2024年主机上云运维现代化核心能力白皮书

践行深度用云主机上云运维现代化核心能力 目录CONTENTS目录05-08主机上云带来的运维新挑战挑战1：如何基于应用视角设计高可用上云方案与高可靠运维保障方案挑战2：云平台技术栈快速增厚，如何有效进行全链路可视监控挑战3：云网深度融合，如何快速发现、定位、恢复问题挑战4：如何应对运维安全与租户安全的双重挑战09-43主机上云运维现代化核心能力平台运维现代化全链路运维监控构建从应用到云平台的全栈感知能力基于故障模式库和云网一体化运维实现确定性故障恢复基于一体化风险库和混沌工程进行预见性风险治理应用运维现代化运维规划前置到设计阶段，业务可靠性来源于运维与设计的融合借助运维数仓构建应用可用性监控管理体系，实现业务故障实时感知定界面向故障全生命周期，全方位提升故障感知、诊断、恢复智能化水平安全运维现代化全视角运维安全体系设计构筑金融云运维安全堤坝体系化、智能化安全运营为云上业务保驾护航44结语主机上云带来的运维新挑战挑战1：如何基于应用视角设计高可用上云方案与高可靠运维保障方案主机上云的最大挑战就是核心应用上云后的可用性管理。随着原来运行在大机上的应用不断迁移上云，云上的业务可用性等级要求被提升到了新的高度，传统的运维手段已经无法满足核心业务N个9的可用性目标。可用性管理前置到了系统设计乃至应用设计阶段。即便如此，可用性管理依然面临着成本、技术和管理的三重挑战。首先，无论是备份、主备、多活还是业务单元化改造，所有的高可用的架构设计都需要投入高昂的成本，高可用的效果和技术方案的投入成本成正相关关系。如何平衡高可用的投入与产出就成为IT管理者在高可用管理过程中的重要难题。基于先进的单元化设计理念达成核心应用N个9的可靠性也是IT管理者面临的难题。最后，服务SLA（ServiceLevelAgreement,服务水平协议）的达成还需要有相匹配的管理手段与工具，如故障模式库、演练工具等资源作为支撑，不但要能有效跟踪度量SLA的实际效果，还需要持续、主动发现可用性风险的机制与工具，在可用性管理的过程中实现数据积累和能力演进。挑战2：有效进行全链路可视监控随着主机上云和业务云化转型的持续深入，分布式数

据库、中间件、AI、大模型等各种云原生技术被广泛应用。新服务、新技术的迭代加速，犹如一柄双刃剑，在助力业务快速发展、快速创新的同时，也带来了系统技术栈复杂度的急剧提升，给传统的IT运维方式带来巨大冲击。例如，应用的微服务化改造，带来微服务数量的指数级增长，应用的调用层次和调用关系变得冗长；分布式云原生的深度应用，使得业务链路更加复杂。当上层业务应用出现故障时，排障过程可能涉及从应用到网络的完整链路，这其中包含业务应用、云服务实例、云基础设施和服务器、网络、存储等物理设备。典型的业务流量路径如：应用>容器>PaaS拟机>服务器>虚拟网络>物理网络。在针对这个路径的运维实际工作中，应用、虚拟机软件提供方、服务器和网络设备提供方常常是各管一段，整个业务从上到下的全栈调用路径往往是个黑盒，导致故障定位定界困难，或者恢复时长无法控制。面对IT系统复杂的技术栈及海量的运维对象，做到软硬件运维对象的统一管理，指标、告警、日志、调用链、拓扑等运维数据的统一汇聚和分析，构建全链路故障感知、全栈故障可视的运维体验，对于金融主机上云过程中的运维工作至关重要。挑战3：云网深度融合，如何快速发现、定位、恢复问题过去一年，在互联网领域发生过多起颇为严重的宕机事故：2023年3月，某互联网服务商发生机房故障，多个互联网核心应用受到影响，事故持续7个小时，影响约十几亿用户。2023年11月，某云服务商旗下多款应用出现无法登录故障，事故持续4个小时，这是该云服务商时隔一年之后第二次出现严重故障。2023年11月，某互联网服务公司核心应用业务瘫痪接近12个小时，流失千万订单，直接损失上亿元，引发了广泛的社会关注。总结上述这些事故，它们都具备了如下几个特点：事故影响范围巨大，社会反响强烈，更有甚者还会对社会的衣食住行产生严重影响。事故影响时间较长，业务恢复周期以数小时计，严重者故障恢复时长达到了12小时。造成巨额经济损失，负责人被处分、问责。随着上云进程的逐渐深入，金融企业开始将核心应用搬迁上云。核心应用一般有着规模大、分布式、架构复杂等特点，这一点和互联网业务非常相似，上述互联网的故障也在时刻给金融核心应用的运维敲响警钟。在此背景下，近年来金融领域客户提出了核心业务的“1-5-10”目标，即：1分钟发现故障、5分钟定位、10分钟恢复。要实现这个目标必须要解决以下关键问题：如何尽可能地少出问题首先，需要有一个完善的运维规范和流程来保障运维流程合规；其次，核心应用需要全局的高可用设计，从架构层面避免单点故障；最后，企业还应具备完善的风险管理体系，可以对识别到的风险举一反三快速闭环，持续提升核心应用的韧性。如何快速恢复故障基于核心应用黄金指标的秒级故障感知是故障恢复的前提；基于调用链分析、日志解析、云服务实例快速诊断的分钟级故障定位是故障恢复的基础；基于应急处理预案的一键式故障恢复是行之有效的手段。

如何解决云网络问题在云网络和物理网络深度融合的场景下，应用级的网络可视、云网络端到端的故障探测是解决云网络问题的关键所在。挑战4：如何应对运维安全与租户安全的双重挑战主机上云的过程中，应用与云平台的运维会同时受到运维安全和租户安全的双重挑战。在运维安全方面常见的挑战包括：运维安全意识不足运维管理者缺乏对运维安全的完整规划，在制度、流程和技术规范方面缺少对变更的严格管控。在缺乏对变更的严格审控机制的情况下，随意的变更为引发后续事故埋下了隐患。运维安全管控的技术手段不足主要表现为，对运维操作入口没有进行技术管控，缺乏对运维操作过程的有效监管，缺乏对高危操作的拦截，缺乏对运维操作的记录与审计，缺乏识别恶意操作的评估手段。权责不匹配运维人员的权限过大或者超越自己的职责范围，很容易引发超出职责范围的误操作，从而带来不必要的运维风险。在租户安全方面的挑战包括：安全攻击无法避免希望一劳永逸地解决租户安全问题是不切实际的。人类的操作永远无法做到完美，系统和技术总在不断演进，新的漏洞会不断出现，完全消除漏洞是不可能的。所以，0日攻击、钓鱼攻击以及账户被破解都无法被避免。租户安全防护难以全局统筹现代企业和组织的网络环境越发复杂，涉及众多设备、应用、数据类型。同时安全威胁也在不断演变，包括网络攻击、钓鱼、木马、病毒、社会工程学攻击等多种形式。安全团队需要同时跟踪多种威胁情报，及时调整安全策略和措施，以应对各种各样的威胁。安全威胁处置缓慢安全威胁普遍具有隐蔽性强的特点，不易被及时发现。现代安全威胁越来越复杂和多样化，攻击手段和方式不断演变，安全团队需要花费更多时间来分析和

理解威胁的本质，以制定有效的处置策略。有时候安全团队还会面临技术上的限制，从而需要花费更多时间来研究和实施解决方案。在实际业务场景中，由于安全管理不善造成重大事故和业务损失的案例并不鲜见，如误删数据库账户造成结算业务失效，误删虚拟机造成业务中断，租户权限管理不当误删OBS桶等等。云化、集中化虽然提升了业务的创新速度，也让运维安全的管控以及租户安全的治理变得更加复杂，所以运维安全是业务可靠性保障的基石，也是运维现代化的基础。主机上云运维现代化核心能力主动预防运行稳定主动预防运行稳定安全可靠1.2.3.存贷款存贷款支付结算现金管理理财管理资金交易中间业务消费信贷全链路运维监控确定性故障恢复全链路运维监控确定性故障恢复预见性风险治理全链路可观测云网定位定界主动风险预防面向应用运维故障精准诊断变更风控管控极简信息汇聚一键故障恢复混沌工程演练高可用架构设计智能化应用运维高可用SLA规划运维数据治理应用高可用设计可用性指标构建持续高可用治理运维故障分析全视角运维安全体系化安全运营用户授权可控制立体防御体系作业过程可信赖主动智能安全潜在风险可识别全面安全运营主机上云新基座应用平迁上云应用改造上云核心重构图2.1运维现代化三大核心能力平台运维现代化平台运维的现代化转型重点要考虑如下三方面的能力建设：全链路运维监控核心业务上云的过程中，云与应用的耦合度逐步提高，应用与云平台的关系愈加复杂，因而云运维必须实现应用到云平台乃至物理设备的全链路覆盖。同时需要梳理出应用与云平台间的依赖关系，当应用出现故障的时候能够基于应用的视角快速感知和诊断故障。确定性故障恢复快速创新的金融业务场景增加了云平台技术栈复杂度，也因此提升了故障定界、故障快速恢复的难度。

华为云给出了通过全链路检测、故障模式库和云网结合快速定界故障的思路，以此提升核心应用上云后云平台故障恢复的确定性。预见性风险治理实现风险的提前感知与预防始终是运维管理者长期的期望，也是运维人员一直面临的难题。这个问题同样摆在华为面前。在十多年运维工作中，华为云通过大量项目实践摸索出了一套预见性风险治理的思路，不但覆盖了运行时的风险治理，也覆盖了对变更的风险治理方法，以及对未知风险的识别与预防手段，本文将详细阐释通过数字化到自动化的转换实现云平台风险预见性治理的思考。10应用运维现代化只有打破各个工具间的数据孤岛才能统筹洞察应用的完整运行态势，对应用进行全方位的监控与分析。在本文中，华为云提出要将应用的可靠性保障前置到设计阶段，通过高可用设计提升应用的可靠性，同时也给出了应用高可用设计的思路，帮助金融企业选择合适的高可用方案平衡成本与效益的矛盾。安全运维现代化运维安全是保障业务可靠性的基石，也是运维现代化的基础。在运维安全领域需要通过对运维过程无死角的安全管控来保障运维安全，具体来说，需要实现事前对权限的有效规划和管理，事中对运维操作的严格管控，以及事后对运维操作的审计与分析，减少由于运维误操作给云业务带来的风险。除了云平台本身的安全保障，在租户安全维度，也应构建完整的安全防护体系，端到端保障云租户的安全。平台运维现代化核心能力全栈感知能力从应用视角到平台视角，构建全面的指标体系，快速感知故障核心应用部署上云，从上到下可以分为四层，分别为终端层、应用层、PaaS实例层和IaaS基础设施层。如下图：终端层严格意义上并不在云上部署，主要部署在端侧，通过APP或者浏览器实现应用访问；

应用层通过在容器集群、弹性云服务器、裸金属服务器上部署复杂的应用，实现某些业务功能；PaaS实例层主要是指云平台提供的容器集群、中间件、数据库等实例资源；IaaS基础设施层主要指提供计算、存储、网络的基础资源池，如云数据中心的存储池、虚拟网元、计算资源池或者传统数据中心的服务器、网络设备、存储设备等。订单处理2msELB102msapi-gwcache-mgrAPP APP APP订单处理2msELB102msapi-gwcache-mgrAPP APP APP200ms102ms102msRabbitMQ数据库product-mgrRedis缓存 容器节点 云硬盘 云主机宿主机 网元存储池 宿主机宿主机网元存储池 宿主机物理主机网元存储池终端层应用层120msuser-mgr102msMySQL10实例层层paaslaas云数据中心1 云数据中心2 传统数据中心实例层层paaslaas图2.2典型云上应用部署模型构建核心应用可观测体系，需要根据应用部署层级分别进行设计：终端可观测终端层需重点关注用户的使用体验，采集终端应用运行报告、访问成功率、接口延时等体验类指标，通过终端内置的软件工具包(SDK)上报到应用可观测平台。必要时需要部署一定数量的云拨测终App/ServerApp/ServerKit边缘网络AccountkitAudiokit…Internet/骨干网&CDN

端，对应用进行周期性拨测，快速感知边缘网络故障。终端层常见指标举例：APP用户搜索耗时、用户下载速率等表征最终用户体验的指标量消耗等应用可观测应用层需要根据应用的核心功能，构建表征功能健康度的黄金指标。不同应用功能存在差异，梳理出的指标不尽相同，指标越能精细表征健康度，越能快速感知故障，反之亦然。以某互联网视频应用为例，需要基于应用接口日志定义接口请求量、接口成功率、接口时延、播放卡顿率等指标，针对指标数据进行治理，最终呈现不同时间维度的视图，同时支持针对流量的趋势进行动态阈值调整，准确产生指标告警。APP体验指标API性能指标APP体验指标API性能指标边缘网络指标下载成功率API时延带宽安装成功率调用量流量首页打开耗时成功率速率首页图片耗时…CDN用户搜索耗时……APP...视频分类请求结果...时延1.0.1长视频成功301.0.2短视频成功501.0.1短视频成功351.0.3长视频失败40维度：APP版本、视频分类度量：请求结果标识、时延 视频登录请求次数维度：APP版本、视频分类度量：请求结果标识、时延 视频登录请求次数视频登录请求成功次数/视频登录请求成功次数 视频登录请求次数 视频登录请求成功率 长视频登录请求成功率逻辑主体基础指标派生指标指标叠加公式组合指标派生组合指标XX（%）长视频登录请求成功率XX（%）视频登录请求成功率X（次）视频登录X（次）视频登录请求次数应用指标定义完成之后，还需要构建应用全链路拓扑视图，发生故障时，能够在拓扑视图中直观呈现，运维人员可以从多个维度快速感知故障影响范围，并对故障进行简单定界。全链路拓扑一般可以分成应用调用拓扑和网络流量拓扑：-应用调用视图：基于APM(applicationperformancemanagement，应用性能管理)调用链能力，追踪应用进程内部的函数调用路径，用于跨线程和异步场景故障感知。-网络流量视图：基于eBPF(extendedBerkeleyPacketFilter)内核组件和网络报文染色能力，无侵入式覆盖网关、基础服务、网络路径、跨语言服务场景的故障感知。应用调用视图应用调用视图33calls|120msuser-mgr31calls|102ms31calls|102ms31calls|102msMySQLapi-gw133calls|200ms31calls|102ms503calls|568msRabbitMQ29calls|1014mscache-mgrproduct31calls|102ms-mgrRedis0%/8us0%/10usapi-gw 3%/20usGuestOSGuestOSRabbitMQ网络流量视图网络流量视图subnetELB源端subnet目的端subnet VPC源端目的端0%/15us0%/8usvSwitchELB源端0%/8us0%/8us0%/15usvSwitch0%/15us0%/8us0%/8us0%/8us0%/15us目的端vSwitchvSwitch源端目的端图2.5全链路应用拓扑视图PaaS实例可观测云平台通常能够提供丰富的PaaS实例，如容器集群、消息队列、数据库、分布式缓存、分布式事务等中间件，这一类PaaS实例由云平台侧提供开箱即用的SLI(servicelevelindicator指标)，通过API或者监控对接等方式接入到应用运维平台。此类指标以云平台提供的客户可感知的服务实例为中心，直观体现实例状态的监控指标，与实例类型强相关，通常以业务请求消息统计的形式获取对应指标。PaaS实例SLI指标体系建设遵照VALET原则构建五个维度的指标：-Volume(容量)：是指服务承诺的最大容量是多少，如数据库连接数、容器集群可用节点数等。-Availablity(可用性)：代表服务是否正常，如实例主备状态、实例可用副本数量等。-Latency(时延)：代表响应是否足够快，如分布

式数据库的长事务、慢SQL执行等指标。-Error(错误率)：代表执行某一业务的错误率是多少，如分布式缓存高危命令、大Key使用等指标。-Ticket(工单)：代表某一功能是否需要人工介入，人工介入越多，可用性越差。容量可用性工单实例SLI指标容量可用性工单实例SLI指标延时错误率云服务（索引功能点功能平面VALET类别指标名称指标单位指标周期监控方式阈值规则重复次数影响说明DCSDCS实例可连接性数据面可用性DCS实例连接使用率%1分钟服务监控连接使用率大于90%查询过去1分钟内为一个统计周期，至少3次检测连接使用率达到95%。3上述指标表征DCS实例连接使用率情况，超过使用率可能导致实例新建连接失败，可用性产生异常。DCSDCS实例可连接性数据面延时DCS实例命令时延毫秒1分钟服务监控查询过去1分钟内为一个统计周期，每分钟统计的最大时延超过10ms，连续三次上报告警。3实例命令时延过长，阻塞后续命令执行，影响实例功能。DCSDCS实例可连接性数据面错误率DCS实例使用规范性布尔类型1分钟告警查询过去1分钟内为一个统计周期，存在高危命令、大Key使用的告警。需要考虑告警聚合策略。1高危命令、大Key使用可能影响实例可用性。图2.7基础设施可观测IOPS类指标可通过公共能力统一提供。

综上所述，构建核心应用的可观测体系，应该从业务应用视角到云平台资源视角进行分层设计。应用视角主要包含终端层和应用层，基于应用的核心功能，由业务开发人员、运维人员、测试人员组成“铁三角”共同设计。云平台资源层主要包含PaaS层实例和IaaS层基础设施，由云平台提供开箱即用的标准SLI指标，应用指标和资源指标汇聚接入到应用可观测平台中，由应用可观测平台统一对外呈现。终端体验类指标应用黄金指标应用请求成功率应用请求吞吐量端侧体验类拨测端侧运行监控端侧可观测终端体验类指标应用黄金指标应用请求成功率应用请求吞吐量端侧体验类拨测端侧运行监控端侧可观测日志指标事件应用可观测日志指标trace事件实例可观测日志指标事件基础设施可观测日志指标事件终端应用业务应用视角APP移动端浏览器拨测云拨测运营数据业务数据JS错误异常分析用户旅程业务应用全局拓扑链路追踪业务应用全局拓扑链路追踪代码级诊断Profiling多语言接入云实例可用性指标实例可连接性实例读写时延实例状态云服务实例容器集群可观测云实例可用性指标实例可连接性实例读写时延实例状态云服务实例容器集群可观测中间件可观测集群监控Pod监控RDS节点监控网络监控缓存基础设施指标CPU利用率内存利用率网络带宽使用率存储IO使用率资源池基础设施指标CPU利用率内存利用率网络带宽使用率存储IO使用率资源池平台资源视角管理虚拟机操作系统主机存储网络

应用可观测平台

图2.8四层指标体系极简信息汇聚，一站式触达运维态势，提升运维体验和故障处理效率如前所述，金融客户在日常运维信息的获取上，存在两个关键痛点，一是运维体验围绕功能展开，对运维对象的操作需要在不同界面来回切换，体验不畅；二是信息分散，比如描述状态的告警指标信息、用于定位的日志和调用链信息、各类操作的状态信息需要从不同的运维界面上获取，导致故障处理效率低。因此需要持续构建极简信息获取的能力，使运维人员可以快速获取所需的运维态势信息，从而提升运维体验和故障处理效率，进而解决企业运维要求高和运维能力不足的矛盾。极简信息获取的设计理念信息集约：面向运维对象进行运维操作功能的体验设计，例如，在同一个操作界面上集成运维对象的状态信息、组件关联、操作维护等信息。对象关联：围绕同一个运维对象，可向下关联依赖的容器、物理设备等底层资源信息，向上关联被依赖的应用组件信息，从而快速获取与该运维对象相关联的运维信息。逐层下钻：在呈现运维状态信息时，界面应围绕运维对象关系，展示逐层下钻的内部组件和依赖资源相关的分析信息，以便逐步逼近问题根因。一致体验：所有被管理对象都有一致的全景360视图体验，从一个关联对象可以一键跳转至其全景360监控信息界面。极简信息获取的目标效果运维信息展示要能够围绕运维对象进行汇聚，使运维人员可以方便且快速获取需要的运维信息。对象状态一屏概览：被管对象概览界面，要能够展示对象关键信息，包括基本信息、告警、关键指标等内容。

监控汇聚状态可视：展现被管对象及内部组件的告警信息。基于告警可以快速感知对象的异常状态；此外，运维平台还应支持查看被管对象及内部组件的指标信息。拓扑关联故障定界：展现被管对象与内部组件、底层部署依赖、周边调用依赖等关系的拓扑图，并在拓扑图中展示各个对象的告警状态。创建的拓扑应包括应用的物理拓扑、云服务物理拓扑、云服务部署拓扑等。通过对关联对象的异常状态分析，可以支撑运维人员进行故障定界。组件分析逐层下钻：故障定界定位犹如抽丝剥茧，极简运维要支持从故障表现的点开始，对齐内部组件和依赖资源，逐步、逐层进行下钻分析，一步步接近问题根因。操作维护快速直达：集成被管对象的常见操作，如自动作业、节点诊断、拨测等，在日常运维和故障处理时，能够快速完成操作。实现确定性故障恢复确定性故障恢复需要从应用系统视角和云平台资源视角分别定义。基于云服务故障模式基线库，对云服务实例进行全面诊断，以便精确定位、快速恢复故障应用可观测平台感知故障之后，通过指标的汇聚和算法处理，可以对故障进行初步的定界，输出可能存在故障的资源实例，此时需要云平台具备针对资源实例端到端的精确故障诊断和快速恢复能力。实现资源实例的诊断，需要大量的运维专家经验，从实例的资源、依赖、历史故障模式等多个维度进行分析，因此，构建云服务的故障模式库至关重要。故障模式库生成机制故障模式库是在产品设计阶段，对构成产品的组件进确定分析对象建立框图描述系统功能定义严酷等级故障模式清单确定分析对象建立框图描述系统功能定义严酷等级故障模式清单白盒化的故障模式分析：端到端梳理组件架构，根据组件在架构中的位置，分析可能的故障点。梳理云服务核心功能，并和组件架构有机结合，以实现对某一核心功能对应故障点的可视化呈现。此外，还应规划对应故障点的自动化诊断、一键式恢复能力。黑盒化的功能性拨测：包括关键进程和端口的探测、网络组件交互性拨测、及AA集群流量负载均衡的诊断。现网历史故障补充：基于产品组件在现网中的历史重大故障进行逆向覆盖，确保重大质量问题全覆盖，改进措施对应指标可诊断。可使用系统级FMEA(failuremodeandanalysis，失效模式及效应分)故障模式分析流程持

FMEA分析FMEA分析图2.9系统级FMEA故障模式分析流程续积累故障模式库。故障模式库的推广机制梳理故障模式库只是故障处理的一种手段，让站点能够基于故障模式库快速诊断、恢复故障才是最终目的。因此基于故障模式库中定义的每一种故障模式都需要开发对应的内容包，内容包中应至少包含一套诊断脚本和一套恢复脚本。故障模式内容包应该与产品解耦，既可以集成到产品中支持新建站点的开箱即用，又可以单独发布支撑存量站点的持续迭代更新。针对一类服务的某个核心功能的故障模式库梳理针对一类服务的某个核心功能的故障模式库梳理产品对象故障模式描述云服务名称核心功能点故障对象 故障模式故障影响严酷等级观测方式应急恢复措施分布式缓存Redis访问Redis实例 实例状态异常影响业务访问RedisI类实例状态异常告警实例重启分布式缓存Redis访问Redis节点 节点状态异常影响业务访问RedisI类实例节点异常告警实例节点重启分布式缓存Redis访问Redis实例 实例拒绝连接影响业务访问RedisI类监控实例活跃客户端连接数超规格调整实例最大连接数故障模式适配包开发├─故障模式适配包开发├─resource_{云服务索引}_{version}.zip #故障适配包alarm ││├─{云服务索引}_alarm.json #告警静态信息monitor script config.json {script} operations actions.json i18n autoops operations flows i18n 故障模式适配包推广十统一适配包故障模式适配包推广十统一适配包开箱即用新建站点运维治理包持续迭代存量站点故障模式内容包故障模式库运行机制状态诊断脚本状态诊断脚本状态诊断脚本状态诊断脚本状态诊断脚本信息收集脚本信息收集脚本信息收集脚本局点运维人员快速恢复脚本快速恢复脚本快速恢复脚本XXX服务关系数据库服务分布式缓存服务自动作业指标监控告警监控图2.11故障模式库运行机制自动作业指标监控告警监控图2.12一键式故障诊断恢复示例云网一体化运维实现应用、虚拟链路、物理路由的一致性监控和运维云网一体化运维是指将云计算与网络技术相结合，对云计算环境中的网络资源进行统一管理和维护的一种模式。在这种模式下，网络管理员可以通过云计算平台提供的工具和接口，对网络资源进行实时监控、故障排查、性能优化等操作。云网一体化运维的实现依赖于云平台和网络设备的协同工作，云平台需要提供相应的API接口，以便管理员可以访问和操作网络资源，同时网络设备也需要支持相应的功能，如网络监控、故障诊断、流量分析等，以实现对网络资源的有效管理，从而实现云上Overlay资源与Underlay网络设备的统一运维。云网一体化运维通过如下两个机制实现高效监控与问题定位：应用网络真实业务流一屏监控：主要通过eBPF应

心功能实现。虚拟&物理网络可视诊断定界：主要通过Cloud-NetDebug虚拟网络拨测和FabricInsight物理网络定界两大核心功能实现。（一）应用网络真实业务流一屏监控1）eBPF应用端点无损监测eBPF是一种在Linux内核中运行的虚拟机，它允许用户在不修改内核源代码的情况下，动态地加载和执行代码。eBPF最初是为了网络数据包过滤而设计，已扩展到其他领域，如安全、跟踪和性能分析。eBPF试和排查。具体的实现机制是：eBPF注入到应用内核中并挂载到特定钩子(hook)挂载点上。当内核或应用程序执行到某个挂载点时，产生特定事件并触发程序运行。eBPF技术的代码无侵入、语言无关、高性能、强关联、数据端到端覆盖等特征，可满足可观测性标准和观测数据采集的要求。BPFBPFProgramReaderLLVM/ClangLLVM/ClangProg.bfp Userspacebpf KernelbpfeBPFBPFMapsBPFBytecodeKernelFunctionsNativeCodeVerifier+JIT图2.13eBPF挂载原理

基于eBPF内核观测技术生成的网络级丢包、时延、吞吐量等方面指标，可以实现流级的应用路况可视化监控能力。应用访问拓扑可视：访问关系图、访问量、访问时间应用网络质量可视：重传、拥塞、0窗口2）iFIT真实业务流链路监测IFIT(In-situFlowInformationTelemetry)是一种用于网络流量监控和分析的技术，可以实时收集网络中数据包的元数据信息，如源地址、目的地址、协议类型、源端口、目的端口等，及数据包的时间戳。通过分析这些元数据信息，可以了解网络中流量的实时情况，识别流量模式和趋势，检测异常流量和故障，从而实现网络的智能运维。iFIT主要基于在被检测业务流报文中添加iFIT检测头，实现随流的业务质量检测，反映业务流的真实业务质量。R1(Source)

1588v2/G8275.1

R2(Destination)00110011111000000T:染色周期

Tx[i]

Rx[i+1] Rx[i]110000 1 1 1 0 10000 1每周期统计点后移，屏蔽乱序干扰：T+6T/10，后移6T/10时点流性能测量)染色机制，iFIT染色报文带内测量技术可以构建流级的网络路况追踪和诊断能力，实现基于包粒度的真实业务流全链路检测。这项技术具有以下几方面特点：支持多种业务场景：L3VPN/EVPN/SRv6/SR-MPLS/MPLS易部署运维：头节点按需定制，中间/尾节点一次

部署，自动按需E2E/逐跳检测丢包位置：基于每节点的报文计数，分析丢包点逐跳时延/抖动：基于每节点的时戳记录，分析链路/节点时延路径还原：基于每节点上报信息，呈现业务真实路径图2.15iFIT业务流监测实例如图所示，实例中实现了网络丢包、时延、抖动、带宽等真实业务流路径的可视监控。（二）&物理网络可视诊断定界1）CloudNetDebugCloudNetDebug是面向运维人员的虚拟网络诊断工具，帮助网络管理员和开发人员快速诊断和解决云网络中的问题。通过收集和分析云网络中的数据包、流量和性能指标等信息，提供全面的视图，使用户能够快速定位和解决网络问题，包括数据包捕获、流量分析、集成拨测和抓包、性能监测和故障排查等。通过客户报文模拟拨测，应用报文抓取等方式，实现可视化拨测快速诊断定界。正常周期拨测---覆盖所有链路正常周期拨测---覆盖所有链路CNA1vRouter1①CNA2 交换机1 vRouter2 交换机3 ··· ··· ··· ··· ···BMSGW1交换机2ENAT1交换机4BMSGW2预置探针ENAT2出现故障场景---自动汇聚告警CNA1vRouter1②CNA2···交换机1vRouter2···交换机3······BMSGW1交换机2ENAT1交换机4BMSGW2预置探针ENAT2···图2.16CloudNetDebug拨测原理软件拨测定位是利用染色标记技术主动拨测抓包，通过跟踪染色报文经过的路径，覆盖资源(IP)>虚拟交换网络>物理交换网络进行全景网络拓扑的可视化拨测诊断。实际应用中，有如下两种监控诊断模式：FullLink全链路诊断：进行全链路复杂流量叠加场景的网络问题定位。通过控制面诊断租户的云服务配置、路由表、安全组和网络ACL等配置，检测每个网元的时延和丢包率实现虚拟网络诊断。

物理网络诊断通过调用FabricInsight的接口获取业务流路径指标，包括流状态以及交换机异常信2）FabricInsight物理网络定界FabricInsight是一种用于物理网络分析和监控的工具。这个工具支持实时监控和警报，帮助用户快速发现和解决问题，更好地理解和管理他们的网络链路系统，还提供了丰富的分析功能，帮助用户深入了解网络的性能和行为，并识别潜在的瓶颈和优化机会。此外，FabricInsight工具还支持多种物理设备组网的管理、控制和分析，支持网络仿真校验及虚拟感知，支持NetConf，OpenFlow，OVSDB，SNMP等协议，从而实现物理和虚拟网络设备的可视化管理。网络路径网络路径设备KPI故障风险TCPSYN/FIN/RST报文采集丢包/时延变更检测逐跳真实路径还原网络路况分析TCP连通性分析关联逐跳故障分析VMVMVMVMVMVMVMVMVMVM逐跳配置变更检测VMVMVM自动输出故障定位结论图2.17FabricInsight物理网络故障定界硬件诊断定位是通过业务物理路径指标，包括流状态以及交换机设备故障、链路故障、转发过载等，实现业务流路径物理网络端到端路径的可视及异常定位。Fabric内业务流路径可视：通过关联分析逐跳设备信息感知故障断点，故障一键式诊断，定位网络路由、策略类故障根因。质差主动发现：基于网络路况开放，实现应用网络协同，通过技术分析微突发、丢包、光模块异常等现象快速定界定位问题。预见性风险治理预见性风险治理是一种前瞻性的风险管理方法，旨在通过事前的预测和诊断识别潜在风险，提前制定风险消减措施，保障系统的稳定运行。根据风险场景，预见性风险治理主要分为运行态风险预防，变更风险控制和未知风险挖掘三部分内容。运行态风险预防：建立完善的运行态风险主动预防体系，定期进行风险评估和监测。通过收集和

分析指标、日志、告警、配置、容量等运维数据，从风险隐患、性能规格、系统容量、系统可靠性、最佳实践、版本生命周期、安全漏洞等多个维度对系统进行全面的评估。变更风险控制：通过建立变更前的风险识别和评审机制，提前识别变更的潜在风险；通过自动化及渐进式的变更过程，确保变更不引入风险。未知风险挖掘：通过混沌工程识别系统的薄弱环节并改进，持续提升系统韧性。变“被动救火”为主动预防，构建运行态风险主动预防体系面向未来，“被动救火”式运维将成为过去式，主动运维将成为保障系统高可用的重要手段《史记》曾载，魏文侯问扁鹊“你们三兄弟谁的医术最为高明？”扁鹊言“长兄最善，中兄次之，扁鹊为下。”文侯好奇道“何出此言？”扁鹊答“大哥治病，常以望闻问切，诊断隐患，在病害形成之前就能铲除病因，因此一般人不知道大哥的厉害，是以声名不显。二哥治病于初起之时，大家以为他只能看看小病，所以他只闻名于乡里。而我治病于严重之时，用针刺猛药，救人于危机之时，所以大家都以为我医术最高明，因此名传天下。上工治未病，扁鹊长兄治病于未发，是为事前；中兄治病于渐发，是为事中；扁鹊治病于严重，是为事后。治病如此，运维亦是如此。运维的核心目标是保障业务可用，减少和避免故障发生。传统的救火式运维，运维人员的工作内容和工作重心往往聚焦在事件和故障处理，偏向事后，这种运维方式无异于减少和避免故障，无法满足现代化云运维的要求。从故障事前、事中和事后的角度看，事后恢复不如事中控制，事中控制不如事前预防。因此，必须摒弃传统的救火式运维，变被动为主动，预防和减少故障发生，防患于未然。建设金融云风险主动预防体系，实现站点故障早发现主动运维并不是一个新鲜的概念，但在大部分的企业中，主动运维仍是一句口号，对于一个云平台，如何能让主动运维真正落地并产生效果？本质上来讲，主动运维的目的在于事前预防，治病于未发是关键，因此需要重点构建事前的风险识别和预防能力。1986年，美国挑战者号航天飞机发射后发生爆炸，事故造成7名宇航员丧生，发射活动以失败告终。为了实现故障先预警，隐患早发现，NASA建立了航天器故障预防诊断平台，旨在提前通过诊断检查发现异常事件，保障航天器可靠运行，避免事故发生。对于云平台这种大型的分布式软件系统来说，建立风险检测预防机制同样是重中之重。传统IT系统的风险主动预防通常会以产品化的方式发布巡检工具，通过在现网部署巡检工具进行巡检来识别风险，这种方式受限于工具的发布节奏，风险无法实时更新，无法保证现网时刻都可以应用到最新的风险库。

金融云风险主动预防机制的核心思想是通过构筑中心化的风险库，从风险规则的生成、风险诊断到风险的预警推送，构筑服务化的风险主动预防能力。实施层面可按如下思路展开建设：构建中心化风险库构建中心化风险库的目的在于将风险集中管理，防止风险管理的无序和散乱。风险库的建设需遵循全面性、实时性和持续性原则。全面性：风险库需要涵盖明确的风险类型和范围，如产品缺陷、性能过载、组网非标、配置隐患、版本配套、硬件适配、安全漏洞等，确保风险范围覆盖全面，防止遗漏。实时性：风险动态实时更新，即风险从发现到入库的时效性需要得到保证，确保现网应用的风险库时刻保持最新。持续性：制定明确的风险库管理制度，包括风险库的更新和维护机制，确保风险库的有效运行和持续更新。建立风险评估机制风险评估机制是通过收集和分析信息数据，结合风险库规则来识别风险隐患的过程，其目的是为了有效地识别系统风险。风险评估机制的主要步骤包括：信息收集：收集生产环境的指标、日志、告警、配置、资源、容量等运维数据，作为风险诊断分析的数据输入。诊断分析：对收集的运维数据进行分析诊断，识别系统劣化指标，匹配风险库规则进行风险冒泡，评估风险等级及影响，输出健康度评估报告。26建立风险预警流程26建立完善的风险预警机制，通过定期的风险评估报告方式将风险预警推送到现网，确保风险信息可以及时准确地传递给相关组织。同时，提供相应的风险规避措施，持续跟踪风险在现网的闭环情况。基于变更模型提前拦截变更态风险，通过全流程自动化实现变更态风险有效控制变更风险控制是系统变更过程中至关重要的一环，旨在减少因系统变更而带来的不利影响，提高变更的成功率。随着业务数量和业务规模的持续扩大，现网的变更数量和变更频次不断增长，而频繁的变更常常会给运维带来不可预知的风险。据数据统计，70%的线上故障都是由变更引起，变更可能引起功能失效、性能下降、数据丢失甚至系统崩溃。如何有效管控变更风险，是运维工作面临的巨大挑战。面向现代化的变更风险控制能力构建可按下面思路进行考量：控制能力

变更前变更准入：建立变更准入机制，在变更申请阶段对变更的准入条件进行控制，包括变更必要性评估，标准化变更方案制定，变更影响分析，回退方案、变更授权等；风险识别：变更前对变更风险进行识别，包括变更历史问题风险、变更方案风险、业务影响风险、高危操作风险等；变更评审：变更评审阶段，由评审人对变更方案和变更风险进行评审，确保变更实施方案正确，变更影响和变更风险评估准确。变更中灰度变更：构筑变更实施阶段的灰度变更能力，按需控制变更范围，可以尽早发现并解决变更问题，有效降低变更带来的风险；风险控制：在变更实施过程中控制变更操作的风险。对于高危操作、未授权操作实施拦截，对于变更过程中的异常和非预期结果，应实施变更自动终止操作。标和告警，快速发现变更带来的非预期影响。变更后退以及按阶段、按工步的局部回退，支持灵活的回退策略制定；后通过业务拨测验证变更业务是否可用，及时发现问题。更风险提前识别首先，对不同类型的变更建立不同的变更模型，并对变更模型设定相应的风险规则，风险规则可来源于此类型变更的历史问题和专家经验，或与此类变更相关的状态、指标和配置等。此外，应建立变更模型和风险规则的关联机制，持续积累风险规则，通过工具能力自动识别风险，使得风险识别不依赖人，基于变更模型建立标准化的风险识别流程和能力，确保变更前风险有效识别。险控制有效落地流程具体来说，应建立数字化的变更流程系统，从变更申请、变更评审、变更实施到变更验证建立完善的变更流程

流程，使得变更在各个阶段都能得到有效的跟踪和控制。变更申请阶段，基于变更模型创建变更申请单，变更申请单自动获取变更模型关联的风险规则，同时根据风险规则识别变更风险。风险规则可以是特定的匹配规则或脚本，通过自动化流程运行风险规则或脚本，给出本变更所识别出的风险集合。变更评审阶段，对于变更单所识别变更风险的闭环情况进行审核，确保变更风险全部闭环，变更流程才能进入变更实施阶段。在变更申请和变更评审阶段，重点构筑变更风险的识别和拦截能力。变更实施阶段，基于工具构筑自动化变更及控制能力。工具应具备作业编排、灰度分批、高危拦截、熔断回退等核心功能。灰度分批变更典型的应用形式通常如下：产环境实施前，在灰度环境上提前实施变更，进行业务验证；生产环境分批实施：在生产环境中分批实施变更，优先选择小范围、重要性较低或影响可控对象实施变更，根据变更结果逐步放开批次。推送、闭环执行脚本/规则变更实施风险评审推送、闭环执行脚本/规则变更实施风险评审识别风险创建变更单拉取风险信息导入变更模型风险脚本/规则模型变更作业流水线变更作业流水线变更作业子流程N变更作业子流程N+1安全回滚灰度批批次1生产批批次2生产批批次2准入条件预检查准入条件预检查灰度批批次1安全回滚安全回滚工具能力工具能力模板编排灰度分批高危拦截熔断机制安全回滚生产验证图2.19典型灰度分批变更应用形式变更验证阶段，通过功能验证、业务拨测等验证手段，对变更后的业务进行可用性验证，及时发现可能的风险。持续提升系统韧性混沌工程核心思想：识别系统隐患，减少故障影响，提升系统韧性

从系统架构层面，混沌工程可以验证系统的容错能力，推动提升系统的架构可用性；测试层面，混沌工程可以提前暴露线上问题，防止带病上线；运维层面，混沌工程可以让我们更好地理解和掌握系统的运行逻辑和规律，提升应急恢复效率，降低故障影响和损失，增强团队应急能力，建立系统抵御未知风险的信心。混沌工程的实施实践混沌工程实践可以按照如下步骤开展：制定试验目标开展混沌演练之前，首先需要明确试验目标及假设，确保实验的有效性及针对性。例如，验证某应用系统在过载场景下的保护机制，假设当流量过载时，系统的哪些指标会发生什么变化，预期会有什么保护措施会触发等。故障模式分析故障模式分析是混沌工程实践的关键环节，通过6维故障分析法，从冗余、容灾、备份、过载、依赖和安全的场景输入。云平台故障场景识别xx会议系统故障场景识别lvs冗余云平台故障场景识别xx会议系统故障场景识别lvs冗余视频网关APIGnginx故障点consoleframe容灾安全前端负载均衡故障点6维故障分析法故障点视频前端web01 视频前端web02haproxyhaproxy依赖备份视频后端service 视频后端service故障点pub-dbpub-db过载故障点视频数据库DBimsapicomvpcims故障场景分析故障场景分析如图所示，6维故障分析法对于云平台和业务应用场景的故障模式分析均适用。例如，对于应用系统中的关键模块，如web前端，在业务过载场景下，分析系统是否具备限流、降级或弹性扩容能力；对于数据库，在业务过载场景下，分析系统是否具备自我保护能力等条件。制定应急预案根据故障场景，分析故障发生后的系统行为及影响，制定对应的应急预案。应急预案应包括故障的识别、影响范围确认、故障隔离、恢复验证等方面。故障演练根据故障场景实施故障注入，观察系统的行为是否符合预期，例如稳态指标观察，容错行为验证等，同时验证处置策略，恢复手段是否有效。

演练复盘进行演练复盘总结，从产品质量、预案质量和运作流程等方面识别改进点并优化。混沌工程平台构建混沌工程平是进行混沌演练的基础，完整的混沌工程平台需要具备故障模式管理、故障场景编排、故障注入、演练指挥、演练复盘等能力：故障模式管理提供丰富的故障模式库，如过载类故障、网络类故障、状态变化类故障等，基于故障模式可以构造业务故障场景。过载类故障包括磁盘IO高，CPU负载高，内存利用率高，网卡流量高等。网络类故障典型如网络丢包、网络时延、网络中断、网络错报、乱序、重复包等。状态变化类故障有kill进程、关机、重启、磁盘只读、停止服务等。故障场景编排基于故障模式和资源对象，进行故障场景的灵活编排。故障注入基于故障模式或故障场景，对资源对象进行故障注入，为系统引入错误行为。由于云上资源的多样性，故障注入需要支持各种类型的资源，包括主机、虚机、容器、数据库、中间件、进程等。演练指挥设置演练指挥中心，制定演练计划，演练排班和应急预案，演练过程全程监控。演练复盘分析演练数据，对演练过程进行复盘总结，输出演练报告，发掘改进环节并持续跟踪。演练文化混沌工程要在企业内部有效落地，首先需要认可其所带来的价值，从组织、流程、文化建设方面引导，从上到下建立混沌演练文化。只有持续例行地开展演练工作，才能持续提升系统的容错性和可恢复性，系统的韧性才能得到不断提升。

应用运维现代化靠性来源于运维与设计的融合随着核心业务持续上云，金融企业对应用高可用要求达到了5个9。业务一旦出现故障不但会影响经济效益，甚至会影响到国计民生，所以如何缩小应用故障的影响范围，保障核心业务数据不丢失就成了企业面临的头等问题。因此，应用高可用设计成为应用与基础设施现代化转型的关键。然而，单纯依靠传统的运维方式已经难以保障业务的高可靠要求，运维需要前置到设计阶段，业务可靠性来源于运维与设计的融合。业务容灾等级评估高可用设计并非单纯的技术问题，成本也是影响键。由于高可用设计需要大量的费用投入，而其产出并不能立竿见影地被直接感知到，所以对于高可用设计往往需要先解决“高可用设计成本与业务预期的冲突”问题。在投入成本方面，应用可用性要求越高，对应技术方案需要投入的成本也会越高。成本数据丢失损失成本数据丢失损失成本数据可靠性成本应用可靠性成本应用宕机损失成本业务侧期望业务侧期望当前现状平衡点当前现状数据丢失时长(RPO) 应用恢复时间(RTO)分钟 0 分普通业务 重要业务 关键业务 重要业务 普通业务图2.21高可用设计与业务冲突预期冲突分析如图所示：当RPO和RTO都为0时，对应的高可用设计成本达到峰值；相反RPO和RTO时间比较高时，对应的高可用成本也会相应降低。如果所有业务都按照最高的高可用目标建设，金融企业将面临巨大的高可用投入成本，所以在技术设计前，首先要对业务灾备等级进行评估分类。基于应用的重要程度，数据一致性要求，时延敏感性等因素可以将业务划分为“关键业务”、“重要业务”和“普通业务”三个等级，重要程度依次降低。业务容灾策略不同重要程度的业务选择不同的容灾策略：关键业务的高可用设计原则是通过应用架构改造+部署架构改造，实现数据0丢失，同城多活，异地容灾，并缩小故障爆炸半径；重要业务则需通过调整应用的部署架构（无需调整应用架构），实现数据丢失趋于0，同城主备，异地容灾；普通业务无需对应用和部署架构作任何调整，仅需进行关键数据的定时备份即可。高可用的持续治理应用高可用的保障过程是一个持续的治理过程。在经历了前期的技术选型、方案设计、方案实施和方案验证后，还需建立完善的容灾管理制度，并通过专业的高可用技术团队持续跟踪和优化业务高可用的达成情况。所以应用高可用治理还涉及容灾团队建设、容灾状态监控、容灾演练以及知识管理等一系列工作，才能真正保障应用高可用目标的达成。管理体系，实现业务故障实时感知定界

端边纵向可观测体系设计端边纵向可观测体系设计端侧监控传输指标三方服务业务指标体系搭建请求量时延业务指标体系搭建请求量时延吞吐运维数仓汇聚运维数据日志配置告警图2.22典型运维数据治理流程进于一体的开箱即用的可观测性平台至关重要。运维数仓汇聚运维数据应用运行过程中会产生大量的运维数据，包括端侧数据、拨测网络数据、实例指标数据(Metrics)、日志数据(Logs)、调用链数据(Traces)等。这些运维数据需要一个统一的运维数据仓库进行承载。运维数仓主要由数据集成、ETL、数据湖、MPPDB、数据应用等功能组件构成，典型数据处理流程如下：接入，如消息队列、API集成、SFTP集成等。数据抽取：数据接入之后由ETL对单条数据进行过滤、切分、扩展、格式化等操作，统一放到消息队列中。数据湖处理：不同的数据主体消费消息队列中的数据，完成不同的数据存储，如原始日志或者指标存放到OBS中、单条粒度数据直接入库或者通过格式定义存放到ClickHouse中、时序多维度量数据需要依据一定的数据治理规则分多个表保存在MPPDB中。数据应用：所有运维数据治理完成之后，由数据应用对数据进行API封装，提供对外统一查询接口。运维数仓数据应用数据仓库运维数仓数据应用数据仓库数据湖ETL数据集成UniQueryServer单条粒度运维数据[ClickHouse]时序多维度量数据离线数据分析单条粒度运维数据后端数据订阅分发[Kafka]日志原始文件[HDFS/OBS]单条数据过滤、切分、扩展、格式化[SparkStreaming/Flink]数据集成接入[Kafka/SFTP/HTTPS]端侧数据采集端侧数据采集APMS拨测服务EchoTest指标监控系统Prometheus日志服务LogService调用链服务NuwaTrace自定义数据图2.23应用运维数仓典型架构业务指标体系搭建业务可观测性指标是指在企业的业务层面上，通过监测、分析和理解数据，设计出来的用以表征业务运行情况、用户体验的业务指标。业务可观测性更加关注运行过程、用户旅程和客户交互等方面的可视化，从而帮助企业更好地理解业务的健康状况，给最终用户提供更好的用户体验。业务可观测性指标梳理参与角色设计可观测性指标的前提是对业务系统功能有非常深入的理解，因此应用开发人员、测试人员、运维人员组成的“铁三角”缺一不可。开发人员可以对系统功能的实现逻辑进行白盒化剖析，通过监控和日志手段在开发阶段预埋相应的指标；测试人员更多从用户体验视角设计相应的测试用

例，针对这些测试用例梳理黑盒化指标，如拨测类指标、规格类指标等；运维人员则根据运维过程中的问题持续对指标进行优化，三者相互配合，构建完备的业务可观测指标。业务可观测性指标设计步骤通常情况下，业务可观测指标体系搭建主要分成如下四个步骤：数据调研，分解业务要素指标设计人员将业务系统的功能进行拆解，梳理出业务核心功能点，每个功能点会产生的数据类型（结构化数据、日志、指标等），以及明确这些数据的作用。梳理概念模型，构建总线矩阵每个核心功能点识别之后，就需要开发人员对每个核心功能点的业务过程进行白盒化梳理，包括每个业务过程需要关注的数据维度，以及每个维度对应的字段。以互联网应用“设备登录”业务过程为例，应用需要获取设备类型、设备品牌、登录地域、登录运营商、HTTP响应状态码、业务响应状态码等维度的数据。业务过程一级设备注册业务过程二级北向设备注册一致性维度请求来源Apple设备类型Devtype品类ProductID地理区域运营商http响应码业务响应码南向直连设备注册南向下挂设备注册南向批量下挂注册设备登陆南向设备登陆设备数据上报北向蓝牙设备数据上报北向三方设备数据上报南向设备数据上报设备查询设备控制设备认证设备注销北向设备注销南向设备注销南向鸿蒙设备重置图2.24设备登录业务过程总线矩阵举例逻辑模型设计根据总线矩阵，进行数据仓库逻辑模型设计，在维度建模中，有以下一些关键概念和组件：事实表(FactTable)：事实表是数据仓库中的核心表，包含了与业务过程相关的数值型度量或指标。事实表中的每一行通常表示一个业务事件或交易，并与一个或多个维度表相关联。在实际应用时，应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。

维度(Dimension)：维度是描述业务过程的属性或特征，用于对事实进行分类和分组。维度表(DimensionTable)：维度表包含了描述事实表中度量的上下文信息，它们用于描述与“who、what、where、when、how、why”有关的事件，用于对事实进行分组和筛选的属性。时间维度表艺术家维度表时间维度表艺术家维度表维度表维度表维度表维度表维度表维度表维度表维度表事实表维度表维度表维度表维度表度量/原子指标(Measure)：原子指标和度量含义相同，是事实表中的数值型数据，表示业务过程的性能或结果，是用户在数据仓库中分析的关键指标。设备维度表设备编号DID设备内部型号设备产品传播名设备维度表设备编号DID设备内部型号设备产品传播名设备品牌设备品类…日期维度表歌曲播放事务事实表维度日期[FK]设备编号DID[FK]设备产品传播名时间[FK] 歌曲播放事务事实表维度日期[FK]设备编号DID[FK]设备产品传播名时间[FK] UP_ID[FK]歌曲代理IO[FK]歌曲名称歌曲专辑代理ID[FK]艺术家[FK]度量播放时长播放次数…账号维度表...歌曲维度表歌曲专辑维度表物理模型开发与上线物理模型开发就是在逻辑模型中填充数据的过程，填充的数据就是在总线矩阵中定义的数据，这些数据的来源主要是业务系统的数据库、日志、调用链(本质上也是日志)、指标数据等。而这些数据并非结构化数据，需要经过清洗，汇聚到数据仓库的物理表中，才能够让指标设计人员对指标进行进一步处理(如打标签或者派生指标设计)，最终完成业务可观测性指标上线。端边纵向可观测体系设计应用运维的运维对象是应用，即是将“应用”作为一个独立的逻辑实体。所有该应用所使用的资源，如VM、Docker、中间件、数据库等，都是该“应用”的组成部分。所以对于应用运维来说，构建该

应用完整的全链路监控是非常有价值的工作：可以提升故障主动发现率，减少故障对业务的影响，提高系统的稳定性和可靠性。通过逐层下钻的数据分析能力，帮助快速定位和解决问题。通过对系统的实时监测和数据分析，提供决策支持，优化系统性能和资源利用率。上一章节主要阐释了指标体系如何构建，下面介绍如何根据这些能力构建一个典型应用的全链路监控模型。App/ServerKitAccountkitAudioKit…边缘网络Internet/骨干网&CDN服务&微服务ELB Web服务器SLB App/ServerKitAccountkitAudioKit…边缘网络Internet/骨干网&CDN服务&微服务ELB Web服务器SLB 应用服务器二方/三方三方服务二方服务APP体验指标下载成功率安装成功率…API性能指标API时延调用量成功率…边缘网指标带宽流量速率CDN…APP体验指标下载成功率安装成功率…API性能指标API时延调用量成功率…边缘网指标带宽流量速率CDN…服务&微服务性能API时延中间件数据库…依赖方性能API调用量成功率…图2.28根据上图我们可以看出，一个应用要对最终用户产生价值，整个数据流是从端侧发起，经过接入侧、广域网、数据中心传输后，最终到达云上的服务端完成逻辑处理，再返回到端侧，完成一次完整的数据交互。其中在云上服务端处理的过程中，还存在与第三方外部服务调用的场景。在这个交互过程中，任何一个环节都可能影响到最终用户的使用和体验。所以对于应用的全链路监控来说，每个环节都应该尽可能地做好监控。端侧监控通常采用埋点方式完成对端侧数据的采集。端侧的指标是应用监控指标中最能直接反应最终用户体验的数据，比如打开应用的时延、访问成功率等。如果传输质量降低，云侧成功率指标可能没有明显波动，而通过端侧指标则可迅速感知。传输网络应用运维需要感知本应用在传输过程中的质量数据，比如涉及地域、线路、边缘网络加速等数据，但不必过度关注底层传输指标。网络传输过程中的质量问题往往需要与运营商或供应商协同

处理，掌握传输过程的数据有利于在协同处理中更高效地完成故障修复。由于无法在传输节点上采集数据，这部分的时延数据一般可通过云侧与端侧的指标通过复合计算得到。而边缘加速网络的数据可以通过供应商的标准监控能力获取。云侧监控应用的云侧监控除了应用黄金指标外，还应包括构建该应用的资源监控。这部分的监控数据来源于云基础设施监控能力，但要按应用纬度进行切割、汇聚，即应用看到的数据应该是以本应用为颗粒度的整体数据。三方服务指本应用之外的调用或交互。这部分数据的获取不能依赖对端服务，而应该从自己应用的调用过程中采集，例如可以通过对调用对端接口的日志进行分析的方式获取。经过多轮的业务可观测指标设计之后，就可以将指标根据业务核心功能在监控大屏中进一步呈现。图2.29业务可观测大屏展示面向故障全生命周期，全方位提升故障感知、诊断、恢复智能化水平围绕故障生命周期，构建开箱即用的一体化可观测性平台，有助于提升典型故障的故障定界、分析诊断和恢复闭环的效率。故障预防故障诊断故障诊断故障恢复故障改进自动巡检专家诊断工具 AI辅助诊断通报自恢复事后分析链路诊断DB诊断性能诊断网络诊断……链路诊断DB诊断性能诊断网络诊断……WarRoom应急预案工单管理故障生命周期管理故障处理策略管理故障模式库(VM故障/容器故障/网络故障/中间件故障/DB故障/微服务故障/…)智能运维RPA(roboticprocessautomation)智能化故障管理图2.30应用智能化故障管理流程智能化故障管理基于监控指标的智能化故障呈现在构建全链路监控后，应用运维就具备了精细化的业务指标监控能力，下一步就是要能及时感知故障。传统的异常检测基于阈值开关，这样常常会使

得阈值配置过于保守而产生大量的无效告警。为解决上述问题，可通过业务特征的曲线历史形态(周期性、徒增突降、趋势性)进行建模，从而通过动态拟合的阈值精准识别异常，1分钟发现业务故障。1据和模型超参23456xx天的历史数据123、数据平滑&插值1、周期性识别（2、波动性识别3、平稳性识别1boxplot2DSPOT3SVM 4小样本算法5、MAD…1（毛刺点）2、突变3、长时间掉零…8、存入模型7训练12推理345最近xx个点的实时数据12、数据平滑&插值126111097返回实时数据推理结果（包含测量值、阈值）123告警进入标记位、告警退出标记位8图2.31智能化感知故障建模智能化感知故障建模主要分为训练和推理两个阶段：训练：通过加载一定时期的历史数据(如一个月的历史数据)，进行异常数据剔除、数据插值、数据重采等数据预处理，识别出数据特征，基于一定的模型算法，输出训练的阈值，形成业务运行的典型模型。阈值对比，对存在异常的指标进行标记(包含窗口突变告警等异常标记)，确定最终告警标记位，进而生成最能呈现指标变化的推理结果。基于监控指标的智能化根因诊断当应用运维监控指标构建的足够完善，就可以通过智能化分析进行故障根因诊断。故障根因诊断通常有以下几个步骤：

告警聚合成事件，以最新告警和历史事件作为告警聚合的输入；并将诊断算法产生的根因记录到事件中；事件中诊断的根因结果会被用来进行新告警的聚合；智能决策引擎进行事件的总结，包括事件描述的总结、事件根因的总结等。告警告警聚合告警告警聚合调用链根因诊断多维下钻诊断事件日志根因诊断根因智能决策引擎流量溯源分析诊断事件总结智能诊断能力构建中常用到的算法有AdtributorMDRCA等，用于诊断的数据来源可以是业务黄金指标、日志、流量、调用链等等。基于作业编排的自动化故障恢复业务系统故障在运维人员得知根因的情况下，往往都能快速完成故障恢复，包括但不限于：双活流量切换、故障节点隔离、故障节点重启等等，但对于新手可能需要指导并不能独立完成。如果系统规模较大，即使是经验丰富的运维人员要完成准确的故障修复也并不容易。成熟的运维组织应该构建稳定可靠的自动化故障恢复能力。构建基于IaC(InfrastructureasCode，基础设施

即代码)的自动化部署能力，可以通过IaC对现网资源和配置进行基线化管理，以便在任何需要的时候快速完成基线变更，这样不仅能快速完成现网故障恢复的变更操作，也可以极大地降低频繁变更引发的人因风险。故障根因修复手段是不断迭代积累的过程，如果要能快速不断完善针对应用的自动化恢复手段，还是需要一套较灵活的流程编排和脚本作业工具。脚本作业可以通过shell或python快速构建故障修复的原子能力，而流程编排可以调用这些原子能力，以及结合应用的监控、告警、诊断结果等数据，构建起完整的故障恢复流程，当故障发生时使用这些编排好的流程，即使是新手也可以快速完成故障的修复。资源声明配置声明环境声明资源声明配置声明环境声明状态声明···laC执行灰度控制灰度评估自动化部署灰度升级配置变更自动化部署灰度升级配置变更资源变更XaC声明自动化执行AIOps智能底座···流量预算算法健康评估算法可观察性数据事件数据自动化结果评估服务状态评估结果验证自动化评审准入评审事件评估DryRun风险评审高危操作爆炸半径开始开始completeandresult().result.Status!=0completecompleteandresult().result.Status!=0completecompletecompletecomplete结束回调器step18回调失败step15执行失败发送消息step3开始自动修复告警回调器step16回调成功step17清除告警step11确认告警查看step查看ipstep14执行成功图2.34安全运维现代化随着金融业务上云从一般业务扩展到核心业务，云平台安全管控面临的复杂情况增加。这些新的情况都让金融云的安全面临着前所未有的挑战，例如：传统的安全威胁主要来源于数据中心外部，在边界作好防护就能解决大部分问题。而在金融云场景下，租户间网络边界从物理边界变为虚拟网络边界，防护边界变的模糊。此外，云平台的安全边界还会随着云租户数量和规模的扩展或调整而发生动态调整；安全攻击不仅有可能来源于数据中心外部，还可能来源于内部的社会工程、钓鱼软件、恶意植入、权限滥用、数据窃取等安全威胁；攻击点的多样性需要不同安全防护工具来应对，因而，安全威胁会在不同安全防护工具上以不同的形式显现出来，如果安全工具间不能很好协同，安全威胁防范的效率将无法保证；不仅云主机、容器、云内数据需要安全防护，云原生应用和API也需要进行安全防护。此外，在复杂性快速上升的云租户安全防护场景下，仅仅被动响应安全威胁已经无法满足安全运营的要求，主动安全势在必行。面对这些新的挑战，整体上应从运维安全体系设计和云安全运营两大层面进行面向现代化的能力构建。云运维安全堤坝在云运维领域，由于运维安全设计不周或能力不足造成的事故不胜枚举，如由于管理员和租户权限设置不当造成误删除存储或虚拟机，由于变更过程缺乏管控造成误配或业务冲击，由于高危操作缺乏管

控造成数据误删等等，这些事故往往会造成业务中断，给企业造成重大损失。运维安全不仅需要从意识层面重视，更重要的是从管理到技术两个层面制定保障机制，实现运维过程事前、事中、事后端到端的安全保障。事前布局在传统IT网络中，运维主管通常主要关注对管理员权限的统筹规划与管理。在深度用云的时代，云服务越来越多，业务场景越来越多样化，更多的场景要基于云服务、基于租户操作进行授权，而不再是传统的按照资源进行授权。因此，金融云场景不但对管理员权限规划提出了更高的要求，也需要实现对租户权限的统筹管理。具体来说，金融企业需要建立统一的权限管理制度和规范，建立运维权限分配指导和审核制度，无论运维管理员还是租户，都应该按照“权责匹配、最小授权”的原则进行权限规划。同时，需要建立完整的账户权限分配、账户提权、权限回收、密码策略与权限审查机制，保障权限管理的持续有效。权限管理除了在规范和制度上进行约束外，还应当将权限管理落实到工具上。在工具上实现按云服务、资源、租户、操作等多维度组合授权，也就是说，将云服务、资源池、租户和具体操作权限分别当成一个独立维度，账号的实际权限为几个维度权限的交集，这样才能精确匹配账号的职责，实现最小授权。事中管控除了对权限进行管控外，对运维操作过程也需要进行严格管控。重点需要关注的操作有如下几方面：云管或堡垒机进行，避免任何不受控变更的发生；回收所有内部特权账号，并定期修改特权账号口令；所有操作均需要通过审核并在变更窗口期内对账户进行提权，窗口期过后权限会被回收；在配置变更过程中，管理员输入的每个命令行和回显都会被记录归档，用于后期审计与回溯；云管和堡垒机均需实现对高危命令的拦截，避免误操作带来灾难性损失；变更审核时对黑屏操作进行管控，逐步减少黑屏操作的频次，牵引变更操作通过自动化脚本完成，便于变更前验证以及后续复用。总之，通过合理制定和落实事中管控的一系列手段，可以从技术上最大限度