云计算技术的飞速发展，使IT基础设施和应用运行模式均发生了革命性改变。多数企业通过构建IaaS（基础设施即服务）、PaaS（平台即服务）和SaaS（软件即服务）三层云服务体系，实现了资源灵活供给及有效复用，并完成了应用从传统IDC机房至虚拟化云平台的迁移。随着云计算技术深入推进，业界对该技术的期望也日益提升，如何使应用在云上以最优架构、最佳姿态运行，充分享受云平台高效持续的服务能力成为新的热点研究方向，云原生（Cloud Native）技术应运而生。               

随着云原生技术的蓬勃发展，越来越多的企业开始转向云原生技术栈。云原生计算基金会(CNCF)云原生全景图中的项目也由成立之初的不到100个扩展到超过1000个（如图1所示），扩展出基础设施供给、编排调度管理、运行时支撑、可观测分析等众多分支，初步建成了覆盖云原生应用全生命周期的全栈技术体系。互联网企业由于对业务线上化、技术创新有很高要求，率先大规模拥抱了云原生技术，其他传统企业也因降本增效的要求加大了对云原生技术的投入。根据Gartner预测，到2025年，云原生技术将成为95%以上新数字化计划的基础。

图1 CNCF云原生全景图

云原生技术的大规模运用也加速了企业敏态业务和稳态业务IT架构的融合。Gartner在2014年提出了“双模IT”的概念，即“管理两种独立、一致的IT交付模式的实践，一种专注于稳定性，另一种专注于敏捷性”。其中，稳态IT架构以传统IT建设思路为代表，基础设施多采用集中式部署和高端服务器，应用强调安全、稳定。敏态IT架构以互联网建设思路为代表，基础设施多采用分布式部署和通用服务器，应用强调灵活、可扩展。“双模IT”的概念一经提出就受到了业界的广泛赞同，各企业多年来大都建立了两套独立的IT架构来承载不同业务的发展。但“双模IT”造成了较大的资源浪费，也不符合新时期敏捷创新的要求。云原生技术针对敏态业务和稳态业务的云化部署及运行均提供了全套适配解决方案，为“双模IT”的融合创造了必备条件，原有部署在稳态IT架构下的业务正加速迁移至新型敏态IT架构。

针对“双模IT”架构，在运维层面逐步发展形成稳态运维和敏态运维两种形态。稳态运维面向稳态IT架构管理场景，强调可靠、安全和成本。运维工具多为解决某一单一运维管理场景需求“烟囱式”建设，运维操作还是以人工触发为主，自动化水平低。敏态运维面向敏态IT架构管理场景，随着云计算技术的大规模发展逐步确立，强调速度、灵活和迭代。运维工具可满足多个运维场景共享复用的需求，运维自动化、智能化的水平显著提升。

云原生技术的运用带来了基础设施、应用架构、交付流程等领域的全栈变革，随着核心业务从稳态IT架构大规模迁移至新型敏态IT架构，原有适配核心业务的稳态运维模式已无法满足新架构下运维保障的需求。我们认为传统稳态运维模式在基础支撑、资源运营等方面面临巨大的挑战，主要包括：

在监控观测方面，微服务、服务网格等技术促使应用节点朝着小而多的方向迅速发展，节点调用链路和关系更趋复杂，日志、监控等运维数据量呈爆炸性增长，原有监控体系已无法敏锐洞察系统的变化。

在变更守护方面，随着应用变更上线的常态化，传统手工半自动的变更方式已难以为继，如何在容器和分布式架构体系下提升变更及验证的效率、降低变更失败的风险成为必须要解决的问题。

在故障应急和防范方面，由于用户通过移动互联网可以在任何时间、任何地点轻松获取所需服务，故障所带来的影响面及损失呈指数级扩大。实现故障快速应急止血，进一步提前发现并防范各类隐患风险成为运维必须要满足的诉求。

在基础支撑方面，基于容器镜像的交付方式重塑了软件开发、交付和运维的全生命周期，业务线上化后也对版本快速迭代提出了全新的要求，无论是运维工具链还是人员组织架构均需改造升级。

在资源运营方面，容器和虚拟化技术改变了计算、存储、网络等资源的供给模式，秒杀抢购活动的日常化也要求运维侧具备弹性供给大规模设备的能力，在保障应用有效隔离的前提下充分共享和复用资源成为一个难题。

为有效应对上述挑战，亟需构建云原生敏态运维体系（如图2所示），在IaaS/PaaS云平台基础上，结合云原生技术，深入构建敏态运维体系下的监控观测、变更守护、故障应急、风险防范、基础支撑、资源运营六大能力。同时在运维组织架构层面也需完成适配运维体系的变革，实现高效率、高质量、低成本的运维目标，保障云上应用平稳运行。

云原生敏态运维体系在现有敏态运维体系基础上，针对以云原生技术为底座的新型分布式敏态IT架构提供全方位运维保障支撑。该体系首先以保障生产平稳运行为核心，同时致力于实现应用交付部署、资源分配供给等运维效率的全面提升，主要涵盖六大领域的建设内容：构建监控观测平台，实现生产运行状态的实时掌控；打造变更守护能力，降低频繁线上操作对生产稳定性的冲击；提供故障应急服务，最大限度减少业务异常影响；建立故障常态化演练机制，提前发现和化解生产各类安全隐患。此外，在基础支撑领域，需实现从组织架构到工具链的全面变革，并利用资源管控技术，充分发挥云原生基础设施优势，满足资源运营灵活供给的需求。

图2 云原生敏态运维体系建设图谱

苹果工程师Cindy Sridharan提出，“监控告诉我们系统的哪些部分是工作的，可观测性告诉我们那里为什么不工作了”。监控观测平台作为掌控生产运行状态的核心渠道，为用户感知生产异常、锁定瓶颈环节提供了有力的抓手。

目前指标（Metrics）、日志（Logging）和链路（Tracing）已成为业界公认的云原生可观测数据体系的三大支柱（如图3所示），监控观测平台的建设主要围绕这三方面开展。

图3 云原生可观测性三大支柱示意图【2】

指标，通过聚合反馈系统状态及趋势。随着云原生建设的深入推进，用户所需观测的指标范围不断拓展，除传统的系统和应用指标外，IaaS、PaaS虚拟化层的指标也被纳入了视野。在采集端，通过对不同的观测对象部署独立的采集工具完成指标的获取。为有效应对短暂抖动、网络瞬断等因素造成的故障，指标采集精度的要求也越来越高，已由原先的分钟级迈入秒级时代。在传输端，“推”和“拉”两种模式各有利弊。“推”模式能有效满足实时性要求，但在可靠性方面依赖于采集端通过重试或者探测机制自行保障，服务端无法精确感知。“拉”模式保障了指标获取的可靠性和完整性，有助于及时发现采集端故障，但在时效性方面略有欠缺。如业界比较流行的开源产品Elastic MetricBeat采用的是“推”模式，而Prometheus则较多采用的是“拉”模式。在存储端，时序数据库（TSDB）已成为指标可靠归集和挖掘利用的有效载体，能满足监控告警、可视化展现、智能分析等多方面的需求。

日志，实现系统状态变化过程的记录。应用上云后由于容器重启、漂移等情况下无法保留数据，因此传统本地保存日志的模式已不再适用，必须构建统一的日志采集、传输和存储体系。在采集端，业界一直致力于在不干扰业务容器正常运行的前提下，以较小的资源消耗代价完成日志数据的采集，由此衍生出Fluentd、Filebeat等一系列轻量级采集工具。通过在每台宿主机上启动统一的日志采集服务，完成其上所有容器日志数据的采集是其中一种部署模式，该模式可最大幅度降低资源占用，但对采集工具的性能提出了非常高的要求。而边车（Sidecar）模式则是为每个业务容器绑定匹配的日志采集容器，这种模式可有效降低采集性能压力，但也会造成一定的资源浪费。在传输端，为满足日志数据多渠道消费，减轻高峰期对存储端造成压力的需求，通常会引入Kafka、RocketMQ等消息队列完成日志的缓冲，并通过在后端部署独立的消费者集群完成日志数据的二次加工与投递。在存储端，ElasticSearch通过分布式横向可扩展架构，可有效承载海量日志数据的写入。同时，通过倒排索引机制，满足了日志数据快速检索查询的需求。截止目前ElasticSearch仍是业界主流的日志存储方案。

链路，提供端到端链路追踪路径。随着微服务架构的大规模推广，单个用户请求会经过多个微服务节点、横跨多台机器，形成复杂的调用路径。传统的依赖于单点业务日志、指标的监控观测手段已难以应对，以链路数据为核心的观测工具和方案应运而生。在采集端，业界通常通过探针或者埋点的方式实现链路数据的采集，从初始服务节点产生唯一识别信息TraceID并透传至下游的服务节点，Zipkin和SkyWalking是当前被较多采用的方案。在存储端，ElasticSearch和Hbase是目前业界主流的技术路线，前者可满足链路快速关联追踪的需求，后者则对于海量数据提供了更好的存储服务。

图4 云原生可观测性产品体系图【1】

业界普遍认为，变更是引发生产稳定性问题的主要因素。在云原生架构体系下，每个微服务均可独立交付和部署，使业务的敏捷上线成为了可能。越来越多的研发团队提升了业务更新的频率以快速应对市场需求的变化，生产变更操作的次数也较原先呈现指数级增长。为降低变更出错或失败对线上运行的影响，我们需分别从流程和技术两方面入手全方位打造变更守护能力，涵盖建立分级发布流程、构建自动化验证体系、研究智能化防控机制三大建设内容。

分级发布流程，有助于提前暴露变更风险，最大限度降低变更失败的影响面。近年来，企业除正式环境外普遍完成了预发环境和灰度环境的新增建设（如图5所示）。当应用程序交付至生产后，首先会被部署到预发环境进行充分的测试验证，预发环境和生产实际运行环境在功能及配置方面保持了高度的同步，但不会接入生产实际流量，因而该环境下的变更失败不会造成任何业务损失。其次，应用程序会被部署至灰度环境进一步校验，灰度环境承接了小规模生产实际流量，可以在较小业务损失的代价下，提前发现变更风险。最后，应用程序才会被全量部署到生产运行环境，但在具体发布过程中，还是会按照从单点到集群，再到园区由点及面、循序渐进的方式进行，以便故障情况下及时阻断和回退。

图5 变更分级发布流程示例【3】

自动化验证体系，降低了人工误操作的风险，可大幅提升变更的整体效率。随着应用部署节点爆发性的增长，节点间调用关系日趋复杂，依靠运维人员手工发起验证的模式已难以为继，自动化验证成为云原生运维必备的基础能力。为全面适配云上应用个性化验证及反馈的需求，自动化验证体系需涵盖丰富的原子验证手段、可配置的验证编排服务和多渠道结果反馈机制三大要素。原子验证手段通过打通PaaS、微服务、负载均衡等基础支撑平台，满足容器、服务、接口和数据库等多种场景的验证要求；验证编排服务支持用户针对每次变更自定义录入相匹配的验证策略，并在变更事前、事中和事后按照预先的设置实现自动触发验证；验证结果反馈有助于用户实时掌控投产动态，第一时间做出调整决策，目前，可视化展现、邮件通知等反馈渠道已被广泛运用。

智能化防控机制，提供不依赖人为设置的防御服务，守护变更风险的最后一道防线。目前业界在自动化验证体系的基础上，主要运用人工智能技术打造了两类较为成熟的智能化保障机制。一类是指标时序异常检测机制，该机制基于动态时间规划、3-Sigma、核密度函数估计等时序异常检测模型对系统和业务指标进行变更执行前后、变更组与非变更组、变更组与全局等多种维度的智能化比对，第一时间发现异常风险。另一类是日志堆栈新增/突增异常检测机制，该机制基于自然语言处理技术提取日志模板相似性特征并进行分类，通过对比变更前、后系统堆栈日志是否有出现过新的日志模板类型，以及系统堆栈日志是否有某个日志模板类型的数量出现大幅度增长，提前识别潜在的瓶颈隐患。

云原生时代对业务的快速止损提出了更为苛刻的要求，传统故障应急体系已不再适用。互联网头部企业针对故障应急提出了1-5-10故障处理标准，即1分钟故障发现、5分钟故障定位和10分钟故障恢复，该标准覆盖了故障响应的全流程，也成为各公司故障应急体系建设的目标。事实上，通过云原生监控观测平台打造的数据体系和报警功能，已基本满足故障快速发现的要求，因此，故障应急服务主要侧重于提升故障定位和恢复环节的效率。

在故障定位环节，业界一直致力于缩短从接收报警到确定故障节点的时间，以便采取措施尽快完成恢复，而对于引发故障的具体根因，则可在事后再分析。为降低对运维人员经验和水平的依赖，专家规则自动定位和AIOps辅助分析定位是目前努力的两大方向。专家规则自动定位普遍基于故障树分析法（Fault Tree Analysis，FTA）开展，该方法是由上往下的演绎式失效分析法，利用布尔逻辑组合低阶事件，分析系统中不希望出现的状态。基于FTA理论构建的故障定位平台，可提供专家经验串、并行编排能力，支持基于前序诊断结果发起后续诊断，有助于提升专家规则固化保鲜和决策定位的能力。针对未知故障，AIOps智能算法通过对运维数据进行建模分析，可帮助运维人员确定问题排查的方向。截至目前，AIOps仍处于发展衍化的阶段，故障定位算法的准确度和普适性也还有待提高。

在故障恢复环节，业界致力于通过提升自愈水平和打造一键式应急服务，双管齐下实现应急恢复时间的压缩。针对部署维度的简单故障，云上自愈主要提供容器、宿主机两个层面的快速自愈和恢复服务。在容器层面，基于健康检查、资源配额限制等保障手段，自动重启或驱逐异常容器。在宿主机层面，通过k8s集群管理机制定时汇总各主机实时状态，及时发现并隔离异常主机。针对服务维度的简单故障，如突发性的外部流量访问或内部节点异常，会导致局部服务响应缓慢或者不可用，可通过建设限流、熔断等流量防护手段，对系统少量服务出现故障的场景进行处理，实现整体功能的快速恢复。针对版本升级、集群变更等因素引发的复杂故障，因涉及多技术栈多平台的联动操作，自愈存在较大的风险，通常会根据企业自身技术选型和架构特点，个性化地打造一键式预案执行的能力，在执行层面引入人工二次确认的机制进一步降低风险。

通过常态化演练发现系统隐患，验证各类运维功能的有效性已成为云原生时代保障生产稳定运行的重要手段。近年来，业界不断丰富演练场景，持续拓展演练覆盖范围，逐步形成了线上、线下一体化的故障演练体系。通过规范化、流程化等手段进一步健全稳态保障机制的运维敏捷性，帮助企业快速发现和化解生产各类安全隐患。其中，混沌工程、无损演练和全链路压测是实施故障演练最为倚重的三大核心能力。     

混沌工程，是在分布式系统上进行试验的学科，旨在提升系统稳定性，建立系统抵御生产环境中发生不可预知问题的信心。不同于传统使用故障演练工具手工注入故障进行系统可用性测试的方式，混沌工程提供了一整套稳定性保障方法论和工具集，与企业敏态运维思路能够很好契合。在以分布式、云计算架构为核心的架构体系中，混沌工程通过模拟注入故障、观察系统行为、发现弱点并反复迭代，不断驱动云原生服务提升健壮性（如图6所示）。基于审慎原则，故障演练一般会在测试环境引入和生产对等环境，再逐步进阶到具备真实流量的灰度环境和生产环境。对于成熟的演练场景，在精准流量控制、有效爆炸半径控制及成熟应急预案的前提下，真实在生产环境实施演练。目前，混沌工程技术发展迅猛，服务强弱依赖治理、监控告警治理、典型生产故障案例守护等场景已实现自动化，支持在无人值守情况下提供流量自动注入、故障自动注入、稳态自动检测、自动安全防护、报告自动生成等全流程服务。

图6 混沌工程实践流程图

无损演练，是在生产演练场景下利用混沌工程能力对生产各运维系统开展非真实的故障模拟，以期望在运行过程中发现运维监控系统、团队还存在的缺陷，从而降低生产故障出现后能够造成的影响程度。无损演练机制通过持续对生产系统和团队进行操练，可不断完善运维系统和团队的敏态运维能力。在运维系统检验方面，无损演练针对各类运维指标（日志、监控、报警等）进行故障注入，可检验报警配置是否精细，监控覆盖是否全面，应急方案是否详细完备。在团队锤炼方面，可锻炼团队快速响应，利用工具进行故障快速定位和应急处置能力。目前，无损演练为红蓝攻防提供重要工具支撑，在故障发现、故障响应、故障定位恢复、故障复盘等方面不断提升应用整体运维水平，提高团队战斗力，降低故障影响程度。

全链路压测，是基于真实的生产业务场景、系统环境，模拟海量的用户请求和数据，从而对整个业务链进行压力测试，并持续调优的过程（如图7所示）。在云原生时代，IT环境和链路变得更加错综复杂，使得如何对分布式系统整体的真实性能进行评估成为亟待解决的问题。首先是测试环境仿真困难，在真实的业务场景下，每个系统的压力都比较大，而系统服务之间有着错综复杂的相互依赖关系，测试环境很难稳定模拟；其次，系统整体性能无法准确评估，采用传统的单机压测，以局部结果推算整个集群的健康状况，往往无法评估整个系统的真实性能水平；最后是系统治理演进缺少依据，现有限流机制均在单个节点或服务上实现的限流，系统整体的高可用治理以及性能容量规划缺少指导依据。全链路压测通过流量模拟、流量染色、数据隔离、日志隔离、风险熔断等关键技术，提供了上述难题的标准化解决方案，实现链路级性能容量测试和调优的敏态运维能力。通过染色与隔离手段防止压测流量对真实业务产生影响，并在压测过程中对生产系统健康度进行实时监控，可快速识别压测对生产业务带来的影响，实现系统极限容量的精准探测。

图7 全链路压测流程图

云原生运维需要解决标准化、自动化和智能化这几个关键问题：标准化促使开发和运维团队高效协同，推动工具链生态日趋完善；自动化应对大规模运维场景的挑战，支撑业务快速迭代和稳定运行；智能化作为自动化运维的增强是未来演进的必然趋势。因此，运维效率提升的重点在于组织和工具层面应该如何应对。而在云原生架构渐为普及的背后，DevOps文化以及支撑其落地的自动化工具链与平台能力发挥着巨大的作用，极大地加速了开发和运维角色的融合。基于成熟的DevOps理念组织团队使用自动化的工具进行协作和沟通，从而高效地完成软件生命周期管理，进一步增强了云原生的敏捷特性，实现更加快捷、稳定的软件部署。与此同时，SRE（Site Reliability Engineering）理念开始被广泛接受，该理念旨在通过软件和自动化手段来解决系统的运维复杂性和稳定性问题，帮助团队在发布新功能和提升系统可靠性之间找到平衡。【4】

运维架构和体系的变化持续推动组织架构转型。随着应用架构的迭代演进，组织架构也需要随之相应调整，两者需要保持高度匹配。在云原生时代，传统运维团队的一些职责转移到开发团队，比如应用配置和发布、投产变更流水线等，从而降低了运维成本，让运维职责更加聚焦于系统稳定性和主动治理。谷歌（Google）提出的SRE是其在DevOps领域的实践总结和抽象，近些年被业界所广泛熟知，其职责包括容量规划、分布式系统监控、负载均衡、服务容错、on-call、故障应急和业务协同支持等。虽然国内外各大企业在探索和实践SRE模式过程中都结合自身的特点形成差异化的方法论、组织结构与分工，但核心目标是一致的，都是使用系统工程的思想和方法替代软件工程系统管理员的手工工作，确保应用服务可以正常运转。组建SRE团队应对云原生时代繁杂、海量的运维工作已经逐步成为业界普遍的共识。“一群能够将工程专业知识应用于运维问题的开发人员”负责维护和建立其系统的服务水平指标（SLI）、目标（SLO）、协议（SLA）和错误预算，并且专注于运维平台和运维工具的研发及维护，实现应用运维和系统、资源运维的自动化和智能化，确保系统正常运转。【5】

高效的运维体系也离不开稳定的工具链支撑。容器技术解决了应用打包、分发和运行一致性的痛点，加速了不可变基础设施理念的落地；而Kubernetes作为分布式资源调度的标准，向下封装资源、向上支撑应用，极大地简化了应用部署和维护，提升了系统的可移植性。在此基础上，依托DevOps平台以及CMDB、变更发布管控系统等建立投产变更流水线，实现了应用无人值守版本发布或环境变更。在发布过程中，系统根据应用日志、监控数据、业务指标等进行自动化的分析验证，结合灰度发布策略，在正常情况下逐步进行流量爬坡，直至发布完成；在异常情况时可以自动阻断发布过程，设置自动回滚。另一方面，近年来随着SRE实践经验的不断沉淀和总结提炼，业界也出现了被称为SRE工作台的一站式运维套件，提供在运维、开发领域所涉及到的工具链的全栈解决方案，有助于将运维工作进一步前置到研发环节，提供SRE作业在线开发、标准化调度管理等功能，并基于数据化运维业务模型推动运维量化管理。

根据Gartner统计，全球数据中心资源的平均利用率不足12%，资源存在巨大浪费的现象。根据中国信息通信研究院调查数据显示，云原生技术给企业带来的价值中，提升资源利用率，节约成本连续两年排名第一；此外，截至到2021年，已有九成用户认可该项价值，提升资源利用率的排名远在提升弹性效率、提升交付效率、简化运维系统等之前。

我们认为在云计算时代的资源运营大致可以分为两个阶段。第一阶段我们称之为“资源池化+配额管理”，该阶段是基于容器、虚拟机等虚拟化技术实现资源池化，辅以基于配额分配的资源运营手段，资源利用率可达到远超平均的接近30%水平，该阶段资源配额评估主要依靠于人工，用户在申请资源时冗余量通常会被放大，这直接制约了资源利用率的进一步提升。而资源运营的第二阶段则强调“资源按需调度分配”，充分利用弹性伸缩、资源配额推荐调整、Serverless和资源混部等柔性计算技术（如图8）实现资源配额的自动评估，最后实现按需使用，门槛显著提高。

图8 柔性计算技术象限分布图

弹性伸缩，指根据用户的需求和策略，自动调整其弹性计算资源的管理服务，是这几项技术中难度最低、但效果较好的一项技术，能充分体现“按需使用”的特点，包括有计划的定时弹性伸缩和自动弹性伸缩两大类，在资源空闲时缩容释放资源，在资源紧张时进行扩容。资源配额推荐调整，则会引入相关AI算法，基于应用实际资源使用数据进行计算，以预测结果驱动资源配额的推荐甚至资源调整，包括了横向的副本数，以及纵向的资源配额，是自动弹性伸缩的增强版本。

 图9 弹性伸缩技术原理示意图

Serverless函数计算，作为目前云计算的热门技术，被Gartner称为最有潜力的云计算技术发展方向。Forrester也认为：Serverless架构的兴起，让函数FaaS（函数计算）成为继 IaaS、PaaS、SaaS之后一种新的云计算能力提供方式。Serverless函数计算通过函数代码即业务服务的模式，通过事件驱动，应用无需管理服务器等基础设施，平台可实现根据调用量自动弹性扩展运行函数所需要的容器计算资源，并在使用后立马释放资源，提供弹性、高可靠的运行方式。Serverless技术把云平台“按需使用”的特点发挥到了极致。

 图10 Serverless函数计算技术原理示意图

资源混部，目前比较典型的应用场景为“在线+离线”混部，即在离线混部技术，通过将在线业务(通常为延迟敏感型高优先级任务)和离线任务(通常为 CPU 消耗型低优先级任务)同时混合部署在同一个节点上，以提升节点的资源利用率；也可以扩展到更广的应用范围，即多优先级应用混部，它采用了把高优先级应用运行过程中多申请的空闲资源，调度给海量低优先级负载运行的应用使用的思路，获得了立竿见影的良好效果。资源混部是所有技术中门槛最高的，目前业界较为通用。

 图11 多优先级任务混部技术原理示意图

经调查，业界头部大型IT公司的数据中心资源利用率远高于平均水平。比如，该领域的先驱Google公司，基于其生产实践输出了多篇影响力较大的论文，如《Large-scale cluster management at Google with Borg》、《Autopilot: workload autoscaling at Google》，同时Google利用混部技术将资源利用率从10%提升到60%，每年可节省上亿美金成本，通过Autopilot（智能资源请求）将闲置资源率从46%缩小到23%。腾讯公司联合信通院发布了《云原生成本管理白皮书》，并先后开源云原生成本优化项目Crane和在离线混部系统Caelus；同时基于云原生的成本优化，腾讯自身业务负载从30%提升到了45%，混部集群的负载更是达到65%的较高水准。

近年来，金融业也在积极拥抱云原生技术，随着云原生转型的深入和IT架构的变革，企业数字化转型已经进入关键期，金融行业亟需打造与云原生架构相匹配的敏态运维体系，以满足银行业务快速增长以及应用系统连续性和高可用的需要。通过多年的研究和建设，金融企业在云原生敏态运维体系建设方面也取得了显著成效，主要体现在运维效率提升、稳定性保障、成本优化三个方面（图12）。

 图12 运维转型成效示意图

金融业从工具链支撑和组织架构转型两方面入手，重塑运维基础支撑体系，实现运维效率的大幅度提升。在工具链支撑方面，积极打造一站式研发运维平台，并深度运用DevOps技术构建标准化交付流水线，提升研发到运维全流程自动化水平；在组织架构层面，通过适配云原生技术，升级运维管理流程和管理规范，同时探索组建SRE团队加速传统运维团队的转型升级。比如：

建设银行重塑运维基础支撑体系，以云原生持续提高交付和运维管理能力，通过标准化运维语言建立模型，沉淀通用的运维服务，为共享运维能力创造条件；借助跟云产品的深入集成，打造敏捷研发平台，提供研发流程和平台工具支持，平台工具链的完善使得运维效率得到大幅提升。建设银行在《打造云原生能力赋能新金融行动》【6】提到“敏捷研发平台已为1500余个系统提供1.8万条流水线服务，平台工具链基本覆盖行内主流交易类应用从开发到投产的全流程。运维能力共享使得应用发布更敏捷、运维人员操作更规范、自动化水平和运维能效更高、架构可靠性更强、系统稳定更有保障。”

浦发银行深度融合业务需求，对齐业务目标，打造了全新的DevOps平台飞云；推进组织架构层面和团队建设方面与云原生技术的适配，以平台为核心枢纽，整合串接各研发工具链，保障研发过程数据共享，完成运维工具链建设，为各团队提供需求分析、研发协作、CI/CD等能力，推进研发运维一体化。浦发银行在《业务价值领航先锋案例 | 上海浦东发展银行DevOps工具平台-飞云系统》中提到【7】“截至2022年4月底，飞云已支持浦发银行340个系统使用，服务用户3800余人。其中敏捷转型项目110多个，支撑4个项目完成中国信通院DevOps三级认证，提高了项目研发质量和研发效率。同时，飞云作为自研系统，为浦发银行节约了采购微软Azure DevOps等商业平台产品的支出，一定程度上避免‘卡脖子’风险。”

工商银行重塑运维研发模式，实现生产运维管理全流程自动化，将环境交付、版本发布和变更管理等核心流程统一纳管至一站式生产运维服务平台，有效提升运维的协作效率和工作质量。深度运用DevOps相关理论和技术，自动化管控版本投产交付全流程，应用版本交付自动化覆盖率超过95%，投产交付实施成功率超过92%，提升了金融业务产品推陈出新、敏捷交付的速度与质量，全新的交付运维模式为金融业务发展提供了高水平的运维支持。

金融业始终以保障生产7x24小时可靠运行为第一要务，通过拥抱业界最新技术成果，持续提升云原生时代的稳定性保障水平。一方面，针对生产部署、运行和应急各阶段均构筑了牢固的观测守护体系，实现故障从发现到应急的全流程敏捷管理；另一方面，积极探索建立故障演练机制，通过以演促防的策略，主动出击将风险隐患扼杀在萌芽状态。比如：

招商银行为保障云原生时代故障快速止损，深耕故障应急领域，一方面借助容器平台弹性伸缩特性，实现容器、宿主机等维度的故障自愈，另一方面通过完善的网络线路、隔离机制实现复杂故障一键式恢复。《招商银行原生云容器平台项目》【8】提到“生产应用发布后即可获得多AZ高可用部署、平台级AZ故障流量自动隔离能力和一站式域名级流量切换能力,此外,借助容器平台的多指标弹性伸缩,应用可实现秒级的快速扩缩容,从而可以有效应对流量高峰”。通过故障应急能力的提升，为招商银行业务稳定运行提供了可靠的保障。

中国银行在监控可观测方面和故障应急方面进行了探索和创新，在全链路观测领域，构建了秒级监控、全链路监控、动态异常检测、告警风暴抑制四大核心能力，全方位展示业务运行状态，同时基于海量流水日志，依托下钻至组件级的“仪表盘”对关键数据可监控观测，有效缩短异常发现和问题定位时间；在应急方面打造了应急处置的场景化、自动化和智能化能力，支持自动化熔断和限流，支持园区级流量切换。中国银行在《智能运维构筑金融发展新格局》【9】提到“应用采用组件单元化部署方式，实现交易智能分流，以达到同城双活异地可实切效果，使应急处理效率得到显著提高，特别是在分布式架构下，相比集中式架构，应急操作自动化能力有了质的飞跃。”

工商银行根据业界“1-5-10”故障处理标准，通过云原生监控观测平台可第一时间发现业务异常，利用专家规则自动定位和AIOps辅助分析对故障原因进行定位，同时联动灾备平台、云平台进行快速应急止损，保障业务稳定运行。基于日志、全链路跟踪、AIOps等技术，构建了企业级的云原生可观测平台，提供多维度、多场景的监控能力，并支持个性化报警配置，可实时掌握服务的运行状态；建立投产验证平台，提供接口验证、数据库验证、日志验证等16大验证场景验证能力，月均验证点数量超过4.5万条，进一步提升变更效率，降低变更风险；建立故障应急平台，帮助应用发现投产和运行风险超过8000个，协助定位问题次数超过10万次；建立混沌演练平台，落地工行300余个业务系统，沉淀混沌测试案例18000余个，帮助落地应用发现600余个深层次、高可用问题，为保障研发测试阶段的稳定性发挥了重要作用。

金融业通过深度运用柔性计算技术，持续提升云原生时代的资源利用率，大幅降低成本支出。目前，大部分金融企业在资源运营方面已完成从第一阶段人工静态分配到第二阶段动态按需分配的转变，并基于弹性伸缩、Serverless、混合部署等云原生新技术，提供资源配额的实时自动评估和灵活供给的服务，达到降本增效的效果。例如：

网商银行不断深化云原生技术的应用，针对成本优化大规模使用Serverless技术和在离线混部技术。通过建设基于Serverless的核心基础设施平台，将容量弹性伸缩等核心能力与业务解耦，实现资源利用效率的提升；在离线混部技术方面，以资源隔离和动态调整为基础，通过CPU弹性共享和优先级抢占、应用错峰编排等能力，利用调度算法和容量计算模型等技术手段完成资源的合理利用。网商银行在《金融级云原生分布式架构实践》【10】提到，实现了“让应用可以无限扩展以应对极高的流量峰值，在达到流量峰值后可以进行资源的快速释放，真正做到资源按需弹性伸缩，同时解决资源错峰高效利用的问题，降低IT成本。”

工商银行提前布局资源混部、Serverless函数计算、弹性伸缩等云成本优化技术。在资源混部技术方面，利用机器学习算法预测应用的负载趋势情况并计算最佳的配额，通过资源调度将不同优先级应用部署在同一个物理节点，以空闲的高优先级业务满足低优先级业务的需求，并通过毫秒级的资源隔离，实现节点资源利用率提升至2倍及应用稳定性影响小于5%。在弹性伸缩方面，基于CPU、内存等资源使用情况实现了应用副本秒级扩缩，生产上月均扩缩超过2万次，资源无需按峰值需求置备。在函数计算方面，利用函数计算按需加载、实时弹性伸缩的特点，落地模型发布、分布式批量、标准化投产等场景，资源利用率提升90%。

未来，我们认为云原生敏态运维体系在监控观测、基础支撑和资源运营三大领域还有长足的发展空间。在监控观测领域，用户要求的不断提升和技术水平的衍进发展，促使可观测体系的建设迈入深水区。在基础支撑领域，一方面GitOps的出现有利于研发运维的深度融合，将打通运维交付效率提升的最后一公里；另一方面，分布式云新型部署架构的出现为现有云原生基础支撑体系带来了全新挑战，驱动其持续适配升级。在资源运营领域，FinOps发展迅速，有望成为资源高效运营的标准解决方案。

 图13 云原生敏态运维体系发展趋势

指标（Metrics）、日志（Logging）和链路（Tracing）三大支柱为可观测能力提供了基本的数据保障，但随着云原生技术的不断发展和大规模运用，用户对可观测体系提出了更高的要求。一方面，可观测领域需覆盖的场景持续向纵深、精细化方向拓展。在系统维度，除传统用户态观测指标外，内核资源消耗、网络拓扑调用等深层次运行状态也被纳入视野；在应用维度，原有节点级观测粒度已无法满足性能瓶颈精准定位的要求，程序级细粒度观测成为新的研究目标。另一方面，现有三大支柱数据体系相互割裂的弊端逐渐显现，影响了故障定位分析效率的进一步提升。

新时期用户观测需求的衍进驱动着可观测体系建设逐步迈入深水区，eBPF、Continues Profiling（持续性能剖析）和OpenTelemetry正成为引领可观测领域发展的三大热点研究方向。

eBPF是一种安全高效的内核可编程技术，在对内核无侵入的前提下实现自定义监控及跟踪能力。业界期望通过该技术填补内核态监控领域的空白，识别系统节点间调用的拓扑关系。脸书（Facebook）、谷歌（Google）、微软（Microsoft）、奈飞（Netflix）等公司在2021年共同发起成立了eBPF基金会，国内阿里、腾讯、字节跳动等互联网头部企业也已布局开展相关研究及实践。

Continues Profiling是一种在应用运行时收集程序信息的动态分析技术，能够让性能分析贯穿应用的整个生命周期。该技术使用户在生产运行环节永远知道代码的所有执行细节，具备代码级性能分析能力。谷歌（Google）于2019年最先发布的Cloud Profiler支持极低开销的CPU内存采样统计性能分析，亚马逊（Amazon）的CodeGuru Profiler、Datadog的Continue Profiler等产品以及Pyroscope开源项目也在持续迭代中。国内阿里在JVM Profiling特定领域有相关实践，浙江大学也在开展相关研究及原型开发。

OpenTelemetry是云原生基金会CNCF重点打造的项目，致力于实现指标、日志和链路三大支柱数据的融合，以统一的协议使用统一Agent完成采集和传输。项目已发布链路组件的稳定版本，并于今年5月份发布了指标组件的候选版本。谷歌（Google）、微软（Microsoft）、亚马逊（Amazon）等公司深度参与了项目建设，国内公有云厂商如阿里云、腾讯云等对OpenTelemetry均有支持。

未来，随着eBPF、Continues Profiling和OpenTelemetry等技术趋于成熟，云原生可观测体系所覆盖的观测场景及观测能力将迎来质的飞跃，助力用户更全面、更精准、更实时的掌控生产运行状态。

云原生带来的变革并不限于基础设施和应用架构等技术层面，更是对于研发理念、交付流程和IT组织方式的重塑。DevOps经过多年的实践，虽然已经较好解决了应用侧持续发布的问题，也在基础架构即代码（IaC,Infrastructure-as-Code）方面有所实践，但在环境一致性、变更回溯和合规审计等方面仍存在一些痛点，而GitOps正是解决这些痛点的代表技术之一。

“云原生”DevOps遵循在K8s上运行容器的最佳实践，并将基础架构即代码理念进一步延伸，覆盖整个云原生软件的交付、运维流程，加速了GitOps技术的应用和相关工具链的成熟，使云原生下的DevOps更加高效、安全、稳定和可靠。GitOps作为一种用于Kubernetes集群管理和应用程序交付的技术，将应用所有声明式部署编排（基础设施代码、应用代码、策略与配置等）都存放在Git仓库中管理，并通过自动化流程进行交付和变更。基于容器、微服务或无服务器架构等云原生技术栈并遵循开源标准构建的应用，可以完全抛开历史包袱，充分利用“云原生”DevOps技术实现持续交付和智能运维能力，实现更高的服务质量、更低的开发运维成本，让研发更专注于业务的快速迭代，让运维发挥更大的价值。

未来，以GitOps技术为代表的“云原生”DevOps将得到更加广泛的应用，进一步推动研发运维体系的深度融合。与此同时，SRE模式探索和实践也将不断深化，围绕着整个 DevOps 交付链不断输出运维的能力与价值，进一步重塑研发和运维体系，使开发和运维高效协同，带来质的变化。

随着技术与架构的快速迭代，在公有云、私有云、混合云后，云计算开始向分布式演进。2019年，Gartner首次提出“分布式云”的概念，并连续两年（2020年、2021年）将分布式云列为顶级战略技术趋势。据Gartner预测，到2025年超过50%的公司或组织将选择使用分布式云，以满足多元化业务需求，实现业务转型的目标。

分布式云，是云计算从集中式的数据中心部署向不同物理位置多数据中心部署、从中心化架构向分布式架构扩展的新模式，通过将云服务按需部署到不同地理位置，并提供统一的管理能力，满足用户对于边缘计算、安全合规、区域定制和就近部署等场景需求。和传统的云计算模式相比，分布式云支持将云服务按需部署到用户指定的位置环境，增强了混合多云一致性的管理能力，并通过统一技术架构和管理平面，拓展了边缘计算能力，在资源、数据、服务、应用、安全和管理等方面实现了云边一体化，降低了用户的管理运维成本。

分行云模式下带来的运维难度以及安全风险也将同步提高，这是分布式云不可避免的存在。多元即复杂，应用的跨云部署、云边端网络之间的协同、节点规模进一步提升后的普遍故障等等都将增加分布式云的运维难度。因此，需要持续升级运维工具链以提供统一的智能运维体系，支持全域管控能力；同时跨地域的云形态对于运维组织架构提出新的要求，需扩展加强属地化运维管控能力建设。

随着云计算的快速发展，云资源浪费问题也日益凸显，根据2022年分析师和供应商报告，云支出总额的32%是浪费的支出，即在云上每100美元的支出中，有32美元是浪费的支出。同时，企业在云资源管理面临着资源浪费难以识别、资源优化手段匮乏、资源优化流程管理不健全等诸多挑战。为应对企业日益增长的用云成本问题，聚焦云成本管理的FinOps理念应运而生。

FinOps被称为云成本管理，是Linux基金会发起的项目，与DevOps一样，FinOps是最佳实践和工具的集合，通过Inform、Optimize、Operate三个生命周期阶段实现云成本的可视、优化与持续运营，让企业具备精细化云计算管理的能力、技术和流程。【11】其中，Inform是云成本管理的基础，通过各类资源指标采集，利用趋势预测、根因下钻等能力协助进行成本估算、分析成本浪费，提供云资源使用、成本可视及多云环境下的成本统一管理；Optimize则基于成本数据，运用资源容量评估和推荐、基于预测的弹性伸缩、资源混部、负载感知的动态调度、Serverless等成本优化技术，减少云成本浪费，达到降本增效的目的；Operate则从组织、流程等方面建设成本运营体系，通过建立成本优化团队，持续优化以数据驱动的资源指标模型，从而保持云成本优化的持续迭代。

FinOps是一个快速增长的市场，目前国外主流云厂商如AWS、Azure和GCP等提供了支持单云的原生云成本管理工具，如AWS Cost Explorer、Azure成本分析平台等，另外还有第三方独立的多云FinOps云管理平台CMP，如Apptio Cloudability、Centilytics等。国内云厂商如腾讯则推出了首个FinOps开源项目crane，阿里云推出了云上成本管理整体解决方案。此外，据信通院调研数据显示：国内近两成企业已经实际开展FinOps相关实践，约六成企业计划进行FinOps落地实践。未来，随着以云成本优化为导向的FinOps理念的逐步成熟，FinOps将助力企业建立上云、用云和持续运营全流程的长期优化体系，帮助企业改善用云成本，充分发挥云原生的效能和价值，为企业的数字化转型提供可靠的保障。

作者丨中国工商银行金融科技研究院云计算实验室