2024年主机上云运维现代化核心能力白皮书-华为-46正式版

践行深度用云主机上云运维现代化核心能力编制委员会主

编

单

位

华为云计算技术有限公司编

委

顾

问

尚海峰胡玉海编

审

组

成

员

支新辉贡徐青俊刘征辉林丽鑫王飞主

编

人

员

郭晓征耿丽丽马晓明毛明强张志炯王进行石松参

编

人

员

黄征彬熊洪槐张闻毅涛马韬钱石姚张沛沛博凯秦丹涛张瀚文张胡刘王江堃杰瑞王珂李松李晋彭永红程紫东张任远田应军席彬王乐晓关建峰赵静敏责

任

编

辑（排名不分先后）序言尚海峰华为主机上云军团CEO、混合云总裁过去三四十年，金融核心系统主要采用集中式主机架构进行建设。随着金融业务数字化转型需求的不断深化，云计算技术的持续演进，金融机构普遍采用了云原生相关技术进行业务改造，更有不少头部大行作为先行者，率先将主机承载的核心系统业务也迁移上云，加速了金融行业数智化、自主创新进程。目前，大部分国有银行和股份制银行已经完成了从一般类业务上云到核心类业务上云改造的试点工作，进入到核心业务批量上云改造阶段。柜面系统、网银系统、信贷系统、投资理财系统、信用卡系统等核心交易系统陆续迁移到云上，使得金融云平台承载的业务规模不断扩大，重要性不断攀升。随之而来的是，业务对持续高可用的要求更加苛刻，尤其是核心业务上云后，任何业务中断都会引发重大的影响。金融对公众开放的核心业务一旦中断会造成严重的社会影响甚至引发信用危机。除业务中断外，业务的劣化，如卡顿、报错等，也会造成最终用户的不满和投诉。这就对承载核心业务的云平台提出了更高的稳定性、可靠性要求。除了稳定的产品外，强大的运维体系是保障云平台稳定性最直接、最有效的手段。在主机核心业务逐步上云后，如何加强运维全链路监控能力，快速定位、定界和解决问题，如何变被动运维为主动故障预防从而大幅减少潜在故障与运维投入，如何将应用运维与平台运维进行有效协同从而保障系统性业务高可靠高可用，如何应对平台运维安全与租户安全带来的双重挑战等问题，成为了摆在金融运维人面前的关键挑战。华为云基于自身云平台运维经验，以及服务上百家金融客户数字化转型的实践，持续积累主机上云场景的运维核心能力，并沉淀了一套全面构建稳定可靠的现代化运维能力的路径和方法，期望助力金融企业加快实现主机业务的全面云化。目录105-08主机上云带来的运维新挑战21.1挑战1：如何基于应用视角设计高可用上云方案与高可靠运维保障方案1.2挑战2：云平台技术栈快速增厚，如何有效进行全链路可视监控1.3挑战3：云网深度融合，如何快速发现、定位、恢复问题1.4挑战4：如何应对运维安全与租户安全的双重挑战09-43主机上云运维现代化核心能力2.1平台运维现代化2.1.1全链路运维监控构建从应用到云平台的全栈感知能力2.1.2基于故障模式库和云网一体化运维实现确定性故障恢复2.1.3基于一体化风险库和混沌工程进行预见性风险治理2.2应用运维现代化2.2.1运维规划前置到设计阶段，业务可靠性来源于运维与设计的融合2.2.2借助运维数仓构建应用可用性监控管理体系，实现业务故障实时感知定界2.2.3面向故障全生命周期，全方位提升故障感知、诊断、恢复智能化水平32.3安全运维现代化2.3.1全视角运维安全体系设计构筑金融云运维安全堤坝2.3.2体系化、智能化安全运营为云上业务保驾护航44结语主机上云带来的运维新挑战挑战1：如何基于应用视角设计高可用上云方案与高可靠运维保障方案据库、中间件、AI、大模型等各种云原生技术被广泛应用。新服务、新技术的迭代加速，犹如一柄双刃剑，在助力业务快速发展、快速创新的同时，也带来了系统技术栈复杂度的急剧提升，给传统的IT运维方式带来巨大冲击。主机上云的最大挑战就是核心应用上云后的可用性管理。随着原来运行在大机上的应用不断迁移上云，云上的业务可用性等级要求被提升到了新的高度，传统的运维手段已经无法满足核心业务N个9的可用性目标。可用性管理前置到了系统设计乃至应用设计阶段。例如，应用的微服务化改造，带来微服务数量的指数级增长，应用的调用层次和调用关系变得冗长；分布式云原生的深度应用，使得业务链路更加复杂。当上层业务应用出现故障时，排障过程可能涉及从应用到网络的完整链路，这其中包含业务应用、云服务实例、云基础设施和服务器、网络、存储等物理设备。即便如此，可用性管理依然面临着成本、技术和管理的三重挑战。首先，无论是备份、主备、多活还是业务单元化改造，所有的高可用的架构设计都需要投入高昂的成本，高可用的效果和技术方案的投入成本成正相关关系。如何平衡高可用的投入与产出就成为IT管理者在高可用管理过程中的重要难题。典型的业务流量路径如：应用>容器>PaaS实例>虚拟机>服务器>虚拟网络>物理网络。在针对这个路径的运维实际工作中，应用、虚拟机软件提供方、服务器和网络设备提供方常常是各管一段，整个业务从上到下的全栈调用路径往往是个黑盒，导致故障定位定界困难，或者恢复时长无法控制。其次，高可用设计是一系列技术方案的组合，从底层网络设计、到云服务的有效运用以及高可用技术工具的选型，从业务部署架构的改造到上层业务的单元化改造，每个层次都涉及多种技术的使用与配合。如何让现有的技术手段以及云服务发挥最大的效能，如何基于先进的单元化设计理念达成核心应用N个9的可靠性也是IT管理者面临的难题。面对IT系统复杂的技术栈及海量的运维对象，做到软硬件运维对象的统一管理，指标、告警、日志、调用链、拓扑等运维数据的统一汇聚和分析，构建全链路故障感知、全栈故障可视的运维体验，对于金融主机上云过程中的运维工作至关重要。最后，服务SLA（ServiceLevelAgreement,服务水平协议）的达成还需要有相匹配的管理手段与工具，如故障模式库、演练工具等资源作为支撑，不但要能有效跟踪度量SLA的实际效果，还需要持续、主动发现可用性风险的机制与工具，在可用性管理的过程中实现数据积累和能力演进。挑战3：云网深度融合，如何快速发现、定位、恢复问题过去一年，在互联网领域发生过多起颇为严重的宕机事故：2023年3月，某互联网服务商发生机房故障，多个互联网核心应用受到影响，事故持续7个小时，影响约十几亿用户。挑战2：云平台技术栈快速增厚，如何有效进行全链路可视监控2023年11月，某云服务商旗下多款应用出现无法登录故障，事故持续4个小时，这是该云服务商时随着主机上云和业务云化转型的持续深入，分布式数06隔一年之后第二次出现严重故障。如何解决云网络问题在云网络和物理网络深度融合的场景下，应用级的网络可视、云网络端到端的故障探测是解决云网络问题的关键所在。2023年11月，某互联网服务公司核心应用业务瘫痪接近12个小时，流失千万订单，直接损失上亿元，引发了广泛的社会关注。总结上述这些事故，它们都具备了如下几个特点：挑战4：如何应对运维安全与租户安全的双重挑战事故影响范围巨大，社会反响强烈，更有甚者还会对社会的衣食住行产生严重影响。主机上云的过程中，应用与云平台的运维会同时受到运维安全和租户安全的双重挑战。事故影响时间较长，业务恢复周期以数小时计，严重者故障恢复时长达到了12小时。在运维安全方面常见的挑战包括：造成巨额经济损失，负责人被处分、问责。运维安全意识不足运维管理者缺乏对运维安全的完整规划，在制度、流程和技术规范方面缺少对变更的严格管控。在缺乏对变更的严格审控机制的情况下，随意的变更为引发后续事故埋下了隐患。随着上云进程的逐渐深入，金融企业开始将核心应用搬迁上云。核心应用一般有着规模大、分布式、架构复杂等特点，这一点和互联网业务非常相似，上述互联网的故障也在时刻给金融核心应用的运维敲响警钟。在此背景下，近年来金融领域客户提出了核心业务的“1-5-10”目标，即：1分钟发现故障、5分钟定位、10分钟恢复。要实现这个目标必须要解决以下关键问题：运维安全管控的技术手段不足主要表现为，对运维操作入口没有进行技术管控，缺乏对运维操作过程的有效监管，缺乏对高危操作的拦截，缺乏对运维操作的记录与审计，缺乏识别恶意操作的评估手段。如何尽可能地少出问题首先，需要有一个完善的运维规范和流程来保障运维流程合规；其次，核心应用需要全局的高可用设计，从架构层面避免单点故障；最后，企业还应具备完善的风险管理体系，可以对识别到的风险举一反三快速闭环，持续提升核心应用的韧性。权责不匹配运维人员的权限过大或者超越自己的职责范围，很容易引发超出职责范围的误操作，从而带来不必要的运维风险。在租户安全方面的挑战包括：如何快速恢复故障基于核心应用黄金指标的秒级故障感知是故障恢复的前提；基于调用链分析、日志解析、云服务实例快速诊断的分钟级故障定位是故障恢复的基础；基于应急处理预案的一键式故障恢复是行之有效的手段。安全攻击无法避免希望一劳永逸地解决租户安全问题是不切实际的。人类的操作永远无法做到完美，系统和技术总在不断演进，新的漏洞会不断出现，完全消除漏洞是不可能的。所以，0日攻击、钓鱼攻击以及账户被破解都无法被避免。07租户安全防护难以全局统筹理解威胁的本质，以制定有效的处置策略。有时候安全团队还会面临技术上的限制，从而需要花费更多时间来研究和实施解决方案。现代企业和组织的网络环境越发复杂，涉及众多设备、应用、数据类型。同时安全威胁也在不断演变，包括网络攻击、钓鱼、木马、病毒、社会工程学攻击等多种形式。安全团队需要同时跟踪多种威胁情报，及时调整安全策略和措施，以应对各种各样的威胁。在实际业务场景中，由于安全管理不善造成重大事故和业务损失的案例并不鲜见，如误删数据库账户造成结算业务失效，误删虚拟机造成业务中断，租户权限管理不当误删OBS桶等等。云化、集中化虽然提升了业务的创新速度，也让运维安全的管控以及租户安全的治理变得更加复杂，所以运维安全是业务可靠性保障的基石，也是运维现代化的基础。安全威胁处置缓慢安全威胁普遍具有隐蔽性强的特点，不易被及时发现。现代安全威胁越来越复杂和多样化，攻击手段和方式不断演变，安全团队需要花费更多时间来分析和主机上云运维现代化核心能力主机上云运维现代化旨在围绕核心系统云平台运维、应用运维及安全运维三大领域系统性构建上云后的云运维保障能力，全面支撑金融核心应用通过平迁、改造或核心重构三种方式迁移上云后的稳定可靠运行，助力金融机构平滑稳健地深化数智业务创新，构筑面向自主创新的高质量发展基座。存贷款消费信贷支付结算中间业务现金管理理财管理资金交易主动预防运行稳定安全可靠1.平台运维现代化2.应用运维现代化3.安全运维现代化全链路确定性预见性高可用智能化全视角体系化运维监控故障恢复风险治理架构设计应用运维运维安全安全运营全链路可观测面向应用运维极简信息汇聚云网定位定界故障精准诊断一键故障恢复主动风险预防变更风控管控混沌工程演练高可用SLA规划应用高可用设计持续高可用治理运维数据治理可用性指标构建运维故障分析用户授权可控制作业过程可信赖潜在风险可识别立体防御体系主动智能安全全面安全运营主机上云新基座应用平迁上云应用改造上云核心重构图2.1运维现代化三大核心能力平台运维现代化平台运维的现代化转型重点要考虑如下三方面的能力建设：华为云给出了通过全链路检测、故障模式库和云网结合快速定界故障的思路，以此提升核心应用上云后云平台故障恢复的确定性。全链路运维监控核心业务上云的过程中，云与应用的耦合度逐步提高，应用与云平台的关系愈加复杂，因而云运维必须实现应用到云平台乃至物理设备的全链路覆盖。同时需要梳理出应用与云平台间的依赖关系，当应用出现故障的时候能够基于应用的视角快速感知和诊断故障。预见性风险治理实现风险的提前感知与预防始终是运维管理者长期的期望，也是运维人员一直面临的难题。这个问题同样摆在华为面前。在十多年运维工作中，华为云通过大量项目实践摸索出了一套预见性风险治理的思路，不但覆盖了运行时的风险治理，也覆盖了对变更的风险治理方法，以及对未知风险的识别与预防手段，本文将详细阐释通过数字化到自动化的转换实现云平台风险预见性治理的思考。确定性故障恢复快速创新的金融业务场景增加了云平台技术栈复杂度，也因此提升了故障定界、故障快速恢复的难度。10应用运维现代化当前，越来越多金融云运维管理者的关注点从以云与设备为核心的运维转向以应用为核心的运维，尤其是核心应用的运维受到格外的重视。在应用运维领域，存在多种多样的工具与技术，然而工具之间数据割裂无法形成全局视野，因而会直接影响应用运维的效率与效果。只有打破各个工具间的数据孤岛才能统筹洞察应用的完整运行态势，对应用进行全方位的监控与分析。在本文中，华为云提出要将应用的可靠性保障前置到设计阶段，通过高可用设计提升应用的可靠性，同时也给出了应用高可用设计的思路，帮助金融企业选择合适的高可用方案平衡成本与效益的矛盾。安全运维现代化运维安全是保障业务可靠性的基石，也是运维现代化的基础。在运维安全领域需要通过对运维过程无死角的安全管控来保障运维安全，具体来说，需要实现事前对权限的有效规划和管理，事中对运维操作的严格管控，以及事后对运维操作的审计与分析，减少由于运维误操作给云业务带来的风险。除了云平台本身的安全保障，在租户安全维度，也应构建完整的安全防护体系，端到端保障云租户的安全。2.1平台运维现代化核心能力2.1.1全链路监控构建从应用到云平台的全栈感知能力应用层通过在容器集群、弹性云服务器、裸金属服务器上部署复杂的应用，实现某些业务功能；从应用视角到平台视角，构建全面的指标体系，快速感知故障PaaS实例层主要是指云平台提供的容器集群、中间件、数据库等实例资源；核心应用部署上云，从上到下可以分为四层，分别为终端层、应用层、PaaS实例层和IaaS基础设施层。如下图：IaaS基础设施层主要指提供计算、存储、网络的基础资源池，如云数据中心的存储池、虚拟网元、计算资源池或者传统数据中心的服务器、网络设备、存储设备等。终端层严格意义上并不在云上部署，主要部署在端侧，通过APP或者浏览器实现应用访问；简单应用访问流程示例微服务架构复杂应用访问流程示例终端层订单处理120ms102msuser-mgrMySQL102msELB应用层102msapi-gw200mscache-mgrAPPSAPPSAPPSAPPAPPAPP102ms102msRabbitMQRedisproduct-mgr数据库实例层缓存容器节点云硬盘云主机宿主机缓存云主机云硬盘容器节点数据库层宿主机网元存储池宿主机网元存储池宿主机物理主机网元存储池云数据中心1云数据中心2传统数据中心如上图所示，针对简单应用（绿色线条），可以直接以应用云上部署架构来构建全链路监控；针对微服务架构的复杂应用（红色线条），需要借助APM工具解析微服务间交互流程来构建全链路监控。图2.2典型云上应用部署模型12构建核心应用可观测体系，需要根据应用部署层级分别进行设计：端，对应用进行周期性拨测，快速感知边缘网络故障。终端可观测终端层常见指标举例：终端层需重点关注用户的使用体验，采集终端应用运行报告、访问成功率、接口延时等体验类指标，通过终端内置的软件工具包(SDK)上报到应用可观测平台。必要时需要部署一定数量的云拨测终a.APP体验指标：如下载成功率、安装成功率、用户搜索耗时、用户下载速率等表征最终用户体验的指标b.API性能指标：调用成功率、调用量、时延等App/ServerKitAccountkitAudiokit…边缘网络c.边缘网络性能指标：丢包率、延时、带宽、流量消耗等Internet/骨干网&CDN应用可观测APP体验指标API性能指标边缘网络指标应用层需要根据应用的核心功能，构建表征功能健康度的黄金指标。不同应用功能存在差异，梳理出的指标不尽相同，指标越能精细表征健康度，越能快速感知故障，反之亦然。下载成功率安装成功率首页打开耗时首页图片耗时用户搜索耗时应用详情耗时用户下载速率…API时延调用量成功率…带宽流量速率CDN…以某互联网视频应用为例，需要基于应用接口日志定义接口请求量、接口成功率、接口时延、播放卡顿率等指标，针对指标数据进行治理，最终呈现不同时间维度的视图，同时支持针对流量的趋势进行动态阈值调整，准确产生指标告警。图2.3典型终端指标设计流程维度：APP版本、视频分类度量：请求结果标识、时延视频登录请求成功次数/视频登录请求次数视频登录请求成功次数视频登录请求次数视频登录请求成功率长视频登录请求成功率逻辑主体基础指标派生指标指标叠加公式组合指标派生组合指标APP版本视频请求分类结果......时延视频登录请求次数视频登录请求成功次数视频登录请求成功率长视频登录请求成功率1.0.11.0.21.0.11.0.3长视频成功短视频成功短视频成功长视频失败30503540X（次）X（次）XX（%）XX（%）图2.4指标设计流程示例13应用指标定义完成之后，还需要构建应用全链路拓扑视图，发生故障时，能够在拓扑视图中直观呈现，运维人员可以从多个维度快速感知故障影响范围，并对故障进行简单定界。全链路拓扑一般可以分成应用调用拓扑和网络流量拓扑：-应用调用视图：基于APM(applicationperformancemanagement，应用性能管理)调用链能力，追踪应用进程内部的函数调用路径，用于跨线程和异步场景故障感知。-网络流量视图：基于eBPF(extendedBerkeleyPacketFilter)内核组件和网络报文染色能力，无侵入式覆盖网关、基础服务、网络路径、跨语言服务场景的故障感知。应用调用视图33calls|120ms133calls|200ms503calls|568msuser-mgr31calls|102ms31calls|102msMySQL31calls|102msRabbitMQ31calls|102msapi-gwcache-mgr29calls|1014ms31calls|102msproduct-mgrRedis0%/8usGuestOS0%/10us3%/20usapi-gwGuestOSRabbitMQ网络流量视图subnetELBVPC源端源端subnet目的端目的端subnet0%/15us0%/8us0%/8usvSwitchELB源端0%/15usvSwitch0%/15usvSwitch0%/8us0%/8us0%/8us0%/15usvSwitch目的端0%/8us源端目的端图2.5全链路应用拓扑视图14PaaS实例可观测式数据库的长事务、慢SQL执行等指标。云平台通常能够提供丰富的PaaS实例，如容器集群、消息队列、数据库、分布式缓存、分布式事务等中间件，这一类PaaS实例由云平台侧提供开箱即用的SLI(servicelevelindicator,服务质量指标)，通过API或者监控对接等方式接入到应用运维平台。此类指标以云平台提供的客户可感知的服务实例为中心，直观体现实例状态的监控指标，与实例类型强相关，通常以业务请求消息统计的形式获取对应指标。-Error(错误率)：代表执行某一业务的错误率是多少，如分布式缓存高危命令、大Key使用等指标。-Ticket(工单)：代表某一功能是否需要人工介入，人工介入越多，可用性越差。PaaS实例SLI指标体系建设遵照VALET原则构建五个维度的指标：容量-Volume(容量)：是指服务承诺的最大容量是多少，如数据库连接数、容器集群可用节点数等。可用性工单实例SLI指标-Availablity(可用性)：代表服务是否正常，如实例主备状态、实例可用副本数量等。延时错误率-Latency(时延)：代表响应是否足够快，如分布图2.6遵照VALET模型建设SLI指标体系云服务（索引）功能点功能平面VALET类别指标名称指标

指标

监控单位

周期

方式阈值规则重复次数影响说明连接使用率大于90%查询服务过去1分钟内为一个统计周监控期，至少3次检测连接使上述指标表征DCS实例连接使用率情况，超过使用率可能导致实例新建连接失败，可用性产生异常。DCS实例可连接性DCS实例连接使用率DCS数据面可用性%1分钟3用率达到95%。查询过去1分钟内为一个统DCS实例可连接性DCS实例命令时延服务计周期，每分钟统计的最监控大时延超过10ms，连续实例命令时延过长，阻塞后续命令执行，影响实例功能。DCSDCS数据面延时毫秒1分钟31三次上报告警。查询过去1分钟内为一个统计周期，存在高危命令、大Key使用的告警。需要考虑告警聚合策略。DCS实例可连接性DCS实例使用规范性布尔类型数据面错误率1分钟告警高危命令、大Key使用可能影响实例可用性。图2.7可用性指标设计举例15基础设施可观测综上所述，构建核心应用的可观测体系，应该从业务应用视角到云平台资源视角进行分层设计。应用视角主要包含终端层和应用层，基于应用的核心功能，由业务开发人员、运维人员、测试人员组成“铁三角”共同设计。云平台资源层主要包含PaaS层实例和IaaS层基础设施，由云平台提供开箱即用的标准SLI指标，应用指标和资源指标汇聚接入到应用可观测平台中，由应用可观测平台统一对外呈现。基础设施指标主要是指以公共的基础设施类资源为中心，用于体现基础资源当前运行状态的指标。此类指标只有出现瓶颈时才可能会影响上层业务，但很难定义出与上层业务之间明确的必然性以及关联度，如：CPU使用率、内存使用率、IOPS、网卡发送速度等指标。此类指标无业务含义，重点体现的是基础设施资源的运行状态，而指标的异常也无法明确对上层业务的具体影响。由于比较通用，这类指标可通过公共能力统一提供。业务应用视角应用可观测平台端侧可观测终端应用日志指标事件终端体验类指标端侧数据采集APP浏览器拨测云拨测运营数据业务数据移动端JS错误端侧体验类拨测端侧运行监控异常分析用户旅程应用可观测业务应用日志指标trace事件应用黄金指标应用数据汇聚全局拓扑链路追踪代码级诊断应用请求成功率应用功能响应时延应用请求吞吐量Profiling多语言接入实例可观测云服务实例日志指标事件云实例可用性指标云实例数据汇聚容器集群可观测中间件可观测实例可连接性实例读写时延实例状态集群监控Pod监控消息队列RDS节点监控网络监控GaussDB缓存基础设施可观测资源池日志指标事件基础设施指标平台CPU利用率内存利用率资源池数据汇聚管理虚拟机操作系统主机网络网络带宽使用率存储IO使用率存储图2.8四层指标体系16极简信息汇聚，一站式触达运维态势，提升运维体验和故障处理效率监控汇聚状态可视：展现被管对象及内部组件的告警信息。基于告警可以快速感知对象的异常状态；此外，运维平台还应支持查看被管对象及内部组件的指标信息。如前所述，金融客户在日常运维信息的获取上，存在两个关键痛点，一是运维体验围绕功能展开，对运维对象的操作需要在不同界面来回切换，体验不畅；二是信息分散，比如描述状态的告警指标信息、用于定位的日志和调用链信息、各类操作的状态信息需要从不同的运维界面上获取，导致故障处理效率低。因此需要持续构建极简信息获取的能力，使运维人员可以快速获取所需的运维态势信息，从而提升运维体验和故障处理效率，进而解决企业运维要求高和运维能力不足的矛盾。拓扑关联故障定界：展现被管对象与内部组件、底层部署依赖、周边调用依赖等关系的拓扑图，并在拓扑图中展示各个对象的告警状态。创建的拓扑应包括应用的物理拓扑、云服务物理拓扑、云服务部署拓扑等。通过对关联对象的异常状态分析，可以支撑运维人员进行故障定界。组件分析逐层下钻：故障定界定位犹如抽丝剥茧，极简运维要支持从故障表现的点开始，对齐内部组件和依赖资源，逐步、逐层进行下钻分析，一步步接近问题根因。极简信息获取的设计理念信息集约：面向运维对象进行运维操作功能的体验设计，例如，在同一个操作界面上集成运维对象的状态信息、组件关联、操作维护等信息。操作维护快速直达：集成被管对象的常见操作，如自动作业、节点诊断、拨测等，在日常运维和故障处理时，能够快速完成操作。对象关联：围绕同一个运维对象，可向下关联依赖的容器、物理设备等底层资源信息，向上关联被依赖的应用组件信息，从而快速获取与该运维对象相关联的运维信息。2.1.2基于故障模式库和云网一体化运维实现确定性故障恢复逐层下钻：在呈现运维状态信息时，界面应围绕运维对象关系，展示逐层下钻的内部组件和依赖资源相关的分析信息，以便逐步逼近问题根因。确定性故障恢复需要从应用系统视角和云平台资源视角分别定义。一致体验：所有被管理对象都有一致的全景360视图体验，从一个关联对象可以一键跳转至其全景360监控信息界面。基于云服务故障模式基线库，对云服务实例进行全面诊断，以便精确定位、快速恢复故障应用可观测平台感知故障之后，通过指标的汇聚和算法处理，可以对故障进行初步的定界，输出可能存在故障的资源实例，此时需要云平台具备针对资源实例端到端的精确故障诊断和快速恢复能力。实现资源实例的诊断，需要大量的运维专家经验，从实例的资源、依赖、历史故障模式等多个维度进行分析，因此，构建云服务的故障模式库至关重要。极简信息获取的目标效果运维信息展示要能够围绕运维对象进行汇聚，使运维人员可以方便且快速获取需要的运维信息。对象状态一屏概览：被管对象概览界面，要能够展示对象关键信息，包括基本信息、告警、关键指标等内容。故障模式库生成机制故障模式库是在产品设计阶段，对构成产品的组件进17行逐一分析，找出潜在的失效模式，并分析其可能造成的影响，根据组件的薄弱环节，输出的预防措施列表。构建一个完善的故障模式库需要至少包含如下三个方面：确定分析对象描述系统功能定义严酷等级建立框图故障模式清单白盒化的故障模式分析：端到端梳理组件架构，根据组件在架构中的位置，分析可能的故障点。梳理云服务核心功能，并和组件架构有机结合，以实现对某一核心功能对应故障点的可视化呈现。此外，还应规划对应故障点的自动化诊断、一键式恢复能力。FMEA分析图2.9系统级FMEA故障模式分析流程黑盒化的功能性拨测：包括关键进程和端口的探测、网络组件交互性拨测、及AA集群流量负载均衡的诊断。续积累故障模式库。故障模式库的推广机制梳理故障模式库只是故障处理的一种手段，让站点能够基于故障模式库快速诊断、恢复故障才是最终目的。因此基于故障模式库中定义的每一种故障模式都需要开发对应的内容包，内容包中应至少包含一套诊断脚本和一套恢复脚本。故障模式内容包应该与产品解耦，既可以集成到产品中支持新建站点的开箱即用，又可以单独发布支撑存量站点的持续迭代更新。现网历史故障补充：基于产品组件在现网中的历史重大故障进行逆向覆盖，确保重大质量问题全覆盖，改进措施对应指标可诊断。可使用系统级FMEA(failuremodeandeffectanalysis，失效模式及效应分)故障模式分析流程持针对一类服务的某个核心功能的故障模式库梳理故障模式描述产品对象核心功能点云服务名称分布式缓存分布式缓存分布式缓存故障对象Redis实例Redis节点Redis实例故障模式故障影响严酷等级I类观测方式应急恢复措施实例重启Redis访问Redis访问Redis访问实例状态异常节点状态异常实例拒绝连接影响业务访问Redis影响业务访问Redis影响业务访问Redis实例状态异常告警实例节点异常告警I类实例节点重启调整实例最大连接数监控实例活跃客户端连接数超规格I类故障模式适配包开发故障模式适配包推广├─resource_{云服务索引}_{version}.zip│├─alarm#故障适配包#告警目录开箱││├─{云服务索引}_alarm.json│├─monitor#告警静态信息#监控目录十统一新建站点即用故障模式内容包

适配包│├─script#非必选│││├─config.json│││├─{script}│├─operations#配置脚本范围#脚本逻辑#运维操作目录#操作配置│││├─actions.json││├─i18n#国际化目录#自动作业目录#操作目录运维持续迭代存量站点│├─autoops治理包││├─operations││├─flows#编排目录││├─i18n#国际化目录图2.10故障模式库推广机制故障模式库运行机制运维人员在运维平台上针对故障进行一键式诊断，对于诊断不通过项，进行一键式故障恢复。这样可以减少运维人员对环境接入及运维能力的依赖，使他们可以更加聚焦业务。分布式缓存服务关系数据库服务XXX服务告警监控指标监控自动作业状态诊断脚本信息收集脚本快速恢复脚本状态诊断脚本信息收集脚本快速恢复脚本状态诊断脚本信息收集脚本快速恢复脚本局点运维人员图2.11故障模式库运行机制19图2.12一键式故障诊断恢复示例云网一体化运维实现应用、虚拟链路、物理路由的一致性监控和运维用端点无损监测和iFIT真实业务流链路监测两大核心功能实现。云网一体化运维是指将云计算与网络技术相结合，对云计算环境中的网络资源进行统一管理和维护的一种模式。在这种模式下，网络管理员可以通过云计算平台提供的工具和接口，对网络资源进行实时监控、故障排查、性能优化等操作。虚拟&物理网络可视诊断定界：主要通过Cloud-NetDebug虚拟网络拨测和FabricInsight物理网络定界两大核心功能实现。（一）应用网络真实业务流一屏监控云网一体化运维的实现依赖于云平台和网络设备的协同工作，云平台需要提供相应的API接口，以便管理员可以访问和操作网络资源，同时网络设备也需要支持相应的功能，如网络监控、故障诊断、流量分析等，以实现对网络资源的有效管理，从而实现云上Overlay资源与Underlay网络设备的统一运维。1）eBPF应用端点无损监测eBPF是一种在Linux内核中运行的虚拟机，它允许用户在不修改内核源代码的情况下，动态地加载和执行代码。eBPF最初是为了网络数据包过滤而设计，已扩展到其他领域，如安全、跟踪和性能分析。云网一体化运维通过如下两个机制实现高效监控与问题定位：eBPF的运维涉及到许多方面，包括部署、监控、调试和排查。具体的实现机制是：eBPF以字节码形式注入到应用内核中并挂载到特定钩子(hook)挂载点应用网络真实业务流一屏监控：主要通过eBPF应20上。当内核或应用程序执行到某个挂载点时，产生特定事件并触发程序运行。eBPF技术的代码无侵入、语言无关、高性能、强关联、数据端到端覆盖等特征，可满足可观测性标准和观测数据采集的要求。基于eBPF内核观测技术生成的网络级丢包、时延、吞吐量等方面指标，可以实现流级的应用路况可视化监控能力。应用访问拓扑可视：访问关系图、访问量、访问时间BPFProgramReaderLLVM/Clang应用网络质量可视：重传、拥塞、0窗口Prog.bfpbpfBytecodeUserspaceKernel2）iFIT真实业务流链路监测bpfIFIT(In-situFlowInformationTelemetry)是一种用于网络流量监控和分析的技术，可以实时收集网络中数据包的元数据信息，如源地址、目的地址、协议类型、源端口、目的端口等，及数据包的时间戳。通过分析这些元数据信息，可以了解网络中流量的实时情况，识别流量模式和趋势，检测异常流量和故障，从而实现网络的智能运维。eBPFBPFMapsBPFBytecodeVerifier+JITKernelFunctionsNativeCode图2.13eBPF挂载原理iFIT主要基于在被检测业务流报文中添加iFIT检测头，实现随流的业务质量检测，反映业务流的真实业务质量。R1(Source)1588v2/G8275.1R2(Destination)Tx[i+1]Tx[i]Rx[i+1]Rx[i]000111110000010001110100001T:染色周期每周期统计点后移，屏蔽乱序干扰：T+6T/10，后移6T/10时点图2.14iFIT监测原理21借鉴IPFPM(FlowPerformanceMeasurement，流性能测量)染色机制，iFIT染色报文带内测量技术可以构建流级的网络路况追踪和诊断能力，实现基于包粒度的真实业务流全链路检测。这项技术具有以下几方面特点：部署，自动按需E2E/逐跳检测丢包位置：基于每节点的报文计数，分析丢包点逐跳时延/抖动：基于每节点的时戳记录，分析链路/节点时延支持多种业务场景：L3VPN/EVPN/SRv6/SR-MPLS/MPLS路径还原：基于每节点上报信息，呈现业务真实路径易部署运维：头节点按需定制，中间/尾节点一次图2.15iFIT业务流监测实例如图所示，实例中实现了网络丢包、时延、抖动、带宽等真实业务流路径的可视监控。（二）虚拟&物理网络可视诊断定界1）CloudNetDebug虚拟网络拨测CloudNetDebug是面向运维人员的虚拟网络诊断工具，帮助网络管理员和开发人员快速诊断和解决云网络中的问题。通过收集和分析云网络中的数据包、流量和性能指标等信息，提供全面的视图，使用户能够快速定位和解决网络问题，包括数据包捕获、流量分析、集成拨测和抓包、性能监测和故障排查等。通过客户报文模拟拨测，应用报文抓取等方式，实现可视化拨测快速诊断定界。22正常周期拨测---覆盖所有链路CNA1vRouter1BorderRouter1①CNA2···交换机1vRouter2···交换机3···BorderRouter2······BMSGW1交换机2ENAT1交换机4BorderRouter15BMSGW2预置探针ENAT2BorderRouter16出现故障场景---自动汇聚告警CNA1vRouter1BorderRouter1②CNA2···交换机1···vRouter2交换机3···BorderRouter2······BMSGW1交换机2ENAT1交换机4BorderRouter15BMSGW2预置探针ENAT2BorderRouter16图2.16CloudNetDebug拨测原理软件拨测定位是利用染色标记技术主动拨测抓包，通过跟踪染色报文经过的路径，覆盖资源(IP)>虚拟交换网络>物理交换网络进行全景网络拓扑的可视化拨测诊断。实际应用中，有如下两种监控诊断模式：物理网络诊断通过调用FabricInsight的接口获取业务流路径指标，包括流状态以及交换机异常信息等，实现从控制面>虚拟网络>物理网络的三层穿透故障诊断。2）FabricInsight物理网络定界LinkMonitor主动链路监控：通过在计算节点创建探针，创建出VPCL2、VPCL3、VPC-Peering、EIP和DC流量的拨测任务，自动周期性探测虚拟网元的转发质量，以及网络服务的链路质量，从被动问题处理转变为主动发现链路质量问题，进而提前发现问题风险点。FabricInsight是一种用于物理网络分析和监控的工具。这个工具支持实时监控和警报，帮助用户快速发现和解决问题，更好地理解和管理他们的网络链路系统，还提供了丰富的分析功能，帮助用户深入了解网络的性能和行为，并识别潜在的瓶颈和优化机会。此外，FabricInsight工具还支持多种物理设备组网的管理、控制和分析，支持网络仿真校验及虚拟感知，支持NetConf，OpenFlow，OVSDB，SNMP等协议，从而实现物理和虚拟网络设备的可视化管理。FullLink全链路诊断：进行全链路复杂流量叠加场景的网络问题定位。通过控制面诊断租户的云服务配置、路由表、安全组和网络ACL等配置，检测每个网元的时延和丢包率实现虚拟网络诊断。23网络路径设备KPI故障风险TCPSYN/FIN/RST报文采集逐跳真实路径还原丢包/时延变更检测网络路况分析TCP连通性分析关联逐跳故障分析关联逐跳网络质量分析逐跳配置变更检测VMVMVMVMVMVMVMVMVMVMVMVMVM自动输出故障定位结论图2.17FabricInsight物理网络故障定界硬件诊断定位是通过业务物理路径指标，包括流状态以及交换机设备故障、链路故障、转发过载等，实现业务流路径物理网络端到端路径的可视及异常定位。分析指标、日志、告警、配置、容量等运维数据，从风险隐患、性能规格、系统容量、系统可靠性、最佳实践、版本生命周期、安全漏洞等多个维度对系统进行全面的评估。Fabric内业务流路径可视：通过关联分析逐跳设备信息感知故障断点，故障一键式诊断，定位网络路由、策略类故障根因。变更风险控制：通过建立变更前的风险识别和评审机制，提前识别变更的潜在风险；通过自动化及渐进式的变更过程，确保变更不引入风险。质差主动发现：基于网络路况开放，实现应用网络协同，通过技术分析微突发、丢包、光模块异常等现象快速定界定位问题。未知风险挖掘：通过混沌工程识别系统的薄弱环节并改进，持续提升系统韧性。变“被动救火”为主动预防，构建运行态风险主动预防体系2.1.3基于一体化风险库和混沌工程进行预见性风险治理面向未来，“被动救火”式运维将成为过去式，主动运维将成为保障系统高可用的重要手段预见性风险治理是一种前瞻性的风险管理方法，旨在通过事前的预测和诊断识别潜在风险，提前制定风险消减措施，保障系统的稳定运行。根据风险场景，预见性风险治理主要分为运行态风险预防，变更风险控制和未知风险挖掘三部分内容。《史记》曾载，魏文侯问扁鹊“你们三兄弟谁的医术最为高明？”扁鹊言“长兄最善，中兄次之，扁鹊为下。”文侯好奇道“何出此言？”扁鹊答“大哥治病，常以望闻问切，诊断隐患，在病害形成之前就能铲除病因，因此一般人不知道大哥的厉害，是以声名不显。二哥治病于初起之时，大家以为他只能看看小病，所以他只闻名于乡里。而我治病于运行态风险预防：建立完善的运行态风险主动预防体系，定期进行风险评估和监测。通过收集和24严重之时，用针刺猛药，救人于危机之时，所以大家都以为我医术最高明，因此名传天下。金融云风险主动预防机制的核心思想是通过构筑中心化的风险库，从风险规则的生成、风险诊断到风险的预警推送，构筑服务化的风险主动预防能力。实施层面可按如下思路展开建设：上工治未病，扁鹊长兄治病于未发，是为事前；中兄治病于渐发，是为事中；扁鹊治病于严重，是为事后。治病如此，运维亦是如此。运维的核心目标是保障业务可用，减少和避免故障发生。传统的救火式运维，运维人员的工作内容和工作重心往往聚焦在事件和故障处理，偏向事后，这种运维方式无异于减少和避免故障，无法满足现代化云运维的要求。从故障事前、事中和事后的角度看，事后恢复不如事中控制，事中控制不如事前预防。因此，必须摒弃传统的救火式运维，变被动为主动，预防和减少故障发生，防患于未然。1.构建中心化风险库构建中心化风险库的目的在于将风险集中管理，防止风险管理的无序和散乱。风险库的建设需遵循全面性、实时性和持续性原则。全面性：风险库需要涵盖明确的风险类型和范围，如产品缺陷、性能过载、组网非标、配置隐患、版本配套、硬件适配、安全漏洞等，确保风险范围覆盖全面，防止遗漏。建设金融云风险主动预防体系，实现站点故障早发现实时性：风险动态实时更新，即风险从发现到入库的时效性需要得到保证，确保现网应用的风险库时刻保持最新。主动运维并不是一个新鲜的概念，但在大部分的企业中，主动运维仍是一句口号，对于一个云平台，如何能让主动运维真正落地并产生效果？本质上来讲，主动运维的目的在于事前预防，治病于未发是关键，因此需要重点构建事前的风险识别和预防能力。持续性：制定明确的风险库管理制度，包括风险库的更新和维护机制，确保风险库的有效运行和持续更新。2.建立风险评估机制1986年，美国挑战者号航天飞机发射后发生爆炸，事故造成7名宇航员丧生，发射活动以失败告终。为了实现故障先预警，隐患早发现，NASA建立了航天器故障预防诊断平台，旨在提前通过诊断检查发现异常事件，保障航天器可靠运行，避免事故发生。对于云平台这种大型的分布式软件系统来说，建立风险检测预防机制同样是重中之重。风险评估机制是通过收集和分析信息数据，结合风险库规则来识别风险隐患的过程，其目的是为了有效地识别系统风险。风险评估机制的主要步骤包括：信息收集：收集生产环境的指标、日志、告警、配置、资源、容量等运维数据，作为风险诊断分析的数据输入。传统IT系统的风险主动预防通常会以产品化的方式发布巡检工具，通过在现网部署巡检工具进行巡检来识别风险，这种方式受限于工具的发布节奏，风险无法实时更新，无法保证现网时刻都可以应用到最新的风险库。诊断分析：对收集的运维数据进行分析诊断，识别系统劣化指标，匹配风险库规则进行风险冒泡，评估风险等级及影响，输出健康度评估报告。253.建立风险预警流程变更前建立完善的风险预警机制，通过定期的风险评估报告方式将风险预警推送到现网，确保风险信息可以及时准确地传递给相关组织。同时，提供相应的风险规避措施，持续跟踪风险在现网的闭环情况。-变更准入：建立变更准入机制，在变更申请阶段对变更的准入条件进行控制，包括变更必要性评估，标准化变更方案制定，变更影响分析，回退方案、变更授权等；基于变更模型提前拦截变更态风险，通过全流程自动化实现变更态风险有效控制-风险识别：变更前对变更风险进行识别，包括变更历史问题风险、变更方案风险、业务影响风险、高危操作风险等；变更风险控制是系统变更过程中至关重要的一环，旨在减少因系统变更而带来的不利影响，提高变更的成功率。随着业务数量和业务规模的持续扩大，现网的变更数量和变更频次不断增长，而频繁的变更常常会给运维带来不可预知的风险。据数据统计，70%的线上故障都是由变更引起，变更可能引起功能失效、性能下降、数据丢失甚至系统崩溃。如何有效管控变更风险，是运维工作面临的巨大挑战。面向现代化的变更风险控制能力构建可按下面思路进行考量：-变更评审：变更评审阶段，由评审人对变更方案和变更风险进行评审，确保变更实施方案正确，变更影响和变更风险评估准确。变更中-灰度变更：构筑变更实施阶段的灰度变更能力，按需控制变更范围，可以尽早发现并解决变更问题，有效降低变更带来的风险；1.变更风险控制需要在变更的不同阶段构筑不同的控制能力-风险控制：在变更实施过程中控制变更操作的风险。对于高危操作、未授权操作实施拦截，对于变更过程中的异常和非预期结果，应实施变更自动终止操作。-变更监控：对变更过程实施监控，通过状态、指标和告警，快速发现变更带来的非预期影响。流程，使得变更在各个阶段都能得到有效的跟踪和控制。变更后变更申请阶段，基于变更模型创建变更申请单，变更申请单自动获取变更模型关联的风险规则，同时根据风险规则识别变更风险。风险规则可以是特定的匹配规则或脚本，通过自动化流程运行风险规则或脚本，给出本变更所识别出的风险集合。-安全回退：构筑变更回退能力，包括变更全量回退以及按阶段、按工步的局部回退，支持灵活的回退策略制定；-拨测验证：建立变更后的业务拨测能力，在变更后通过业务拨测验证变更业务是否可用，及时发现问题。变更评审阶段，对于变更单所识别变更风险的闭环情况进行审核，确保变更风险全部闭环，变更流程才能进入变更实施阶段。在变更申请和变更评审阶段，重点构筑变更风险的识别和拦截能力。2.建立变更模型+风险规则的风险识别机制，确保变更风险提前识别首先，对不同类型的变更建立不同的变更模型，并对变更模型设定相应的风险规则，风险规则可来源于此类型变更的历史问题和专家经验，或与此类变更相关的状态、指标和配置等。变更实施阶段，基于工具构筑自动化变更及控制能力。工具应具备作业编排、灰度分批、高危拦截、熔断回退等核心功能。灰度分批变更典型的应用形式通常如下：此外，应建立变更模型和风险规则的关联机制，持续积累风险规则，通过工具能力自动识别风险，使得风险识别不依赖人，基于变更模型建立标准化的风险识别流程和能力，确保变更前风险有效识别。-灰度测试环境：提供独立的灰度坏境。变更在生产环境实施前，在灰度环境上提前实施变更，进行业务验证；3.基于流程和工具构筑变更风险控制能力，确保风险控制有效落地-生产环境分批实施：在生产环境中分批实施变更，优先选择小范围、重要性较低或影响可控对象实施变更，根据变更结果逐步放开批次。具体来说，应建立数字化的变更流程系统，从变更申请、变更评审、变更实施到变更验证建立完善的变更推送、闭环执行脚本/规则流程变更实施风险评审识别风险创建变更单拉取风险信息导入模型变更模型风险脚本/规则图2.18变更申请、评审流程27变更作业流水线变更作业子流程N变更作业子流程N+1生产批安全回滚灰度批批次2准入条件预检查批次1生产批灰度批批次2安全回滚准入条件批次1预检查安全回滚工具能力灰度分批安全回滚模板编排熔断机制高危拦截生产验证图2.19典型灰度分批变更应用形式变更验证阶段，通过功能验证、业务拨测等验证手段，对变更后的业务进行可用性验证，及时发现可能的风险。从系统架构层面，混沌工程可以验证系统的容错能力，推动提升系统的架构可用性；测试层面，混沌工程可以提前暴露线上问题，防止带病上线；运维层面，混沌工程可以让我们更好地理解和掌握系统的运行逻辑和规律，提升应急恢复效率，降低故障影响和损失，增强团队应急能力，建立系统抵御未知风险的信心。基于混沌工程挖掘未知风险，识别系统薄弱环节，持续提升系统韧性混沌工程核心思想：识别系统隐患，减少故障影响，提升系统韧性混沌工程的实施实践混沌工程实践可以按照如下步骤开展：混沌工程是一种实验性的可靠性工程提升方法，是通过主动模拟故障场景来验证系统在各种异常场景下的行为，通过比较假设行为和实际行为，发现系统存在的薄弱环节。在复杂的分布式系统中，交互关系和服务依赖错综复杂，难免会出现各种不可预料的突发事件，系统越复杂，越容易出现无法预知的故障。混沌工程旨在提前识别系统的未知风险，针对性地进行防范加强，让系统在每一次故障中获益，不断优化，持续提升系统的韧性，保障业务的连续可用。制定试验目标开展混沌演练之前，首先需要明确试验目标及假设，确保实验的有效性及针对性。例如，验证某应用系统在过载场景下的保护机制，假设当流量过载时，系统的哪些指标会发生什么变化，预期会有什么保护措施会触发等。28故障模式分析故障模式分析是混沌工程实践的关键环节，通过6维故障分析法，从冗余、容灾、备份、过载、依赖和安全维度，剖析系统的部署架构，逻辑架构和内外部的依赖关系，分析风险场景，选定故障模式，作为混沌演练的场景输入。云平台故障场景识别xx会议系统故障场景识别冗余lvs视频网关APIGnginx故障点故障场景分析故障场景分析容灾依赖安全备份前端负载均衡consoleframe6维故障分析法故障点故障点视频前端web01视频前端web02视频后端servicehaproxyhaproxy视频后端serviceapicomimsimsvpc故障点故障点pub-dbpub-db过载视频数据库DB图2.206维故障场景分析法如图所示，6维故障分析法对于云平台和业务应用场景的故障模式分析均适用。例如，对于应用系统中的关键模块，如web前端，在业务过载场景下，分析系统是否具备限流、降级或弹性扩容能力；对于数据库，在业务过载场景下，分析系统是否具备自我保护能力等条件。演练复盘进行演练复盘总结，从产品质量、预案质量和运作流程等方面识别改进点并优化。混沌工程平台构建混沌工程平是进行混沌演练的基础，完整的混沌工程平台需要具备故障模式管理、故障场景编排、故障注入、演练指挥、演练复盘等能力：制定应急预案根据故障场景，分析故障发生后的系统行为及影响，制定对应的应急预案。应急预案应包括故障的识别、影响范围确认、故障隔离、恢复验证等方面。故障模式管理提供丰富的故障模式库，如过载类故障、网络类故障、状态变化类故障等，基于故障模式可以构造业务故障场景。过载类故障包括磁盘IO高，CPU负载高，内存利用率高，网卡流量高等。网络类故障典型如网络丢包、网络时延、网络中断、网络错报、乱序、重复包等。状态变化类故障有kill进程、关机、重启、磁盘只读、停止服务等。故障演练根据故障场景实施故障注入，观察系统的行为是否符合预期，例如稳态指标观察，容错行为验证等，同时验证处置策略，恢复手段是否有效。29故障场景编排2.2应用运维现代化基于故障模式和资源对象，进行故障场景的灵活编排。2.2.1运维规划前置到设计阶段，业务可靠性来源于运维与设计的融合故障注入基于故障模式或故障场景，对资源对象进行故障注入，为系统引入错误行为。由于云上资源的多样性，故障注入需要支持各种类型的资源，包括主机、虚机、容器、数据库、中间件、进程等。随着核心业务持续上云，金融企业对应用高可用要求达到了5个9。业务一旦出现故障不但会影响经济效益，甚至会影响到国计民生，所以如何缩小应用故障的影响范围，保障核心业务数据不丢失就成了企业面临的头等问题。因此，应用高可用设计成为应用与基础设施现代化转型的关键。演练指挥设置演练指挥中心，制定演练计划，演练排班和应急预案，演练过程全程监控。然而，单纯依靠传统的运维方式已经难以保障业务的高可靠要求，运维需要前置到设计阶段，业务可靠性来源于运维与设计的融合。演练复盘分析演练数据，对演练过程进行复盘总结，输出演练报告，发掘改进环节并持续跟踪。1.业务容灾等级评估高可用设计并非单纯的技术问题，成本也是影响键。由于高可用设计需要大量的费用投入，而其产出并不能立竿见影地被直接感知到，所以对于高可用设计往往需要先解决“高可用设计成本与业务预期的冲突”问题。演练文化混沌工程要在企业内部有效落地，首先需要认可其所带来的价值，从组织、流程、文化建设方面引导，从上到下建立混沌演练文化。只有持续例行地开展演练工作，才能持续提升系统的容错性和可恢复性，系统的韧性才能得到不断提升。在投入成本方面，应用可用性要求越高，对应技术方案需要投入的成本也会越高。成本数据丢失损失成本数据可靠性成本应用可靠性成本应用宕机损失成本业务侧期望业务侧期望当前现状当前现状平衡点数据丢失时长(RPO)应用恢复时间(RTO)分钟0分钟普通业务重要业务关键业务重要业务普通业务图2.21高可用设计与业务冲突预期冲突分析30如图所示：当RPO和RTO都为0时，对应的高可用设计成本达到峰值；相反RPO和RTO时间比较高时，对应的高可用成本也会相应降低。如果所有业务都按照最高的高可用目标建设，金融企业将面临巨大的高可用投入成本，所以在技术设计前，首先要对业务灾备等级进行评估分类。基于应用的重要程度，数据一致性要求，时延敏感性等因素可以将业务划分为“关键业务”、“重要业务”和“普通业务”三个等级，重要程度依次降低。端边纵向可观测体系设计端侧监控请求量日志传输指标三方服务业务指标体系搭建时延吞吐2.业务容灾策略不同重要程度的业务选择不同的容灾策略：运维数仓汇聚运维数据关键业务的高可用设计原则是通过应用架构改造+部署架构改造，实现数据0丢失，同城多活，异地容灾，并缩小故障爆炸半径；配置告警图2.22典型运维数据治理流程重要业务则需通过调整应用的部署架构（无需调整应用架构），实现数据丢失趋于0，同城主备，异地容灾；进于一体的开箱即用的可观测性平台至关重要。构建这样一个应用可用性观测体系首先需要具备一个统一的运维数据仓库，以及完善的业务可观测指标设计。典型的运维数据治理流程主要包括运维数仓汇聚运维数据、业务指标体系搭建、端边纵向可观测体系设计三个步骤。运维数仓汇聚运维数据是基础，业务指标体系搭建是核心，端边纵向可观测体系设计是补充。普通业务无需对应用和部署架构作任何调整，仅需进行关键数据的定时备份即可。3.高可用的持续治理应用高可用的保障过程是一个持续的治理过程。在经历了前期的技术选型、方案设计、方案实施和方案验证后，还需建立完善的容灾管理制度，并通过专业的高可用技术团队持续跟踪和优化业务高可用的达成情况。所以应用高可用治理还涉及容灾团队建设、容灾状态监控、容灾演练以及知识管理等一系列工作，才能真正保障应用高可用目标的达成。运维数仓汇聚运维数据应用运行过程中会产生大量的运维数据，包括端侧数据、拨测网络数据、实例指标数据(Metrics)、日志数据(Logs)、调用链数据(Traces)等。这些运维数据需要一个统一的运维数据仓库进行承载。运维数仓主要由数据集成、ETL、数据湖、MPPDB、数据应用等功能组件构成，典型数据处理流程如下：2.2.2借助运维数仓构建应用可用性监控管理体系，实现业务故障实时感知定界应用可用性监控管理是面向应用运维的一个重要方面。着眼于持续现代化演进的应用可用性监控，建设一个围绕故障生命周期集预防、检测、诊断、恢复、通报和改数据集成：这些数据并非全部是结构化的数据，因此需要有完备的数据集成平台，支持多种运维数据接入，如消息队列、API集成、SFTP集成等。31数据抽取：数据接入之后由ETL对单条数据进行过滤、切分、扩展、格式化等操作，统一放到消息队列中。数据湖处理：不同的数据主体消费消息队列中的数据，完成不同的数据存储，如原始日志或者指标存放到OBS中、单条粒度数据直接入库或者通过格式定义存放到ClickHouse中、时序多维度量数据需要依据一定的数据治理规则分多个表保存在MPPDB中。数据应用：所有运维数据治理完成之后，由数据应用对数据进行API封装，提供对外统一查询接口。UniQueryServer运维数仓数据应用单条粒度运维数据[ClickHouse]时序多维度量数据离线数据分析数据仓库数据湖ETL后端数据订阅分发[Kafka]日志原始文件[HDFS/OBS]单条粒度运维数据单条数据过滤、切分、扩展、格式化[SparkStreaming/Flink]数据集成接入[Kafka/SFTP/HTTPS]数据集成端侧数据采集APMS拨测服务EchoTest指标监控系统Prometheus日志服务LogService调用链服务NuwaTrace自定义数据图2.23应用运维数仓典型架构业务指标体系搭建例，针对这些测试用例梳理黑盒化指标，如拨测类指标、规格类指标等；运维人员则根据运维过程中的问题持续对指标进行优化，三者相互配合，构建完备的业务可观测指标。业务可观测性指标是指在企业的业务层面上，通过监测、分析和理解数据，设计出来的用以表征业务运行情况、用户体验的业务指标。业务可观测性更加关注运行过程、用户旅程和客户交互等方面的可视化，从而帮助企业更好地理解业务的健康状况，给最终用户提供更好的用户体验。业务可观测性指标设计步骤通常情况下，业务可观测指标体系搭建主要分成如下四个步骤：业务可观测性指标梳理参与角色设计可观测性指标的前提是对业务系统功能有非常深入的理解，因此应用开发人员、测试人员、运维人员组成的“铁三角”缺一不可。开发人员可以对系统功能的实现逻辑进行白盒化剖析，通过监控和日志手段在开发阶段预埋相应的指标；测试人员更多从用户体验视角设计相应的测试用a.数据调研，分解业务要素指标设计人员将业务系统的功能进行拆解，梳理出业务核心功能点，每个功能点会产生的数据类型（结构化数据、日志、指标等），以及明确这些数据的作用。32b.梳理概念模型，构建总线矩阵每个核心功能点识别之后，就需要开发人员对每个核心功能点的业务过程进行白盒化梳理，包括每个业务过程需要关注的数据维度，以及每个维度对应的字段。以互联网应用“设备登录”业务过程为例，应用需要获取设备类型、设备品牌、登录地域、登录运营商、HTTP响应状态码、业务响应状态码等维度的数据。一致性维度业务过程业务过程一级二级请求来源Apple设备类型DevtypeProductID品类地理区域http响应码业务响应码运营商北向设备注册南向直连设备注册南向下挂设备注册南向批量下挂注册南向设备登陆设备注册设备登陆北向蓝牙设备数据上报北向三方设备数据上报南向设备数据上报设备数据上报设备查询设备控制设备认证北向设备注销南向设备注销设备注销南向鸿蒙设备重置图2.24设备登录业务过程总线矩阵举例c.逻辑模型设计根据总线矩阵，进行数据仓库逻辑模型设计，在维度建模中，有以下一些关键概念和组件：维度(Dimension)：维度是描述业务过程的属性或特征，用于对事实进行分类和分组。事实表(FactTable)：事实表是数据仓库中的核心表，包含了与业务过程相关的数值型度量或指标。事实表中的每一行通常表示一个业务事件或交易，并与一个或多个维度表相关联。在实际应用时，应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。维度表(DimensionTable)：维度表包含了描述事实表中度量的上下文信息，它们用于描述与“who、what、where、when、how、why”有关的事件，用于对事实进行分组和筛选的属性。33维度表事实表维度表层次结构(Hierarchy)：维度可以具有层次结构，即组织成多个级别的数据。例如，时间维度可以包含年、季度、月等层次。维度表维度表维度表维度表度量/原子指标(Measure)：原子指标和度量含义相同，是事实表中的数值型数据，表示业务过程的性能或结果，是用户在数据仓库中分析的关键指标。维度表维度表图2.25数据仓库维度模型——星形维度模型设备维度表歌曲播放事务事实表日期维度表维度设备编号DID设备内部型号设备产品传播名设备品牌日期[FK]设备编号DID[FK]设备产品传播名时间[FK]时间维度表设备品类华为账号编号UP_ID[FK]歌曲代理IO[FK]歌曲名称设备价格范围设备上市日期…歌曲专辑代理ID[FK]艺术家[FK]艺术家维度表账号维度表度量播放时长歌曲维度表有效播放时长播放次数…...歌曲专辑维度表图2.26星形维度模型实践举例34d.物理模型开发与上线应用完整的全链路监控是非常有价值的工作：物理模型开发就是在逻辑模型中填充数据的过程，填充的数据就是在总线矩阵中定义的数据，这些数据的来源主要是业务系统的数据库、日志、调用链(本质上也是日志)、指标数据等。而这些数据并非结构化数据，需要经过清洗，汇聚到数据仓库的物理表中，才能够让指标设计人员对指标进行进一步处理(如打标签或者派生指标设计)，最终完成业务可观测性指标上线。可以提升故障主动发现率，减少故障对业务的影响，提高系统的稳定性和可靠性。通过逐层下钻的数据分析能力，帮助快速定位和解决问题。通过对系统的实时监测和数据分析，提供决策支持，优化系统性能和资源利用率。端边纵向可观测体系设计应用运维的运维对象是应用，即是将“应用”作为一个独立的逻辑实体。所有该应用所使用的资源，如VM、Docker、中间件、数据库等，都是该“应用”的组成部分。所以对于应用运维来说，构建该上一章节主要阐释了指标体系如何构建，下面介绍如何根据这些能力构建一个典型应用的全链路监控模型。App/ServerKit边缘网络服务&微服务二方/三方AccountkitAudioKit…ELBWeb服务器数据库三方服务二方服务SLB应用NoSQL服务器Internet/骨干网&CDNAPP体验指标API性能指标边缘网指标服务&微服务性能依赖方性能下载成功率安装成功率首页打开耗时首页图片耗时用户搜索耗时应用详情耗时用户下载速率…API时延调用量成功率…带宽流量速率CDN…API时延主机性能中间件数据库基础设施…API时延调用量成功率…图2.28典型应用全链路监控模型：端边云纵向可观测体系35根据上图我们可以看出，一个应用要对最终用户产生价值，整个数据流是从端侧发起，经过接入侧、广域网、数据中心传输后，最终到达云上的服务端完成逻辑处理，再返回到端侧，完成一次完整的数据交互。其中在云上服务端处理的过程中，还存在与第三方外部服务调用的场景。在这个交互过程中，任何一个环节都可能影响到最终用户的使用和体验。所以对于应用的全链路监控来说，每个环节都应该尽可能地做好监控。处理，掌握传输过程的数据有利于在协同处理中更高效地完成故障修复。由于无法在传输节点上采集数据，这部分的时延数据一般可通过云侧与端侧的指标通过复合计算得到。而边缘加速网络的数据可以通过供应商的标准监控能力获取。云侧监控应用的云侧监控除了应用黄金指标外，还应包括构建该应用的资源监控。这部分的监控数据来源于云基础设施监控能力，但要