导语：在交易量较大的大中型银行中，应用运维一直是一项难度大、压力大且人员占比多的工作。随着应用架构云原生转型，运维压力更是与日俱增，特别是当应用出现故障后，普遍存在告警慢、定位慢、处置效率低下等问题。传统的运维架构与手段已经难以支撑当前的运维需求。在信创建设持续推进的背景下，应用运维模式的革新已刻不容缓。

随着信创建设在“8+N”个关键行业的持续深化，云原生技术在国内快速发展并广泛应用。经过多年实践，云原生技术在算力供给、技术创新、应用建设与安全防护等方面已形成多项标准、评估体系、研究报告和度量模型。

然而对金融科技部门而言，随着业务连续性要求不断提高、应用架构变化导致运行稳定性下降，如何提升云原生环境下应用问题的处置效率与应急能力，目前仍缺乏明确的规范与指导。可以说，云原生应用运维已成为当前金融行业迫切需要解决的核心痛点。

为应对云原生转型带来的应用运维挑战，本文聚焦于金融行业实践，从管理和技术两大维度，探讨云原生应用运维模式的革新路径。

01

管理维度

组织架构调整

近几年，以国有银行和股份制银行为代表的金融机构，已率先完成数据中心的架构调整，实现了从运维到运营的转型，进入了数据中心发展的第四个阶段。

在架构调整过程中，有一些银行将“数据中心”改名为“科技运营中心”或“数据运营中心”，也有一些银行选择进行扁平化管理，将原有数据中心职能拆分为若干处室，直接纳入信息技术部等科技大部门之下。这一系列架构的调整为推动运维到运营转变、促进成本中心向利润中心转变，以及全面提升科技创造价值与满意度奠定了坚实基础。

科技条线的组织架构调整，为应用运维组织架构的进一步革新创造了条件。此次调整一方面继承了开发运维一体化的思想，另一方面本着提升应用运维效率、保障应用系统运行连续性，解决应用运维效能低下、团队人员规模越来越大及运维成本直线上升等问题。因此，在应用完成云原生转型后，即要考虑如何对运维团队进行调整。

02

管理维度

应用运维架构调整

在传统架构应用时期，数据中心的主要职责是保障系统的连续性和稳定性，应用运维相关的所有职责都由数据中心负责。开发中心通常作为应用运维二线，负责协助数据中心进行应用运维问题排查。因此，这个时期的金融机构普遍会在数据中心下设应用运维处室，负责应用巡检、问题发现、故障应急处置、发布部署及监控开发等一系列运维工作。

当应用架构转型云原生架构以后，从应用运维内部来看，应用问题定位及处置将会变得越来越复杂。此时如果仍然依靠原有应用运维模式，显然达不到业务连续性要求。此外，数据中心转型为科技运营中心，其职责重心也将同步转向资源运营、服务运营与数据运营。从应用运维外部来看，需要上升到科技条线视角，那就是提升科技服务价值、改善业务部门满意度并有效降低应用运维成本，已成为外部核心诉求。因此，无论是应对内部运维挑战，还是满足外部核心需求，都需要对应用运维的组织架构进行调整。

基于上述原因，在数据中心转型为科技运营中心后，原应用运维处室被调整到软件（开发）中心下。对于已经实施扁平化组织架构的银行来说，应用运维处室会直接挂靠在科技部下，并由分管开发的领导直接负责。

03

管理维度

应用运维职能调整

应用运维的组织架构调整后，相对应的职能也需要进一步细分和调整。 

应用运维职能调整后，原有应用运维工作职责被划分为两大部分：

一是与生产环境中应用操作相关的，如应用发布、应急处置等直接涉及生产环境的应用操作，此类工作仍然由科技运营中心负责，以符合金融监管要求的开发运维分离、有效预防运维操作风险原则。这类工作会移交给一线运行管理团队（有的银行称之为“大运行”团队）来负责。

二是事件分析与工具研发相关的，涵盖事件定位、排查，以及提升事件告警效率的监控工具研发等工作。这部分职能会随着应用运维处室一起调整到软件（开发）中心。

需要说明的是，上述两类职责的有效履行，均需具备相应的技术条件作为支撑，相关改进要求将在下文中进行详细阐述。

以上应用运维团队的职能调整，更有利于提升应用运维整体效能，其价值是显而易见的，但实施这种调整对于部分银行来说，需要有足够的勇气和魄力。

04

技术维度

构建云原生技术指标体系

想要做好云原生应用运维，要务之一就是构建云原生技术指标体系。尽管技术指标体系这一概念已经在大型金融机构中被提出数年，但能将云原生相关指标落地实施较好的案例仍然较少，成熟落地仍在探索阶段。为了更好的实现由运维转向运营，云原生技术指标体系的相关概念和内容、以及如何构建和落地，是非常值得花费时间去探索和研究的课题。

云原生技术指标体系涵盖分布式框架及云原生相关组件，该体系的有效运行，需依赖相关组件的安装规范和实施工艺，以及各组件的监控指标和监控基线的建立，是保障云原生技术运维非常重要的基础。

在云原生安全领域，中国信通院于2004年发布了《云原生安全配置基线规范V2.0》。该《规范》的发布对云原生安全指标的构建具有一定参考性。然而从技术维度层面看，还需要进一步细化。安全配置基线是金融监管非常重视的内容，而云原生技术指标体系将有效填补云原生转型过程中相关的金融监管标准。

05

技术维度

云原生应用运维技术条件

云原生应用运维技术条件是保障应用运维团队职能调整、应用运维工作职责分离的前提。

■　条件一：全行级云原生应用日志平台

针对云原生应用建设全行级日志平台，该平台需具备容器、分布式组件或PaaS组件、微服务应用及数据库等全量日志收集、清洗、存储的能力，以满足云原生应用系统事件分析、故障排查与定位需求。

■　条件二：云原生应用数据库只读环境

利用中间件或第三方工具构建数据库只读环境，也可以利用数据库自身能力构建数据只读查询节点，以满足云原生应用事件分析、故障排查与定位需求。

■　条件三：一键式云原生应用发布

建设DevOps平台或容器平台，实现云原生应用一键式发布能力，以满足运行管理团队中运维一线人员应用发布操作需求。

■　条件四：云原生应用全链路监控

针对云原生应用建设全链路监控，实现链路跟踪、故障发现、故障定位能力，以满足云原生应用故障快速发现、快速告警及快速定位等运维需求。

■　条件五：云原生应用治理

通过全行级PaaS平台对微服务框架、分布式技术及应用管控等组件进行统一管控，实现业务高并发、应用高可用、微服务流量管控与微服务熔断等处置能力，以满足云原生应用高扩展、高弹性、高安全等运维需求。

对不具备建设全行级PaaS平台的金融机构，可针对一定范围内的云原生应用建设局部PaaS平台，以此来简化云原生应用运维。

06

技术维度

实现应用运维大运行

所谓“应用运维大运行”，是指调整应用运维团队职能（也可以解释为调整原有应用运维团队），实现开发、运维（运营）团队的联合应用运维。

具体实施过程中，原有应用运维职能被拆分，软件（开发）中心应用运维团队、科技运营中心运行管理团队分别接手应用运维相关工作。除构建和满足“云原生应用运维技术条件”外，还需要建设专用的“查询室”，供职能调整后的应用运维团队使用，以此来预防运维操作风险，满足金融监管合规要求。

查询室出入进行实名认证控制，由运行管理团队负责管控，应用运维团队人员可登录日志平台及数据库只读环境，用于排查和定位应用故障。

07

番外

云原生应用运维技术移交

在传统应用架构下，构建应用运维体系时，需开展由开发到运维的技术移交工作。而在云原生架构下，尽管应用运维团队已归属软件（开发）中心，是否仍然需要开展应用运维移交呢？

答案是肯定的。因为云原生架构应用比传统架构应用更复杂，因此更需要移交。只有通过应用运维技术移交，才能保障开发与运维分离，从而满足金融监管合规要求，同时保障应用运维工作的独立性，并降低对应用开发厂商人员的技术依赖。

云原生应用运维文档与传统应用运维一样，包括但不限于《XX应用安装手册》《XX应用运维手册》及《XX应用应急手册》等。应用运维文档由应用开发负责人员编写，并由应用运维人员进行审核和修订。

云原生应用运维技术移交通常分为初次移交和持续移交，并根据应用发布类型和发布版本开展不同类型的移交工作。云原生应用运维技术移交是一项非常重要的工作，这项工作是提高应用运维规范性、保障应用运维知识传承、减少对个体人员技术依赖的重要手段。  

专栏文章内容及配图由作者撰写发布，仅供工程师学习之用，如有侵权或者其他违规问题，请联系本站处理。 联系我们