金融企业应该如何进行对象存储的风险评估？

管理风险，政策风险这里不谈，既然这是技术社区，我们只讨论下技术风险

技术风险来自三个方面，产品本身，已有应用改造，整体系统风险。

第一点，产品本身选择上有两种技术路线选择，开源和商业。
选择开源产品风险大些，选择商业产品风险小些。

1. 基于开源方案，从风险上来说非常直观的不利因素就是无人背锅也无人有义务帮忙，出啥问题自己团队抗。开源方案有成熟也有不成熟的，如何衡量呢？如果类比最成功的开源项目Linux，当你发现有非常多的发行版，非常多的技术服务从业者时，开源项目就还没那么成熟；如果渐渐统一，全世界只有几个版本和Redhat/Suse/Ubuntu级别的大玩家，这就已经很成熟了。如果企业本身技术实力不错，有底层开发能力和网络深度相关经验，选开源产品的好处在于能够整体把控，去除厂商锁定，和源码级改动的可能性。还有一种就是基于开源产品，但选择商业技术服务，这种情况下，商业技术服务公司技术能力如何，在开源社区影响力如何，包括该公司能否持续存活，也都是必须要考虑的因素。
   2.基于商业产品，既然是商业产品 ，必然有厂商替你抗第一道雷。而且根据厂商的专业操守不同，或多或少在产品发布前进行了一定数量的优化和测试，达到发布的程度。当然不同厂商的产品可靠性也是有差异的，这对产品技术风险也有很直接的影响。有些产品比较可靠，但有些互联网风格的厂商是喜欢快速迭代的，在用户处打补丁和升级在他们眼里是义正词严的常规操作，这就看金融企业是否持同样理念了。另外厂商响应时间也是要考虑的，出问题是能4小时及时响应还是要等明天国外的总部反馈，相信也有不一样的感受。最后必须要考虑的问题是厂商锁定，是否能够避免？如何后期必须要切换得付出多大代价？这也是前期风险评估不得不考虑到的因素。

第二点，应用系统改造风险
我们已经知道，使用对象存储更有效率的方式需要改动应用，那你就需要评估自己的系统经得起折腾的可能性和随之带来的风险。如果你的系统是一个历经沧桑，写满历史和岁月痕迹的大型拼图，改一行代码要好多层级的领导们审批，那劝你还是谨慎为好。如果是新系统，所有代码作者都还在办公室里喝茶敲键盘，但不是太清楚系统数据调用的机制，也请讨论清楚后再动手。
由于对象存储的访问方式不同，不仅仅是接口改动的问题，系统的架构也许也需要改动以适应更大的并发访问量和聚合性能。例如原来的数据读写模块只是单独的串行方式操作，也许需要从架构上变成并行，同时间段内起更多的线程虚机读写数据，同时还要引入数据一致性的机制和其他保护机制。这样的改动就会比较大，但带来的风险就更大了。

三，整体系统风险
对象存储是一个分布式系统，你的应用如果改造也会变成分布式系统；即使不改造，以对象存储的技术特点和能力，可以给更多的系统接入使用，形成数据池，数据湖，云存储（随便怎么称呼吧）。这样势必把原来相对简单的封闭系统变得复杂化，引入多个系统对接后，整体风险的上升是必须要考虑的因素。