中小城商行容器化改造最佳适配厂商及实施过程相关运行安全问题规避？

1、中小城商行容器化改造，建议在项目实施过程中，对接现有的运维体系、安全体系和相关工具平台，则可在整体纳入到现有IT保障体系的基础上，将有限资源聚焦于容器台的保障上。
2、行方可购置厂商的驻场服务，解决平台的安全加固和平台运维问题。行方自己聚焦于容器平台的培训、应用推广等产生IT价值的工作

容器运维与传统运维之间有很多大的技术门槛，通过多年的项目经验总结，在中小金融单位决定上容器平台，同时也会采购一定量的人天驻场服务，第一年基本都是合作运维，之后每年根据规模或需求采购订阅服务和重保人天。

在过去三年也看到一些业界容器失败的案例，基本问题就是：测试业务系统迁移到容器平台过程中，出问题运维团队不能及时处理，导致业务开发人员容器平台的稳定性、可靠性产生质疑，最终导致项目失败。

综上，容器项目不是短期内可以交钥匙的，也和稳态（例如IaaS）平台不一样需要紧跟社区，所以后期还存在功能规划、平台运维、升级实施、安全重保、应用迁移、服务改造、流程设计等问题。故，建议行方采购产品的同时，重视服务，采用甲乙双方更加紧密配合的项目建设/服务模式。

我理解，您是想问应用做微服务改造，有哪些厂商可以提供微服务改造服务和方案，以及后期运维双方的权责分工。

微服务改造角度：
业务应用的微服务具体改造工作，都是要应用开发商自身来完成。第三方厂商能够提供的微服务拆分的技术指导和原则，辅助业务开发团队完成微服务拆分工作。一般的容器厂商或者可以做微服务咨询的公司，都会提供类似的技术服务。由于专业厂商不了解业务逻辑，很难让专业厂商来做业务应用的具体拆分工作。

应用改造上线后的运维问题：
一般就是按照应用系统的正常运维来看就好。
一种应用厂商提升驻场运维；另一种甲方自身运维。