如何更好的提升IT系统产品研发效能和交付效率？

中小银行在设计容器云平台的时候，我认为需要注意以下几点：

首先站在产品研发效能提升层面：

1.      银行自身的持续集成系统、测试服务系统或者DevOps流水线工具，我们建议尽可能使用开源工具来建设，目的主要是让整个产品研发的工具链体系和开发流程更加灵活，目前我们看到有大量中小银行都在采用开源工具链来进行DevOps工具体系的建设；

2.      建议引入一些开放的可以整合这些开源工具链的产品，例如灵雀云的DevOps开放平台，充分尊重客户使用的开源工具链，通过工具链集成的形式简化银行DevOps工具体系建设的复杂性，统一DevOps工具链全链路管理能力；

3.      改变应用的交付方式。原来传统的以二进制Jar包、War包为制品的交付方式，最好统一成以标准容器镜像包为制品的交付方式进行交付；

4.      严格规范业务应用运行的中间件版本或者应用运行环境等，例如限定JDK的某几个常用版本，Tomcat的某几个常用版本等；

5.      尽可能使用轻量化、可容器化的中间件作为业务应用的运行环境，例如tomcat、nginx等，不建议使用websphere、weblogic这种比较重的并且对于容器化不够友好的中间件产品；

6.      引入Service Mesh这种下一代微服务网格技术，简化产品研发的人力资源投入，提升整个产品的服务治理和全局可视化管理的能力。

其次站在提升交付效率的层面我们建议：

1.      容器云平台一定要提供开放的API对接能力，目前市面上主流的容器云平台都是基于Kubernetes技术发展出来的，所以Kubernetes的原生对接能力是非常重要的；

2.      银行自身的持续集成系统、测试服务系统或者DevOps流水线需要具备和容器云平台对接的能力，例如这些敏捷开发工具可以直接调用Kubernetes的API来自动进行应用的持续发布；

3.      建议容器云平台最好可以提供一部分DevOps CD的功能，在银行现有敏捷开发工具无法进行容器云平台API对接的情况下，可以通过例如基于制品更新为触发条件的自动化持续发布能力。

持续集成体系需要支撑容器构建及部署，不建议为容器云单独打造持续集成。
有统一的支持集成体系，就会有统一的交付标准及交付流水线
另外银行的特殊性，每次交付需要具备交付文档等内容，这时候建议使用支持所有制品存储方式（文档、war、镜像）的制品仓库（如JFrog Artifactory或Nexus）进行交付，不建议使用Harbor。因为单独为容器构建交付方式，就无法与体系更好的集成。银行的特殊性，交付docker镜像也需要提供各种测试报告及审批报告等。
综上：统一的持续集成流水线、统一的质量门襟、支持双态的工具链、统一的制品存储及跨环境制品同步能力。