一、背景

云原生系统主要基于 DevOps、持续交付、容器化和微服务技术。智能运维（AIOps）是基于智能运维（AIOps）平台实现对整个 IT 运营管理（ITOM）的持续洞察。

智能运维由三个部分组成，观察（监控）、交互（ITSM）、行动（自动化）。监控包括对历史数据的分析、异常信息的检测、性能分析、数据之间的关联和数据情景化。交互包括任务的自动化处理、变更的风险分析、服务中心专员绩效分析以及知识管理。行动包括运维手册、脚本、应用程序自动化。

1.1 云时代业务开发模式发展

云时代业务开发模式发生了变化，要求我们更专注业务逻辑、编程的灵活性，运行的敏捷性以及快速响应的能力。

云时代业务开发模式有如下优缺点：

优点：

• 从系统开发到上线服务之间的时间越来越快
• 快速的对系统进行扩容

缺点：

• 开发的难度在降低，运维的难度在升高，运维成本高
• 压力和成本下沉

1.2 云原生系统

云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行弹性扩展的应用。云时代的代表技术包括容器、服务网格、微服务、不可变基础设施和声明 API。

从技术角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

云原生系统涵盖了 DevOps、持续交付、微服务和容器。DevOps 在新的软件开发模式下，加速了软件的开发速度。持续交付减少了业务上线、交付的时间。微服务的理念是将软件设计成为若干个小而精的软件产品，易于开发、交互和维护。容器技术是基础使能技术，使开发和部署软件系统的速度加快。

1.3 云原生系统可靠性保障挑战

1.3.1 云原生系统可靠性保障挑战1：系统复杂度高

现代云原生软件系统的规模呈现指数级增长，动辄上千个微服务，例如：WeChat 包含近 3000 个微服务，Netflix 超过 700 种微服务，Uber 包含的微服务多达 2200 个。

服务之间呈现复杂的调用关系，调用链跨越几十种微服务。

1.3.2 云原生系统可靠性保障挑战2：系统动态性高

由持续的集成和部署带来的软件系统的频繁更新和运行环境的动态性，容器生命周期短，造成运维算法、运维方式以及运维框架的失效，需要适应这个变化。

1.3.3 云原生系统可靠性保障挑战3：系统多样性增加

• 大量开源软件的使用，ELK、Kafka、K8S，……
• 不同的编程语言，Golang、Java、Nodejs、Python，……
• 不同的分布式框架，Dubbo、SpringCloud、gRPC，……
• 不同的云环境，AWS、IBM、Alibaba、On-Premise

综上，造成运维模式和方法的复杂性，难以形成统一的解决方案。

1.3.4 云原生系统可靠性保障挑战4：系统故障增加

云计算平台的数据中心，都是由大规模集群、容器组成，节点或者集群的故障很常见，因此当出现故障的时候，排查故障的难度和复杂度都很高。

1.3.5 云原生系统可靠性保障挑战5：运维数据复杂

随着技术发展对系统的观测越来越成熟，数据越来越全面，比如，KPI 指标数据、日志数据、告警事件、请求追踪数据，因此数据的量也越来越大，数据之间的关系也越来越复杂。

1.4 故障生命周期

故障从发生到解决经历检测、诊断、隔离、恢复等几个阶段，每个阶段都会产生造成一定的系统停机，影响系统整体的可用性。AIOPS 所包含的不同方法、技术分别对应减少不同的阶段时间，如：异常检测减少 MTTI（平均检测时间），根因定位减少 MTTD（平均故障诊断时间） 等。

云原生系统使故障的处理从提高 MTTF（平均失效发生时间）向降低 MTBF（平均失效间隔时间）转变。

1.5 智能运维

最初“A”的解释使 Algorithmic，即算法。现在指利用大数据、机器学习和其他分析技术，通过分析自动发现 IT 系统中的问题，并定位根因，甚至自动恢复系统，从而增强 IT 系统的稳定性、性能和可用性，为 IT 运维提供“端到端”的解决方法，最终做到“无人值守”。

智能运维（AIOps）平台可实现对整个 IT 运行管理（ITOM）的持续洞察。传统的开发与运维方法将得到改进，以解决软件系统日益复杂的问题。

1.6 挑战性问题

新的可观测性方法、新的异常检测方法、新的故障定位方法、新的故障恢复方案，快速恢复系统，有以下挑战

• 系统规模大，依赖关系复杂
• 系统多样性高，采用大量的开源软件
• 系统运行时动态性高
• 系统运行时故障种类多，发生频繁

1.7 基于 eBPF 的可观测性

• 全链路上下文监控
• 基于日志的异常检测及根因定位
• 基于调用链的异常检测及根因定位
• 多维指标异常检测及根因定位
• 多模态数据融合智能运维
• 多测故障注入方法及系统
• 微服务系统新能优化方法
• 数据驱动的故障恢复

二、可观测性

可观测性不是简单的观测，他是通过观测主动的解决问题。可观测性需要数据的支持，比如，调用链数据、日志数据、指标数据等等。

传统的监控存在若干问题

• 聚焦于会聚数据监控，缺少细粒度的指标监控
• 侧重独立的运维数据，缺少关联的上下文数据
• 与编程语言的耦合性高，使用和维护复杂

2.1 基于 eBPF 的云原生系统的可观测性

eBPF 可以在 Linux 内核中运行沙盒程序，而无需要更改内核源码或者加载内核模块。通过使 Linux 内核可编程，基础架构软件可以利用现有的层，使其具有更加智能、更加丰富，而无需继续为系统增加额外的复杂性。

基于 eBPF 的内核级别的监控技术，能够采集拓扑、业务指标、日志、系统调用等全栈指标，且产生较小的额外负载。

以无侵入方式获取业务拓扑图、L4 层连接信息以及 L7 业务信息，自动识别协议类型，支持 Http、Https、MySQL、Redis 等多种协议，具备灵活可扩展性。

2.2 基于 eBPF 的 Tracing

• 现在微服务系统过于复杂，端到端的请求追踪已经成为缺省配置
• 当前主流的追踪技术/系统包括：OpenTracing、OpenTelemetry、Skywalking 等
• 对源代码由侵入性，学习周期长，且不够灵活，软件升级带来的开销大
• 无法实现跨语言的特性，不同语言需要提供不同的 tracing 库

可以观测性——调用链

利用 eBPF Kprobe + Uprobe，在内核中透传 TraceID/SpanID，实现服务内部和外部完全透明的调用链追踪，不修改源代码，与协议无关，并且能否应对线程池、异步等复杂传输场景。

2.3 基于多模态数据融合的可观测性

基于 Opentelemetry 的全上下文监控方法，能够将调用链、指标和日志关联起来，辅助根因定位。

各个服务间独立打印日志，将 TracID 打印到日志中，通过 TraceID 关联日志上下文。

三、故障检测

3.1 主动性故障注入（混沌工程）

虽然现在智能运维的算法很多，但是缺少故障数据，导致真实的故障数据非常稀疏，这就需要我们通过主动注入故障制造更多的故障数据。

混沌工程逐渐流行起来，除了像 Chaos Monkey、Chaos Kong、chaoskube、Chaos Mesh、FIS 之外，很多企业都构建了属于自己的 故障注入系统。

下面表格中针对一些混沌工程工具对了比较：

通过比较发现，现存的混沌工程工具主要存在如下问题：

• 爆炸范围不可控侵
• 入代码
• 故障注入点随机
• 故障覆盖不完全

我们是这样做的，首先，使用路径驱动方式的故障点场景计算，告诉我们应该在哪里注入故障。然后，针对故障场景进行优先级排序，基于排序后的故障场景进行多层次多语言的故障注入，并对云原生应用进行抗故障人性能力评估。多层次的故障注入可以实现在 API 层面故障注入、进程层面故障注入、 OS 内核层面故障注入，网络通信层面故障注入、基础设施层面故障注入，也可以针对不同编程语言的故障进行故障。最后，生成可能性故障报告和性能故障报告。

3.2 请求全链路混沌测试

MicroFI 是具备爆破范围可控、故障注入点自主选择、故障空间搜索快的故障注入系统。此外，MicroFI 主要面向云原生环境能够在不入侵源码的情况下实现任意请求级别的故障注入。

请求标记：为请求打标记，标记出请求是要进行故障注入，还是放行请求。

协调器：针对请求如何注入故障，注入什么样的故障。

下面图展示了，如何以无侵入的方式实现故障请求标识的端到端传递，利用请求追踪的trace state 特殊字段，添加故障标记信息

3.3 故障检测方法归类

3.4 基于时空图神经网络的分布式系统异常将测

构成软件系统的服务之间有复杂的依赖关系，且处于动态变化中。

算法满足以下特性：

• 能够同时检测单点异常、模式异常和上下文异常
• 无监督，不需要标签数据
• 对系统的健康状态进行整体度量
• 允许系统拓扑变化

解决方案：

• 同时建模指标数据的空间（即拓扑）和时间（即时序）特性
• 采用图卷积神经网络模型
• 采用 自编码器模型
• 自适应阈值调整

提出了一种基于时空深度神经网络的异常检测方法，将 LSTM 神经网络和图神经网络结合起来构建变分自编码器，以捕捉书中的时空信息，更准确地发现分布式系统中出现的故障。

3.5 主动学习在智能运行上的应用

运维中有些领域已经引用了主动学习，也就是把人的反馈引入到系统中。主动学习的一个好处就是可以做到自适应。数据迁移、系统升级或者指标漂移后，主动学习可以自适应的进行调整。

3.6 基于主动学习的故障检测

基于主动学习的故障检测的基本流程下：

把多维的时序数据进行预处理，再根据异常检测模型进行检测，检测模型可根据标签数据的量选择无监督、半监督或者有监督的检测模型，异常点选择算法主要是帮我选出哪些点是真正的故障再推给运维专家，由运维专家确认该点是否为异常点。如果是异常则输出异常，同时反馈给检测模型，由模型进行自学习，完成自演化。

3.7 基于无监督主动学习的故障检测

针对多维指标故障检测问题，提出基于无监督主动学习的故障检测方法，引入专家反馈调整无监督异常检测模型，连续优化检测模型。

3.8 基于半监督主动学习的故障检测

假如加入有标签的故障数据，结果会不会更好呢？这就提出了一种基于半监督学习的变分自动编码器主动异常检测框架 SLA-VAE。SLA-VAE 首先基于特征提取模块定义异常，引入半监督 VAE 来识别多变量时间序列中的异常，并利用主动学习通过少量不确定样本更新在线模型。在进行半监督学习后，收敛效果确实好一些。

VAE基本思想 是一个空间到另一个空间的投影，在投影的空间更容易把正常和异常数据区分开。

3.9 可迁移故障检测

现在 ICT 系统如微服务系统、数据中心网络和运营商网络等规模和复杂性急速增加，为单个实体甚至单个指标单独维护异常检测模型的代价过大。

最好的情况就是训练一个模型，可以适用多个场景。模型可以做迁移的最好满足下面的可行性和必要性。

可迁移的可行性：

• 周期相似性
• 实体行为相关性

可迁移的必要性：

• 模型的训练时间短
• 模型体量小，占内存空间小，装在速度快

为了解决异常检测模型的跨实体/指标共享的问题，设计了基于 Transformer 的多指标/实体可共享的异常检测模型，真实数据集上的实验结果验证了方法的有效性。

3.10 基于 eEPF 的高性能日志在线约减

大规模云原生系统每天产生大量的日志，比如，微信每天都产生 16-20 PB 的数据。一般情况是，少数日志类型占据了大部分日志存储，也就是，“热点日志”占据了大部分。大量的热点日志也给系统（比如，内存、延时等）造成一定的系统开销和影响。

通过 eBPF 将日志拦截器写在内核里面实现日志的约减。通过 eBPF内核中能够实时的发现热点数据以及数据的过滤，在 eBPF 中，将还没有写到磁盘的无用日志直接丢弃，直接写失效。

3.11 基于深度学习的日志异常检测和问题定位

海量的日志数据，存在多种故障类型，日志内容频繁变化，而且日志之间具有上下文关联

为了从日志数据中检测故障，本项目提出了一种基于字典的日志模板提取方法，提取准确度超过了 95%，并在此基础上提出了基于 Bi-LSTM 的日志序列检测方法，检测精度可以达到 0.99。

基于序列分析的日志异常检测复杂度高，难以适配高速率日志系统；日志序列中存在大量冗余信息。

提出了基于日志序列相似性度量的日志特征推荐方法，降低日志序列分析复杂度，同时保障日志分析准确度。

3.12 基于 Sketch 的调用链异常检测

调用链数据量庞大，例如，微信每秒钟可能会产生百万条调用。这样的数据量使用基于神经网络的机器学习处理起来有些困难。所以，采用聚合的方式进行特征提取，再用复杂度较低的算法进行异常检测，速度上就会快很多。

利用 Sketch 技术实时计算指标分位数，并利用随机砍伐森林进行异常检测。

四、故障预测

4.1 基于 Transformer 的可迁移故障预测

云网系统在运行过程中产生大量具有不同采样周期的时间序列，对于这些时间序列进行长期和短期预测对系统资源调度、运维等有重要意义。针对这一问题，本课题提出了一种基于深度 Transformer 模型的可迁移的时间序列预测方法，该方法能够进行长短期预测，并能自适应数据的变化，在真实生产系统（腾讯）上进行了测试，测试效果优于当前最新的方法。

五、 故障定位

5.1 基于因果关系的指标级别根因定位

故障的发生会沿着“因果”链传播，不断地传播直到传播到业务上表现出来。最大的挑战就是怎么把业务的因果关系和指标的因果关系找出来。

5.2 基于调用链的根因定位方法

谱分析广泛用于代码故障根因定位，进行 Debug。谱分析就是利用通过和不通过所经的路径联合进行定位，找出故障的注入点。

利用基于谱分析的方法能够有效定位根因服务实例，但是，难以应对调用链种类稀疏的情况。

整合了基于调用链的谱分析以及 PageRank 方法能够更加准确定位根因，主要创新点为：同时利用正常调用链路和异常调用链路的信息提供的证据信息进行故障定位。

基于 Google 的 Hipster-shop 和 TainTicket 在超过 200 个微服务实例上进行了实验，模拟了多种类型的故障。

5.3 基于图模型的告警根因定位

告警在系统中是普遍存在的，在告警中附带了很多信息，比如，告警特征的描述、告警影响的服务、告警影响的指标，把这些信息抽取出来结构化以后，联合起来做一些告警的识别和定位的工作。

也就提出了一种方法来自动分析在线系统中可用性问题的级联效应，并提取相应特征，形成基于图的表示，将问题表现和受影响的服务属性结合起来。利用基于图神经网络的模型来执行事件检测。然后，利用 PageRank 算法来定位其根因。

六、故障恢复

6.1 真实故障分析

发现故障和隔离故障之后还是要恢复故障，那么，谁才是解决故障的最后一环呢？我们需要找到故障的根因，再列出可以恢复故障的方案有哪些？

微软公布了一些真实故障的根因以及恢复的方案：

故障清单中包含了大量的有价值的信息，用以帮助识别故障根因以及故障恢复手段，利用 NLP 技术和深度学习技术，可以从这些故障清单中自动抽取知识，形成知识图谱，根据故障特征和表象自动推荐根因以及修复方法。

也可以将 ChatGPT 模型压缩，并利用一直的故障进行对模型微调，获得故障处理模型可以定位根因以及推荐修复方案。

七、展望

7.1 基于 eBPF 的细粒度系统行为监控

7.2 透明的全链路上下文关联

将调用链、指标、日志进行关联统一，不仅可以检测异常，还可以解释异常。

7.3 软件定义的多层级智能运维

智能运维架构以软件定义的形式实现，分成数据面和控制面

• 数据面包含数据采集以及智能运维模型，下沉到操作系统内核以及交换机中，通过数据的“近场”计算，实现局部运维（System I），进行短期决策
• 控制面负责复杂模型的训练以及模型的下发，以及长期决策（System II）

7.4 如何找到简单、准确、通用的故障检测方法？

7.5 业务逻辑可感知的故障注入

在知道业务逻辑的情况下，做一些故障注入。

7.6 多源数据融合根因定位

多模态数据如何进行表征，表征以后如何进行推导，推导后如何进行泛化，以及如何进行转移（从一个场景转移到另一个场景），最后如何进行量化，这些都还需要进一步的讨论和系统的研究。

7.7 面向新型计算环境的故障管理

针对新型软件架构如 ServiceMesh、Function as a service、算力网络的智能运维。

八、总结

云原生是一种新的技术体系。云原生架构下，由于应用的服务数量多、访问关系复杂、访问路径长，使得可观测性变得越来越重要。将可观测、故障数据与机器学有机的结合起来，将会成为新技术体系下的利器。

本文参与华为云社区【内容共创】活动第22期。

任务33：云原生系统可观测性及可靠性关键技术研究