争议 | 银行数据中心自动化建设：开源方案 vs 闭源方案，谁更适应银行基因？
来自twt社区同行实践经验分享，欢迎更多同行参与交流
银行金融机构数据中心自动化建设，开源方案和闭源方案哪个更适合？
面对互联网行业对传统银行业的冲击，银行数据中心管理的设备越来越多，越来越复杂，数据中心自动化建设是银行业面临的一项迫在眉睫的工程。面对当前各种自动化工具，有能实现某些功能的开源方案，也有一些集成化高的闭源方案，这些方案在价格和人力成本上都有鲜明的对比。之前听说某闭源方案不错，后来有的银行也告诉我说准备用开源方案替换该闭源方案，为了最好的适应银行业的基因，该如何选型？这一直困扰着我们，在此想多和同行交流下。（问题来自@sunzheng 某农商行 软件开发工程师）@邓毓 江西农信 系统工程师：
开源灵活，相对容易二次定制开发，无论是自己还是第三方，但开发周期可能比较长，项目见效慢。闭源功能齐全，可能会水土不服，过于笨重，涉及二次开发的内容需要原厂支持，自己和第三方很难做，但实施周期短，产品功能见效快。现在国内还有一种闭源的方式，就是提供一个平台，自己可以在这个平台上通过各种模板实现，自动化情景的定制，但涉及平台底层的改动，还是要厂商支持。
@chengfeiw 中国银行 软件开发工程师：
开源自动化产品或成商用自动化产品在金融业落地的话，有以下几方面可供考虑。
1、自动化的范围，大致分为应用自动化、服务器自动化、网络自动化、存储自动化。从商用的看，假设上述自动化全部涉及，基本上就是一套厂商的自动化解决方案，价格不菲，运维成本高，二次开发难度高。而且比较难的一点是很难只绑定一家产品，涉及到多产品整合又是一个新的考量点。
从开源产品看，必然涉及到二次开发的适配，以及多个开源产品的组合。
2、评估自动化的规模，规模小可能开源产品能基本满足需求，一旦规模起来了，开源产品的问题就凸显出来。商用产品可以承诺服务规模。
3、升级迭代的问题，无论开源还是商用的，都会涉及到此问题，一个是向下兼容性，一个是对新架构或产品的适配速度。
总之，还是量体裁衣。开源的不一定就是便宜，商用的就是贵，需要按整个生命周期评估。用开源的技术能力要求高，商用的要求服务支持好。开源的改造相对容易，商用的改造困难且迭代周期长。
另外银行业的IT是需要拐棍儿的，一旦出现问题，要么自己撑得住，要么把锅推给服务商。
@wanggeng 某银行 系统运维工程师：
关于自动化运维：不论开源方案还是闭源方案都没有拿来即用的方案，需要投入定制化开发，开源方案优势是全自主，劣势是自身投入和技术要求高，要完全消化吸收；闭源方案项目投产初期快，能快速解决一些问题。劣势是成本在规模上去后高，定制需求的响应慢。
@顾黄亮 苏宁消费金融有限公司 技术总监：
我认为核心问题不是在于工具的选型，而是在于工具使用的方法论上。
以我公司自动化建设为例，建设自动化流水线，流水线的每个节点对于一个模块，也就是一个工具，具体的工具选型也是遵循稳定、可靠、安全、可维护的原则。把多个工具组链，形成流水线工具集，采用逻辑中台来管控工具，形成以交付为目标的流水线。
工具的使用方面：
一、尽量不要做到工具的二次开发，以我的经验来看，二次开发投入的人力和物力过于庞大，而且工具的作者也有相应的优化迭代计划。对于工具的使用，只需使用工具的相应功能，如jenkins的交付、Ansible的配置管理、sonar的扫描。采取接口的方式，把每个工具抛出的数据集中、聚合、分析，形成链式报表。
二、做到工具集群的解耦，比如说某些工具具备高可用集群方案，或者强关联的一些功能。贸然使用，会导致工具内部出现问题不能快速的解决，需要扩容，需要做更多的配置，不能快速上线。我们的做法是工具的解耦，工具的使用永远的最干净的。
希望能够帮助你。
@zhenbaom 某银行 信息技术经理：
我行之前就是用的某闭源方案，严格来说是个不错的产品，但是有几个问题，一是流程引擎对于大并发的性能不好。二是整体架构落后现有主流架构十年，对于新兴工具集成难度大。三是因为原厂商将产品卖掉，技术人员流失非常严重，出了问题解决不了。四是采购价格昂贵，接手的新厂商对于后期维保价格更是高出一大块。五是新版本产品稳定性一般，经常性宕机。还有一大堆小问题就不罗列了。
@jason2006xu 昆仑银行 技术经理：
首先要根据银行自身运维痛点，能否快速、高效的够解决运维的问题，比如有的厂商基于Ansible的自动化平台接地气，能快速解决我们的运维问题或者经过简单的定制化后就可以满足运维需求，解决痛点，大大提升效率，有的厂商是基于Rundeck的开发的闭源产品，功能虽然大同小异，但是不能解决我们实际问题，或者定制化程度低，价格也差不多的情况我肯定会选择接地气的产品。
此外如何跟CMDB、监控、ITIL集成,以及集成工作量有多大，这也是选择自动化平台的一个重要因素。
当然自动化运维平台的构建，并不是可以一步到位的，甚至需要经过不断的演进过程以及实际运维工作中总结出来的，同时也要结合业内主要的自动化运维技术(如Ansible、SaltStack)以及基于容器的DevOps技术实现开发运维一体化的能力，提高我们在运维方面的能力。
@chinesezzqiang 信息技术经理：
开源方案：
优点是灵活可控，对于企业的自定义需求支持好。架构上弹性扩展能力强，可根据企业实际物理情况进行部署。
缺点是需要较强的技术支持团队，尤其是在代码开发方面的人才，人力成本高。由于代码的开源性特征，安全方面无法得到保证。
闭源方案：
优点是成熟产品，经过厂商专业团队测试，较成熟。后期技术支持有保证，人力投入成本较少。厂商定期更新补丁，修复系统漏洞，安全上有保障。
缺点是价格较高，架构扩展性不够灵活，大规模大规模部署易受到限制，定制能力差。
@fuzzycole 产品经理：
现在自己做的产品也是大量地用到了Ansible，Ansible用来做批量系统配置、批量程序部署、批量运行命令，整个逻辑十分简单易上手。既然有这么好的开源工具了，而且社区也有足够的资源可以要学习参考，为什么不考虑用开源工具呢？
另外又话说回来了，最早时候容器平台金融行业很多用了Mesos，后来不也切到K8S上了么，技术栈啥的变化是很正常的，没有说一定哪种更好，只能说选自己熟悉的易上手的就可以了。
欢迎点击文末阅读原文到社区讨论交流，发表您的观点 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
自动化运维体系建设关键点分析——以某大型金融企业为例
http://www.talkwithtrend.com/Document/detail/tid/422113
基于开源软件自主开发自动化运维系统
http://www.talkwithtrend.com/Document/detail/tid/423199
欢迎关注社区 “自动化运维”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/7085
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场