基于传统应用的架构和开发模式存在耦合度大、部署周期长、开发运维割裂等问题，很难扩展和管理，无法满足业务创新发展的需求。在此背景下，云原生技术结合云计算的特点，实现底层硬件和操作系统的解耦，满足用户在扩展性、可用性、可移植性等方面的需求，推动技术架构深层次融合，实现业务短期迭代、产品更新、应用弹性伸缩，极大地释放云计算效能。云原生技术为工商银行业务创新快速发展、产品快速迭代提供了有效的解决手段，极大提升系统稳定性和安全性，有效降低信息系统运营维护成本。

云原生（CloudNative），其中Cloud表示应用程序位于云中，而不是传统的数据中心，Native表示原生为云而设计。云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论，应用程序从设计之初即考虑到云的环境，充分利用和发挥云平台的“弹性+分布式”优势，在云上以最佳的方式运行。 

工商银行云原生系统基于云原生技术业务系统采用开源Kubernetes+Docker框架的PaaS云容器部署结构，同时系统内采取分层的微服务分布式框架（如图1所示）。其中，应用层分为联机和批量容器，均已实现园区双活能力，注册中心实现应用服务登记和订阅，承担请求负载路由的能力，通过健康检测实现应用容器的自愈性上线和自动下线。数据库通过容器化部署，实现分库分片多活自动主备切换能力。通过数据库访问层实现数据库路由和负载均衡，且具备数据库资源的隔离保护作用。本业务系统从设计之初到实施部署考虑云上运行的最佳化，实现标准化容器平台、标准化交付、标准化容器编排、标准化调度等标准化建设。实践过程中可概括为4个要点：微服务架构、容器化、DevOps、持续交付。

（1） 微服务架构：将应用分解成小型松散耦合的独立运行的服务。这些服务映射到更小的独立开发团队，可以频繁进行独立的更新、扩展和故障转移/重新启动操作，而不影响其他服务。

（2）容器化：Docker是应用最为广泛的容器引擎。容器化为微服务编排系统，用于容器管理，容器间的负载均衡，使应用开发从底层基础架构依赖关系中抽象出来，从而实现应用的简单迁移和扩展、应用平台的基础架构调整和配置自动化、资源分配动态化，提升资源利用率，最大程度减少故障恢复时间和停机时间。

（3）持续交付：测试驱动开发和持续集成是持续交付的实用措施。在不影响用户使用服务的前提下，频繁把新功能发布给用户使用，实现快速发布并获得更紧密的反馈循环，做到更有效影响客户需求。

（4）DevOps：开发运维一体化，通过一组过程、方法、与系统工具，促进开发、技术运维和质量保障部门之间沟通、协作与整合。通过自动化流程使软件开发整体过程更加快捷和可靠。DevOps平台通过一系列工具实现软件开发流程自动化，如：项目管理（PM）、代码管理（GitLab）、持续集成（JenKins）、持续交付（单元发布）、日志中心管理、服务治理、系统监控、负载均衡、全息链路跟踪等组成。 

 图1 业务系统结构

云原生技术智能运维架构的设计主要包括以下两个方面：一是智能运维要结合云原生技术的特点来配合设计，使之能够为云原生系统所服务；二是智能运维要利用云原生技术提升按需弹性的伸缩功能，作出动态化的部署（如图2所示）。从运维对象的角度讲，云原生技术智能运维架构是针对云原生系统设计的内容，这一系统的运维对象相对固定，能够按照需求来弹性地伸缩调度，所以匹配的智能运维系统也需要适应这种变化的趋势，其基础设施包括服务器、虚拟机及数据库等，可以建立起不同服务的连接通路。从数据平台的角度讲，数据平台属于智能运维架构的基础平台，能够为云原生技术智能运维架构中的算法平台提供一定的技术支持，对于数据的存储则要重点考虑如何保存海量数据，并进行跟踪。

图2  云原生技术智能运维架构

随着云原生技术智能运维架构在银行业务系统的使用和推广，根据周期性的趋势预测来调整相应的参数，有效提升了故障告警的准确率和系统的故障排查效率。针对故障处理方式业界提出了“1-5-10”标准，即1分钟发现、5分钟定位、10分钟恢复，该标准已逐渐成为各公司运维转型的目标。对标“1-5-10”全面提升工商银行故障应急处理能力，推进运维智能化转型建设。

（1）从故障发生至报警，整体时间控制在1分钟内。

（2）从故障发生到完成故障根因定位，整体时间控制在5分钟内。

（3）从故障发生到业务恢复正常，整体时间控制在10分钟内。

结合工商银行业务系统“1-5-10”故障处理目标，将故障管理划分为故障识别、故障诊断、故障恢复、回溯验证四个阶段。依托智能运维架构，提升业务实时画像系统整体能力，着重在监控全面性、故障诊断及自动化应急方面开展建设。目前计划通过专家库匹配模式解决大部分简单故障场景问题，部分复杂故障问题通过自动化及智能化分析手段定位根因及应急，如图3所示。

图3  原生云智能化运维故障管理

（1）故障识别：统筹全局发现业务交易、系统资源、跨应用访问、节点可用性及突发事件异常，触发报警。

（2）故障诊断：建设故障点模型库，通过诊断中心预设诊断规则检测应用自身、数据库、关联技术平台、临界资源、关联变更运行情况，提供故障诊断全视图，通过因果简单规则关联/复杂数据聚合等多种方式，定位根因关联应急专家库。

（3）应急修复：根据故障诊断结果，结合应急专家库匹配规则，对接各技术平台的应急恢复能力，实现自动化快速恢复。

（4）回溯验证：使用诊断中心能力，通过诊断规则进行回溯验证，确保应用各类状态恢复正常。

通过图3的架构及具体建设方式，为所有应用整体上提供全面的监控图谱，形成系统性的监控数据采集、存储、分析能力；通过应用预设的诊断规则和对应的应急策略实现准确联动，较快的积累故障管理资产，实现复杂问题故障期间的现场快照及对应信息的长期储存能力，结合基础数据实现智能化进一步提高根因定位的能力；通过简单规则匹配及与技术平台应急机制对接，实现快速应急，解决80%以上的常见问题。