《中国智能运维实践年度报告（2022-2023）》之实践案例分享

某农商行运维可观测性实践

用户现状与需求

C行于2022年成功上线了基于“分布式应用+微服务架构”的新一代核心系统，旨在构建高性能、高可用性、以及具备弹性扩展能力。与此同时，经过多年的运维体系建设，C行的各种运维工具已经相对完备。这些工具包括但不限于业务流程控制（BPC）、系统监控、数据库监控、中间件监控、日志监控、网络监控、存储监控、以及应用性能监控（APM）等。此外，还包括用于日常运维管理的支撑工具，如IT服务管理（ITSM）工具、自动化巡检工具、堡垒机、自动化发布工具等。在日常运维工作中，可通过这些已有的监控工具及时发现业务、资源和网络等方面问题，通常情况下业务故障可以在3分钟内迅速掌握，然而由于核心系统已进行了分布式改造，实施微服务改进，这会在很大程度上影响运维和监控的效率。

1）业务系统关系变得更加复杂

核心系统规划和建设为8个中心，分别是支付中心、用户中心、员工中心、权益中心、交易中心、鉴权中心、计价中心和打印中心，每个中心均提供一个独立服务。在新一代核心系统上线后，资源节点数量呈几何级增长（达到几百个节点），因此当出现业务告警时，不同交易类型之间的端到端服务调用关系变得极为复杂，需要跨越多个业务系统和服务进行排查。在如此复杂的交易系统架构下，现有运维工具的有效故障定位变成了一项极具挑战性的任务，追踪和定位业务故障根本原因的效率也受到限制。

2）告警信息繁多

各类监控工具会产生大量的告警信息，特别是基础资源类告警，对于交易是否产生影响，一线人员难以进行有效的判断。绝大多数运维工具主要以技术视角为基础，缺少业务视角的考量，因此导致工具的利用率低。

3）工具和数据的离散导致分析繁琐

在业务故障发生时，行内运维工具会生成大量包括指标、日志、调用链和告警信息等运维数据。通常情况下，当开发人员与运维人员需要进行沟通、排障和故障定位时，涉及到多个内部工具之间的相互切换，以查看与交易故障相关的指标、日志、调用链等数据。这种多工具协作的方式限制了协作效率的提升。

图1 C行业务系统以及业务视角的场景

运维数据治理驱动的可观测性建设

运维数据治理挑战

在C行，运维数据治理面临着多重挑战，包括数据全面性、数据质量以及高质量运维数据平台的搭建等。笔者对构建可观测性平台所需的运维数据类型进行了总结（见下图），需要对已建成的内部工具进行审查，以确定它们是否包含了所有必要的底层数据源，并且关键数据类别（包括指标、链路、日志）是否满足可观测性数据质量的要求。数据质量的通用评价标准包括完整性、唯一性、有效性、一致性、准确性和及时性六个特性。如发现数据质量和数据类型未能满足可观测性数据质量的要求，可以采用逐步实施的逻辑，即“看大做小”来开展运维数据治理的工作。

图2 数据类型介绍

运维数据治理构建和实施

可观测性以及运维数据治理工作，应以指标（Metrics）、日志（Logging）和调用链（Tracing）的运维数据为基础，从业务出发、以交易视角有效地整合来自内部各种监控工具数据，实现对业务系统和交易的多维度数据关联分析和展示，以提供更全面的洞察。运维数据治理的实施是一个综合性的过程，需要同时考虑多个关键内容。

1）数据生成

数据生成是指被观测系统必须拥有生成规范化运维数据的能力。目前，在这方面内部各种运维工具已经生成了符合标准运维数据要求的数据，包括但不限于：日志中的全局流水号、交易日志的一致规范、APM中的链路追踪数据、各种监控工具的指标数据以及BPC中的业务交易数据等。在新核心项目启动初期，C行就已制定了多项技术规范，这些规范在全行各系统的改造过程中被严格执行。首先，全局流水号规范和应用日志规范都经历了相关改进，同时，通讯报文中所涉及的流水号也进行了规范化处理。全局流水号由初始端生成，贯穿一笔完整交易所经过的所有节点。此外，在全局流水号的基础上，对应用系统运行过程中产生的日志进行了统一规范。除了单独生成具有一致规则的链路日志外，链路信息也需要满足各个节点之间根据流水号进行上下级关联的要求。

2）数据采集与对接

通过观测系统对于不同来源、不同形态、不同介质的运维数据进行广泛且高效的采集、存储、治理，C行在项目中建设了统一采控平台，用于接入多种运维工具数据，统一采控平台以图形化可配置的方式实现第三方运维工具源数据接入。

C行在数据对接工作中采集了多个运维工具的数据，分为监控类工具与非监控类工具。监控工具包括日志监控工具、APM工具、BPC工具、数据库监控工具、中间件监控工具、操作系统工具、网络监控工具、统一告警工具、自动化巡检工具；非监控类工具包括配置管理工具、流程工具、堡垒机、自动化发布工具等。

3）运维数据清洗

运维数据清洗实现了对运维数据的预处理，以保证数据的质量和准确性，在C行数据的数据清洗主要包括：

APM工具数据清洗逻辑包含应用服务类指标数据清洗。例如服务概览性指标：APM响应时间(ms)--Response-平均、APM请求吞吐率(tps)--Throught--平均、APM错误率(%)--Error--平均、Apm异常数（code  external logged）；例如运行时刻指标：Heap memory Usage、Eden Space、Old Gen、Survivor Space、Metaspace、Thread Count。

日志数据清洗逻辑：通过日志中全局流水号清洗出业务系统之间调用关系，主要日志字段如下表所示。

图3 日志数据释义

BPC数据清洗逻辑：BPC对接数据包含BPC交易业务指标和交易明细数据,通过消费Kafka数据进行对接。主要业务指标包含：

--交易总量：发送请求数；

--交易响应时间：响应数据包时间戳-请求时间戳；

--交易响应率：有响应的笔数除以请求数；

--交易成功率：成功的笔数除以有响应的笔数；

交易明细数据接入查询逻辑：在进行业务系统的业务分析时，根据交易明细数据中内容再在日志中找到全局流水号，后端可以通过BPC自带的FlowId关联具体的交易详情。

CMDB数据清洗逻辑：对接行内配置数据以及配置关系数据，每天更新，从CMDB系统获取CI及CI关系数据逐条与数据中台昨日配置数据进行对比（表中存在则更新，不存在则新增），对比完成后再删除更新时间为昨日的配置数据。

基础监控数据清洗逻辑：通过API接口或者采集数据库方式实现实时性能指标数据接入（指标的IP标签与CMDB中各主机模型中IP属性做映射），采集频率1min采集一次，清洗数据存入数据处理平台对应表。

自动化发布数据清洗逻辑：对接内容：变更记录（系统名称、SysId、IP、变更单号、变更时间），对接方式采用对接自动化发布平台数据库MariaDB。

自动化巡检数据清洗逻辑：通过接口方式调用自动化平台把主机巡检结果返回给可观测系统，主机与应用系统关系通过CMDB进行关联。

统一告警数据对接详情，数据清洗逻辑：行内统一告警平台输入数据到对应Kafka主题，其中原始告警消息需要按照可观测系统的格式要求返回。

4）数据分析建模

基于专家经验、规则、AI等对观测数据进行建链、富集、洞察、预测等不同层次的数据分析，建立相关场景的数据模型。为了便于后期维护扩展，接入的第三方运维工具的原始数据通过可配置的数据清洗任务，输出标准化数据到具体的数据模型中，数据模型遵循下面可观测场景架构建立。

图4 可观测性场景架构

可观测性场景构建与落地

在C行，需要建设的运维可观测性核心场景不只是基于opentrace/opentelemetry的链路数据展示，而是要结合业务交易数据、以架构、场景、日志数据、指标数据、链路数据、告警数据为主，变更（自动发布、堡垒机、巡检、日志）、属性、CI、关系、健康度为辅的数据串联/下钻/分组聚合。以实现横向到边的服务调用链路、纵向到底的配置管理关系图，以及这个架构可视化之上的多种可观测性场景的应用，为此C行规划了两个阶段来逐步落地。

图5 横行到边，纵向到底（示例）

一阶段建设：夯实数据，横纵可视

本阶段重点是运维数据融合场景，以业务交易视角进行行内现有运维工具数据融合串联，即实现以交易视角串联各个运维工具中汇聚数据，也能实现单笔业务追踪能力。

以交易维度构建上层可观测场景，当交易出现故障时，例如“手机银行1分钟平均交易响应时间超过2000毫秒”，此类告警属于交易性能下降的业务告警，此时通过可观测性平台可以快速定位到交易性能下降的根本原因是什么，通过数据驱动的业务系统调用拓扑，可以清晰的了解到造成该交易性能下降是由于哪些业务系统造成的，点击进入到有问题的业务系统，可以通过链路追踪拓扑看到业务系统内部的服务调用异常节点，可以通过配置关系拓扑+关联指标数据快速定位是哪些基础资源故障造成的业务性能下降。通过BPC数据及单笔报文数据可以追溯到单笔交易流经了哪些业务系统、哪些服务、影响时间等等，业务交易的内部逻辑及调用关系清晰可见。交易故障的根因定位时间由原来50-60分钟缩短到15分钟左右。

本阶段建设涵盖了13种工具数据的接入和未来的维护工作，既要充分考虑已建成的13个运维工具的现有接口能力，又要考虑这13类工具数据格式质量不同问题。对于工具快速接入，可通过前台页面配置地址、端口以及鉴权信息完成这13种运维工具数据采集；对于数据格式及数据质量各不相同问题，利用可观测平台中数据中台能力对接入的运维数据进行标准化工作，运维数据清洗过程前台可见，数据清洗逻辑由不同的数据清洗任务组成，每个清洗任务里包含符合运维数据特征的清洗算子，对于数据清洗任务有单独的模块进行监控，保证清洗任务的及时性有效性。除此之外，考虑到海量运维数据存储问题，数据平台利用CK技术栈实现了运维数据存储，确保不同数据在IO和压缩比上获得平衡，这比传统ES技术栈节约了30%以上的存储空间。

图6 面向业务视角的全栈可观测性示例（拓扑）

通过可观测场景的构建，提升了50%运维数据消费支撑能力，平台未建成前，对外提供的运维数据质量、提供数据的效率都无法及时的保证；而在平台建设后，全行级运维数据（指标、日志、告警、调用链、配置数据、关系数据等）接入后，通过数据治理组件，有效输出标准化运维数据供上层场景进行数据消费。

二阶段建设：快速定位，智能分析

基于一期建设的成果，C行已能实现对于简单交易故障的快速定位。但对于复杂架构下的交易故障根因，C行仍希望进一步缩短定位所需时间，期望是将复杂交易故障的定位时间从目前的平均15分钟缩短至5分钟以内。

例如故障发生时，“手机银行”（业务系统）内“跨行转账”（交易类型）在上海地区近5分钟内交易中断（无法进行交易）），“手机银行”（业务系统）内“跨行转账”（交易类型）在上海地区近5分内交易延迟过高（2000ms））。针对此类从业务视角出发的故障分析，融合各种运维数据的智能化场景是显著提升故障定位速度的有效手段，通过应用算法技术，自动推荐业务系统交易中断或交易性能下降的故障根本原因。通过智能化根因技术手段，借助已知交易类型的历史故障根因知识图谱，实现快速根因定位。其次，对开展未知交易类故障的根因知识图谱计算。并根据动态决策树，进行根因计算和定位，以进一步提高故障定位的效率。

在进行中的二阶段建设过程中，C行客户还提到了多个数据融合的智能场景探索，包括容量预测、告警以及日志分析各个领域。

智能容量预测：通过指标预测的智能化算法沉淀，可以弥补之前“运维事前”的欠缺的预测能力，平台可以通过算法对容量（业务指标、技术指标）等性能指标进行动态预测，可生成图形化曲线图，可以直观看到容量指标未来趋势走向，为业务底层计算资源扩缩容提供客观数据参考。

智能告警：通过指标异常检测的算法沉淀，可以提升告警60%的准确率。平台建成后告警除了静态阈值机制外，还支持同、环比机制，动态阈值机制，可以大幅降低之前系统抖动或者在特定运维时间（批量、变更）出现大量无效告警的情况。

智能日志分析：通过日志模式识别/异常检测场景，可以补充原有系统只能通过关键字进行日志数据分析的能力。平台落地后可以直接对接原始日志内容，完成数据分析实现故障发现。对专家的依赖度低，且开箱即用，业务价值交付快。

《中国智能运维实践年度报告（2022-2023）》之实践案例分享

某农商行运维可观测性实践

用户现状与需求

C行于2022年成功上线了基于“分布式应用+微服务架构”的新一代核心系统，旨在构建高性能、高可用性、以及具备弹性扩展能力。与此同时，经过多年的运维体系建设，C行的各种运维工具已经相对完备。这些工具包括但不限于业务流程控制（BPC）、系统监控、数据库监控、中间件监控、日志监控、网络监控、存储监控、以及应用性能监控（APM）等。此外，还包括用于日常运维管理的支撑工具，如IT服务管理（ITSM）工具、自动化巡检工具、堡垒机、自动化发布工具等。在日常运维工作中，可通过这些已有的监控工具及时发现业务、资源和网络等方面问题，通常情况下业务故障可以在3分钟内迅速掌握，然而由于核心系统已进行了分布式改造，实施微服务改进，这会在很大程度上影响运维和监控的效率。

1）业务系统关系变得更加复杂

核心系统规划和建设为8个中心，分别是支付中心、用户中心、员工中心、权益中心、交易中心、鉴权中心、计价中心和打印中心，每个中心均提供一个独立服务。在新一代核心系统上线后，资源节点数量呈几何级增长（达到几百个节点），因此当出现业务告警时，不同交易类型之间的端到端服务调用关系变得极为复杂，需要跨越多个业务系统和服务进行排查。在如此复杂的交易系统架构下，现有运维工具的有效故障定位变成了一项极具挑战性的任务，追踪和定位业务故障根本原因的效率也受到限制。

2）告警信息繁多

各类监控工具会产生大量的告警信息，特别是基础资源类告警，对于交易是否产生影响，一线人员难以进行有效的判断。绝大多数运维工具主要以技术视角为基础，缺少业务视角的考量，因此导致工具的利用率低。

3）工具和数据的离散导致分析繁琐

在业务故障发生时，行内运维工具会生成大量包括指标、日志、调用链和告警信息等运维数据。通常情况下，当开发人员与运维人员需要进行沟通、排障和故障定位时，涉及到多个内部工具之间的相互切换，以查看与交易故障相关的指标、日志、调用链等数据。这种多工具协作的方式限制了协作效率的提升。

图1 C行业务系统以及业务视角的场景

运维数据治理驱动的可观测性建设

运维数据治理挑战

在C行，运维数据治理面临着多重挑战，包括数据全面性、数据质量以及高质量运维数据平台的搭建等。笔者对构建可观测性平台所需的运维数据类型进行了总结（见下图），需要对已建成的内部工具进行审查，以确定它们是否包含了所有必要的底层数据源，并且关键数据类别（包括指标、链路、日志）是否满足可观测性数据质量的要求。数据质量的通用评价标准包括完整性、唯一性、有效性、一致性、准确性和及时性六个特性。如发现数据质量和数据类型未能满足可观测性数据质量的要求，可以采用逐步实施的逻辑，即“看大做小”来开展运维数据治理的工作。

图2 数据类型介绍

运维数据治理构建和实施

可观测性以及运维数据治理工作，应以指标（Metrics）、日志（Logging）和调用链（Tracing）的运维数据为基础，从业务出发、以交易视角有效地整合来自内部各种监控工具数据，实现对业务系统和交易的多维度数据关联分析和展示，以提供更全面的洞察。运维数据治理的实施是一个综合性的过程，需要同时考虑多个关键内容。

1）数据生成

数据生成是指被观测系统必须拥有生成规范化运维数据的能力。目前，在这方面内部各种运维工具已经生成了符合标准运维数据要求的数据，包括但不限于：日志中的全局流水号、交易日志的一致规范、APM中的链路追踪数据、各种监控工具的指标数据以及BPC中的业务交易数据等。在新核心项目启动初期，C行就已制定了多项技术规范，这些规范在全行各系统的改造过程中被严格执行。首先，全局流水号规范和应用日志规范都经历了相关改进，同时，通讯报文中所涉及的流水号也进行了规范化处理。全局流水号由初始端生成，贯穿一笔完整交易所经过的所有节点。此外，在全局流水号的基础上，对应用系统运行过程中产生的日志进行了统一规范。除了单独生成具有一致规则的链路日志外，链路信息也需要满足各个节点之间根据流水号进行上下级关联的要求。

2）数据采集与对接

通过观测系统对于不同来源、不同形态、不同介质的运维数据进行广泛且高效的采集、存储、治理，C行在项目中建设了统一采控平台，用于接入多种运维工具数据，统一采控平台以图形化可配置的方式实现第三方运维工具源数据接入。

C行在数据对接工作中采集了多个运维工具的数据，分为监控类工具与非监控类工具。监控工具包括日志监控工具、APM工具、BPC工具、数据库监控工具、中间件监控工具、操作系统工具、网络监控工具、统一告警工具、自动化巡检工具；非监控类工具包括配置管理工具、流程工具、堡垒机、自动化发布工具等。

3）运维数据清洗

运维数据清洗实现了对运维数据的预处理，以保证数据的质量和准确性，在C行数据的数据清洗主要包括：

APM工具数据清洗逻辑包含应用服务类指标数据清洗。例如服务概览性指标：APM响应时间(ms)--Response-平均、APM请求吞吐率(tps)--Throught--平均、APM错误率(%)--Error--平均、Apm异常数（code  external logged）；例如运行时刻指标：Heap memory Usage、Eden Space、Old Gen、Survivor Space、Metaspace、Thread Count。

日志数据清洗逻辑：通过日志中全局流水号清洗出业务系统之间调用关系，主要日志字段如下表所示。

图3 日志数据释义

BPC数据清洗逻辑：BPC对接数据包含BPC交易业务指标和交易明细数据,通过消费Kafka数据进行对接。主要业务指标包含：

--交易总量：发送请求数；

--交易响应时间：响应数据包时间戳-请求时间戳；

--交易响应率：有响应的笔数除以请求数；

--交易成功率：成功的笔数除以有响应的笔数；

交易明细数据接入查询逻辑：在进行业务系统的业务分析时，根据交易明细数据中内容再在日志中找到全局流水号，后端可以通过BPC自带的FlowId关联具体的交易详情。

CMDB数据清洗逻辑：对接行内配置数据以及配置关系数据，每天更新，从CMDB系统获取CI及CI关系数据逐条与数据中台昨日配置数据进行对比（表中存在则更新，不存在则新增），对比完成后再删除更新时间为昨日的配置数据。

基础监控数据清洗逻辑：通过API接口或者采集数据库方式实现实时性能指标数据接入（指标的IP标签与CMDB中各主机模型中IP属性做映射），采集频率1min采集一次，清洗数据存入数据处理平台对应表。

自动化发布数据清洗逻辑：对接内容：变更记录（系统名称、SysId、IP、变更单号、变更时间），对接方式采用对接自动化发布平台数据库MariaDB。

自动化巡检数据清洗逻辑：通过接口方式调用自动化平台把主机巡检结果返回给可观测系统，主机与应用系统关系通过CMDB进行关联。

统一告警数据对接详情，数据清洗逻辑：行内统一告警平台输入数据到对应Kafka主题，其中原始告警消息需要按照可观测系统的格式要求返回。

4）数据分析建模

基于专家经验、规则、AI等对观测数据进行建链、富集、洞察、预测等不同层次的数据分析，建立相关场景的数据模型。为了便于后期维护扩展，接入的第三方运维工具的原始数据通过可配置的数据清洗任务，输出标准化数据到具体的数据模型中，数据模型遵循下面可观测场景架构建立。

图4 可观测性场景架构

可观测性场景构建与落地

在C行，需要建设的运维可观测性核心场景不只是基于opentrace/opentelemetry的链路数据展示，而是要结合业务交易数据、以架构、场景、日志数据、指标数据、链路数据、告警数据为主，变更（自动发布、堡垒机、巡检、日志）、属性、CI、关系、健康度为辅的数据串联/下钻/分组聚合。以实现横向到边的服务调用链路、纵向到底的配置管理关系图，以及这个架构可视化之上的多种可观测性场景的应用，为此C行规划了两个阶段来逐步落地。

图5 横行到边，纵向到底（示例）

一阶段建设：夯实数据，横纵可视

本阶段重点是运维数据融合场景，以业务交易视角进行行内现有运维工具数据融合串联，即实现以交易视角串联各个运维工具中汇聚数据，也能实现单笔业务追踪能力。

以交易维度构建上层可观测场景，当交易出现故障时，例如“手机银行1分钟平均交易响应时间超过2000毫秒”，此类告警属于交易性能下降的业务告警，此时通过可观测性平台可以快速定位到交易性能下降的根本原因是什么，通过数据驱动的业务系统调用拓扑，可以清晰的了解到造成该交易性能下降是由于哪些业务系统造成的，点击进入到有问题的业务系统，可以通过链路追踪拓扑看到业务系统内部的服务调用异常节点，可以通过配置关系拓扑+关联指标数据快速定位是哪些基础资源故障造成的业务性能下降。通过BPC数据及单笔报文数据可以追溯到单笔交易流经了哪些业务系统、哪些服务、影响时间等等，业务交易的内部逻辑及调用关系清晰可见。交易故障的根因定位时间由原来50-60分钟缩短到15分钟左右。

本阶段建设涵盖了13种工具数据的接入和未来的维护工作，既要充分考虑已建成的13个运维工具的现有接口能力，又要考虑这13类工具数据格式质量不同问题。对于工具快速接入，可通过前台页面配置地址、端口以及鉴权信息完成这13种运维工具数据采集；对于数据格式及数据质量各不相同问题，利用可观测平台中数据中台能力对接入的运维数据进行标准化工作，运维数据清洗过程前台可见，数据清洗逻辑由不同的数据清洗任务组成，每个清洗任务里包含符合运维数据特征的清洗算子，对于数据清洗任务有单独的模块进行监控，保证清洗任务的及时性有效性。除此之外，考虑到海量运维数据存储问题，数据平台利用CK技术栈实现了运维数据存储，确保不同数据在IO和压缩比上获得平衡，这比传统ES技术栈节约了30%以上的存储空间。

图6 面向业务视角的全栈可观测性示例（拓扑）

通过可观测场景的构建，提升了50%运维数据消费支撑能力，平台未建成前，对外提供的运维数据质量、提供数据的效率都无法及时的保证；而在平台建设后，全行级运维数据（指标、日志、告警、调用链、配置数据、关系数据等）接入后，通过数据治理组件，有效输出标准化运维数据供上层场景进行数据消费。

二阶段建设：快速定位，智能分析

基于一期建设的成果，C行已能实现对于简单交易故障的快速定位。但对于复杂架构下的交易故障根因，C行仍希望进一步缩短定位所需时间，期望是将复杂交易故障的定位时间从目前的平均15分钟缩短至5分钟以内。

例如故障发生时，“手机银行”（业务系统）内“跨行转账”（交易类型）在上海地区近5分钟内交易中断（无法进行交易）），“手机银行”（业务系统）内“跨行转账”（交易类型）在上海地区近5分内交易延迟过高（2000ms））。针对此类从业务视角出发的故障分析，融合各种运维数据的智能化场景是显著提升故障定位速度的有效手段，通过应用算法技术，自动推荐业务系统交易中断或交易性能下降的故障根本原因。通过智能化根因技术手段，借助已知交易类型的历史故障根因知识图谱，实现快速根因定位。其次，对开展未知交易类故障的根因知识图谱计算。并根据动态决策树，进行根因计算和定位，以进一步提高故障定位的效率。

在进行中的二阶段建设过程中，C行客户还提到了多个数据融合的智能场景探索，包括容量预测、告警以及日志分析各个领域。

智能容量预测：通过指标预测的智能化算法沉淀，可以弥补之前“运维事前”的欠缺的预测能力，平台可以通过算法对容量（业务指标、技术指标）等性能指标进行动态预测，可生成图形化曲线图，可以直观看到容量指标未来趋势走向，为业务底层计算资源扩缩容提供客观数据参考。

智能告警：通过指标异常检测的算法沉淀，可以提升告警60%的准确率。平台建成后告警除了静态阈值机制外，还支持同、环比机制，动态阈值机制，可以大幅降低之前系统抖动或者在特定运维时间（批量、变更）出现大量无效告警的情况。

智能日志分析：通过日志模式识别/异常检测场景，可以补充原有系统只能通过关键字进行日志数据分析的能力。平台落地后可以直接对接原始日志内容，完成数据分析实现故障发现。对专家的依赖度低，且开箱即用，业务价值交付快。