金融企业如何解决容器云平台自研过程中可能遇到的问题？

自研过程中遇到的问题不一定都是技术型的，也有些可能是规范或者应用上的问题，对此，解决不同问题，采取的方案也不同，但对于容器技术上的问题：

建立一支专业的容器云平台技术研发团队是必不可少的，学习业内优秀产品，跟进社区技术发展趋势，整合优秀开源实践，同时也要结合自身场景需求，加强底层关键能力及核心技术的研发，扩展云原生技术能力。

对于其它非容器技术问题，比如内部应用运行要求、管理规范、运维管理、及规模化推广等问题，需要加强内部协作、跨部门沟通，以及一些运维工具的开发实现，同时也需要建立一支专业的应用容器化技术团队，更好地支撑容器云平台在企业的落地。

银行以自研方式建设容器云平台的核心挑战和困难，有多方面。
（1）基础设施方面的支持，譬如要考虑银行有成熟稳定的IAAS资源池的支撑，  选择好操作系统和确保供应商支持到位。
（2）是团队建设，譬如核心技术骨干的培养，保障骨干队伍的稳定性
（3）运营体系的建设。走自研的路线，好处是自主可控和节省采购成本，但是要趟的坑较多，运营运维的成本较大，需要加强规范、培训和架构治理，引导业务应用开发方使用好容器云平台。

有几点建议：
1. 内部要先从思想上进行云思维转型和统一，这是一切管理活动、技术方案等决策的基础和大前提；
2. 要有专业能力强大的容器云研发团队和运维团队，且职责分工要清晰；
3. 有外部力量支撑，从方案、疑难杂症、技术视野、能力培训等多方面辅助自研和自运维；
4. 内部相关组织机构要充分协作，包括管理、应用研发、技术平台、运维等相关部门，遇到问题不可怕，可怕的是所有问题都压在一个点。

大体分为两类，技术范围的和非技术范围，笔者将过程中的问题大致分为三类，分别是稳定可靠、自主可控、简单易用。
1、稳定可靠，金融企业对稳定可靠特外重视，尤其是持牌机构，因此格外需求容器云应该要保证业务高SLA。
2、自主可控，金融企业的架构优化往往需求基础架构进行配合，尤其近几年新技术得到频繁的运用，以微服务为例，所以需要格外关注容器云的开源组件的迭代问题，作为企业用户，版本升级的时候会有很大的风险性和不确定性。
3、简单易用，使用容器云不是目的，目的是解决企业目前面临的问题，给企业带来价值，如CI/CD、面临高并发的时候快速扩容、故障快速恢复和迁移、应用快速交付、复杂集群快速部署等问题

这个问题，目前我只能认为是技术问题，技术问题只有一找有经验的厂商解决方案，二找有经验的人，三自己人不断的在黑暗中摸索，就看金融企业能接受哪种了，个人感觉，必然会选择第一种！

外来的和尚好念经，如果用自研的平台，出了问题谁来负责是个大问题，而且这种平台类的一出问题都是影响一大片。

最重要是产品持续性和关键问题的解决能力，还是商业化更可控。

1、可持续性技术输出
     金融企业主业在金融交易上，而容器云作为IT的一种底层技术选择，自研的动力并不充足。因此，能否有长时间稳定的开发团队来支撑，这是需要注意的问题。

2、内部推广困难
     在内部推广过程中，往往会遇到应用开发团队不愿意使用的问题。有应用团队对容器不了解，排查使用新技术的情况；也有平台不好用的问题。

 根据我的经验，
 1、领导要对容器化应用有足够重视，推动各个团队使用；
 2、反复给应用团队培训容器，让其了解容器能够给其带来的价值；
 3、对于已经熟悉开源K8s的开发人员，更喜欢用yaml发布；运维人员对k8s了解有限，需要界面化操作。这两种类型，平台都需要兼顾。
 

3、人员需要持续学习
     既然干上IT这行，就要活到老学到老。需要对K8s及周边技术的持续学习，包括对开源社区的动向也要及时了解。

整个平台建设过程中肯定会遇到很多问题，例如技术架构选型、版本缺陷，一些特殊的场景满足等
一些技术架构之类的问题主要是看团队的技术水平，自研过程可以适当的引进一些云厂商做咨询之类的。但是当平台和业务场景耦合到一起就比较有特色了，有相同的案例较少，需要不断的提升团队的技术水平。