从故障演练到运维工具产品力评测的探索 | 龙蜥技术 原创

编者按：随着 AI 和云原生技术的发展，运维工具的作用越来越大，对快速发现业务系统的稳定性、及时告警、根因分析上起到关键作用。当前，业界涌现出了很多优秀的运维工具，但也有不少工具存在低质、重复、难用、兼容性差等特点。龙蜥社区系统运维联盟通过对特定的业务系统进行故障注入，将不同的运维工具放在一起进行评估和评测，让优秀的工具脱颖而出。

系统架构的演变

随着互联网行业的发展，如电商、短视频等应用的架构也在飞速发展。总体来说，系统的架构大致经历了：单体应用架构->分布式架构->微服务架构的演变，当然，目前已经向服务化网格（Service Mesh）演变。

早期，一般的网站流量较小，采用的是单体应用架构，即把系统中所有的功能、模块、组件等耦合在一个应用中，通常运行在同一个进程中，共享一个数据库。这种模式简单直观，可以减少开发、部署和维护的成本，适合小型应用的快速开发，但其缺点也很明显：无法水平扩展、模块耦合大等。

演进到分布式架构时，重复的业务代码被抽象出来作为统一服务被其他业务代码或模块调用，形成了服务层和表现层，服务层封装了具体的业务逻辑供表现层调用，表现层负责处理与页面的交互操作。分布式架构提高了代码复用性，提升了整体的访问性能。但是这种架构调用关系也比较复杂，难以进行维护。

​

微服务架构，即将一个大的应用拆分成多个小的应用，这些小的应用相对独立，有自己的运行进程，相互之间通过消息传递或远程调用进行通信。系统中的各个微服务可独立开发，独立部署，独立运维，各个微服务之间是松耦合的，有利于扩展和维护。但是其开发成本较高，系统复杂，存在数据一致性难以保证等问题。

架构变化带来的问题

随着架构越来越复杂、应用越来越多样，特别是 K8s 场景下，服务之间的调用层级越来越多，这给业务系统的稳定性、运维工具的有效性提出了挑战：

• 某一模块的大规模变更过程导致稳定性故障频发。
• 架构的复杂化导致传统的保障方式无法满足稳定性需求。
• 监控警报、运维工具等基础设施在故障出现时是否能有效工作。

针对架构变化带来的稳定性问题，特别是用户和流量规模越大，影响将越致命。除了确保业务上线时必要的测试外，还需要针对性的做重点保障，比如一个游戏业务新上线时特别安排了为期一两个月的重保行动。

另外，当前针对系统的保障方式，也只能做到出现问题后的补救行为，我们能否在运维工具上，快速的发现问题并且预警，提前进行主动运维？这就需要我们在监控、可观测领域，研发、采购产品力更强的运维工具（比如当前云原生的可观测运维产品），实时的采集系统运行的指标，根据指标的异常情况，提前做故障预测，通过智能分析算法，给出根因分析，提出修复建议，以快速的发现和解决问题。

这就需要通过故障演练的方式，提前发现问题、解决问题，发现运维工具存在的指标不够、告警不力、根因分析不足等问题，也要组织演练。

为什么需要故障演练

云原生技术的发展，微服务架构、容器化技术广泛使用，软件架构的复杂度在不断提升，由服务之间的依赖所带来的不确定性也呈指数级增长，任何一环出现非预期或者异常的变化，都可能对其他服务造成非常大的影响。因此，有必要构建一个故障演练平台和机制，来提升系统架构的容错能力和韧性，验证整个故障定位能力和恢复体系。

下图是针对不同的演练阶段，在不同的演练环境下进行的演练任务，目的也是通过故障注入案例，在测试环境、灰度环境、生产环境上验证系统稳定性、运维告警平台的有效性而开展的一系列活动。

另外，根据故障处理的一般流程，故障演练也可以归纳为三个阶段：

• 事前：及时发现风险，做好架构、预案、演练。
• 事中：及时发现故障，及时定位，及时止损。
• 事后：排查根因，落实复盘改进项。

故障演练，主要是模拟线上环境可能遇到的各种问题进行提前摸底测试，既可以对业务系统的稳定性进行检验，也可以对运维工具的综合能力进行检验。

在生产环境上进行的故障演练是最高级别的演练，非常考验案例注入的丰富性及系统的控制编排能力（混沌工程）、可观测平台告警和根因分析能力、数据的隔离能力，这就会涉及到下一节谈到的全链路压测。

全链路压测如何来做？

有了故障演练，为何还要搞全链路压测？这是因为某些问题只有在真正的大流量下才会暴露，比如网络带宽、系统间影响、基础依赖等等。

很多人可能也会问，双十一等大促时，全链路压测到底是怎么做的？全链路压测不仅仅是做压测，更多的是进行一次真实的大促预演，预案演练、限流验证、破坏性演练等高可用方案的统一验收。

全链路压测需要考虑的一个重要问题，就是生产环境的数据隔离：在生产环境进行写压测时，需要保证在压测进行的同时不影响线上业务的正常运行。采取的方案是将压测产生的数据与生产的真实数据隔离存储，避免脏数据对线上业务产生影响。目前有两种隔离方案：影子表方案、影子库的数据隔离方案。

本文简单介绍一下影子库方案，它是在同一个实例上建立对应的影子库。用户服务挂载的压测探针获取到流量标之后进行相应的旁路处理；如果是影子流量，那么会从影子连接池中获取影子连接供业务侧使用，从而将压测流量产生的数据旁路到对应的影子库中，以此达到数据和生产库隔离的效果，从而避免了压测流量产生的数据对生产库造成污染。

有了故障演练和全链路压测后，业务可以上线，我们的运维工具是否就无用武之地呢？答案是非也。一般的，大型的云原生系统都会上可靠的可观测工具为业务系统进行保驾护航。那么，通过故障演练和全链路压测验证过的运维工具，成为我们挑选工具的重要参考。有必要设计各类故障演练场景，来进行一场“选秀”活动。

故障演练场景有哪些？

故障演练场景有很多，从单个系统应用的维度、集群组件视角维度去构造案例，以检验我们业务系统的稳定性，更重要的是提前发现问题的能力，这对运维工具提出越来越高的要求，挑战也越来越大。

从垂直技术架构层次，设计演练场景：

从集群和组件维度，设计演练场景：

针对不同的业务场景、部署场景进行演练，我们可以对运维工具进行全方位的评估，比如通过混沌工程制造一个网络丢包案例，运维工具能否在毫秒时间内进行告警报错，能否从应用监控维度发现造成的建联失败、超时等问题，同时报告出错的点是在 OS 内核位置，还是云场景中的云网络丢包还是物理网络丢包。

如果是构造了一个访问空指针造成系统宕机的场景，集群维度的运维工具是否能快速检测到单节点出的故障，抓取 vmcore 信息并分析造成宕机的根因，然后报告节点健康度状态，根据影响做出迁移动作，非常考验运维工具的综合能力。

如何对工具进行评估

从上文故障演练的介绍可知，在问题预警、问题发现、根因排查方面，运维工具的作用非常大，对快速发现业务系统的稳定性、及时告警、根因分析上起到关键作用。运维工具的丰富度、告警是否及时、指标是否有效等能力，稳定轻量、易于使用、功能全面、社区支持等，也是参考的重要指标。因此，结合故障演练环节对运维工具进行评估，是一个非常有效的手段。

在成熟的业务系统上，部署一套运维工具，特别是常态化开启的监控工具，如可观测场景下经常会通过 profiling 进行系统性能剖析，往往会对业务系统带来一定的性能开销，也就是我们的运维工具上去之后，必须保障对原系统影响较小，即挑选一个功能丰富、性能开销较小、存储费用较少、能进行故障预测和告警、提供根因分析和修复建议（即具备智能化分析能力）的运维产品，将是重要目标。

总结起来对运维工具的评估，会考虑以下方向：

• 资源占用少。运维工具本身占用 CPU、内存等资源要小，不能占用比我业务系统还大的资源，本末倒置！
• 对原业务系统无影响。上工具前，先问一句工具是否可靠，不能把我的系统搞挂。否则，我业务都没了，还要你的工具做什么。
• 响应及时性，告警有效性。有问题先告警，别乱报啊！
• 分析准确性，功能一致性。监控和 profiling 功能要稳，根因分析要准确，一致！
• 数据成本低。日志、指标、追踪数据要精简，能定位问题，但指标不宜过多。多了我可买不起，不瞎折腾！
• 易用性好，易部署、易升级。操作简便，别整高大上的花里胡哨但解决不了问题的东西！
• 架构可移植性好，不同平台、不同版本兼容。考虑 X86、Arm 及 eBPF 在不同内核版本的兼容性等。

下面，分别从功能、告警、观测指标评估项上进行细化讨论。

功能评测项

1. 基础功能完备性：

• 系统监控：对 CPU、内存、磁盘、网络流量等基础资源的实时监控能力。
• 应用层监控：API 接口调用监测、数据库性能监控、容器/微服务状态监控等。
• 自定义指标支持：是否允许用户自定义监控指标和阈值。

2. 告警配置灵活性：

• 多条件组合告警规则设置：支持多维度数据聚合与逻辑运算进行告警触发判断。
• 告警策略管理：如重复告警抑制、告警升级机制、告警合并等功能。

3. 故障定位精准度：

• 根因分析：提供故障根因分析工具或功能，能快速定位问题源头。
• 故障排查路径追踪：记录并展示故障发生时的事件链路，辅助排查过程。

告警评测项

1. 告警延迟检测：

• 实时告警触发时间与实际故障发生时间之间的差距。
• 平均告警延迟时间统计。

2. 告警通道覆盖范围：

• 支持的告警通知方式（短信、电话、邮件、企业微信、钉钉等）。
• 第三方集成：与其他告警渠道和服务集成的能力。

3. 告警触发阈值敏感度：

• 对异常情况的敏感程度以及告警阈值设定的合理性。

4. 告警通知频率控制：

• 在持续异常期间告警频率的调整策略，避免过多重复告警。

观测指标评测项

1. 可观测数据源丰富度：

• 日志观测：日志收集、解析、搜索及关联分析能力。
• 时序数据观测：对各种时序数据（如系统性能指标、业务关键指标）的可视化展示。
• 分布式追踪：对分布式系统调用链路的跟踪能力。

2. 数据可视化效果：

• 可视化仪表盘定制能力：包括图表类型、自定义布局、颜色编码等。
• 数据实时更新速度：界面刷新率和数据同步延迟。

3. 洞察力与分析深度：

• 异常检测算法的有效性：能否准确识别出潜在问题。
• 智能诊断建议：提供基于AI/ML的故障预测与解决方案推荐。

4. 可扩展性和兼容性：

• 对不同架构（如云原生、混合云环境）的支持。
• 与第三方系统的兼容对接（如 Prometheus、OpenTelemetry 等标准协议）。

通过以上评测项的量化评估，可以全面了解运维产品的功能准确性、告警及时性和观测有效性的表现。同时，评测过程中需结合具体场景和用户需求，确保评测结果具有针对性和实用性。

系统运维联盟的工具测评

由于业务系统涉及到千行百业，市面上混沌工程种类繁多，运维工具参差不齐，运维技术始终处在跟随国外的角色，行业发展受阻等现象。运维生态也呈现出没问题时没人重视，出问题时运维人员背锅的现象，对故障没有敬畏之心，对运维工具的作用没有足够的认识。

随着 AI 和云原生技术的发展，系统越来越复杂，调用层级越来越多，国内外对可观测和 AIOps 运维方向的探索源源不断，涌现出了很多优秀的工具，但也有不少工具存在低质、重复、难用、兼容性差等特点。为了让运维行业呈现百花齐放、让优秀的工具脱颖而出，​​龙蜥社区成立了系统运维联盟​​，其中一项重要的工作就是通过对特定的业务系统进行故障注入，将不同的运维工具放在一起进行评估和评测，通过打分和排行榜的机制，来一次同场竞技，是驴是马都拉出来溜溜！

SOMA（System Operation & Maintenance Alliance）龙蜥社区系统运维联盟（https://soma.openanolis.cn/）是由龙蜥社区联合平台厂商、运维厂商、高校及科研院所、事业单位和广大行业用户等，按照平等、自愿的原则，发起并成立的，以推动系统运维技术进步、促进产学研合作为目的的组织。运维联盟通过建立一套故障注入平台和运维产品力评测系统，为平台厂商、运维厂商和广大客户建立起沟通的桥梁和纽带，让用户对运维产品拼图有全局认识。

运维联盟所做的运维工具评测，主要包含四个系统：案例注入、被测系统、评测系统、报告和评分系统。通过注入不同类型的案例到被测系统（被测系统采用标准的微服务系统），借助标准化接口把故障预期给评测系统，评测系统到测试点（如运维工具透出的标准接口，或者第三方的标准观测系统）采集现场指标与预期指标进行范围匹配，评测完成后，生成对应产品的评测分数及测试报告。后面将会对这些评分结果进行排行，发布产业报告，进行一些商业化动作。

具体流程：

1. 输入故障案例和混沌管控工程

包括客户案例、厂商案例、评测案例。前两种案例主要是方便客户和厂家随时进行案例注入及故障行为的模拟，方便客户对故障的表现形式及运维工具的能力进行全方位认识和评判。评测案例主要是对运维工具资质的审核、排名、评分而进行的，具有标准化、公信力。

2. 评测系统采集指标

评测时，在业务系统选择标准上有一定考虑：可持续维护、微服务应用、调测接口丰富。由复旦大学彭鑫教授团队开发的Train-ticket微服务应用当前（也可以基于online boutique）被作为业务基准。评测系统的基准指标来自于故障注入系统，还必须从运维工具输出的接口采集到业务系统指标。而目前大部分运维工具是不存在这些接口的或者接口不完善，需要去制定一些标准规范下来。

3. 指标比对和范围匹配

评测系统需要从注入系统拿到预期的输出指标，作为基准与运维工具本身得到的指标进行比对。根据指标类别制定一套标准，然后确定指标偏差范围对工具进行打分。

4. 打分，输出工具等级分布，生成单项测试报告

5. 根据评分发布排行榜，年度运维产业报告

从故障演练到评测的操作流程和数据接口图：

通过以上分析，一套评测系统，关键的问题是制定一套评测项和标准，确定哪些指标能进行自动化的评测，它的指标范围需要在特定场景下规范下来，最好由故障注入时，就能确定其预期范围，比如 CPU 的使用率，内存的使用量，或者系统延时都要有确定性预期。

运维联盟所做的最具挑战性的工作，就是去定义这套标准，根据标准实现自动化评测能力。我们也希望越来越多对此有兴趣的个人和企业，一起贡献到这里面来。

目前，基于 Chaos Mesh 的故障注入系统（由联盟成员云观秋毫团队开发）已经在龙蜥社区开源（https://gitee.com/anolis/soma/tree/master/chaos），当前提供了网络、存储、K8s 类的故障案例，希望大家一起来贡献案例。可以通过龙蜥社区主页进入运维联盟网页体验：​​https://soma.openanolis.cn/​​

我们把联盟成员里面的运维平台，针对不同的评测类型，形成了下面的评测知识图谱：

系统运维联盟的评测方向

由上面的评测知识图谱可以看到，我们把运维联盟进行评测的相关领域进行了划分：

• OS 系统运维
• 云原生可观测
• AIOps智能运维
• 服务器运维
• 传统运维

每一个领域，都有自己的评测项和评测内容以及评测方法，有些是共用和交叉的。但无论怎样，做好一个评测，包含以下重点内容：

• 定义出来前置条件，什么场景下评测。
• 评测标准、评测项定义。如指标类型和接口定义，指标范围定义。
• 案例注入设计。预计的观测指标范围，制定接口对接到评测系统。
• 看结果，评分和评级。评测系统和被测工具资源占用情况，制定打分规则和工具等级。

由于业务系统繁多，运维工具也是各有侧重点，系统运维联盟会在这两类比较热门的工具进行研究，一个是可观测方向，另外一个是 AIOps 方向。

可观测方向，我们拿具体的一个功能点进行评测：通过聚合指标的方式反馈某个节点的健康状态（健康、亚健康、不健康等），这些分项指标包括饱和度、系统错误、系统延时、网络流量，下面是相关评测项：

• 饱和度：持续监控，在问题发生之前，动态调整内核参数，以及资源泄露分析。
• 错误：系统错误事件/日志，对业务的影响，识别潜在风险。
• 延时：系统延时对应用的影响。
• 流量：监控引起流量突发的进程和应用。

另外，当运维工具上去后，如何评判它对原系统的影响，也就是系统资源受损情况。我们首先拿第三方的标定工具作为可信源头，比如 Prometheus 的采集工具，通过对比标定工具的指标和被测工具输出的指标，来对被工具进行打分和评定。目前次评测项正在由联盟成员云杉网络团队开发，不久会在 ​​https://gitee.com/anolis/soma​​ 开源。

相关的评测项：

• 基础资源：CPU、内存、流量、fd 资源、IO 资源、磁盘空间。
• 应用资源：连接池、线程池、中间件，调用 lib 库、其他库。
• 日志和存储资源：日志量，指标数据量，其他数据量。

最终，我们评测出来工具的等级，将会包含以下几个方面：

各个评测项不同，评分和工具等级对应可能不一致，后续将会陆续介绍这方面的研究成果。

AlOps工具评测

在对 AIOps 工具进行评测时，需要针对具体的问题进行根因分析，利用混沌工程模拟多种故障场景，测试 AIOps 解决方案有效性和鲁棒性。通过采集指标、搜集日志、链路追踪 Trace，提供一套标准化的评估指标和数据集，为用户选择合适的 AIOps 工具提供了参考。为运维应用开发人员和科研人员提供真实的数据和场景，用于学术研究、产品测试和评测打榜。

龙蜥社区系统运维联盟通过和清华大学裴丹教授发起的 OpenAIOps社区（https://www.aiops.cn/）合作，共同建立起 AIOps 领域的评测能力。

评测和排行榜的魅力？

系统运维联盟，今年最重要的工作就是建立一套评测的最小价值系统，即建立从故障注入到评测评估的体系，对运维工具进行打分到发布评测报告和制定运维排行榜。信通院也会参与到评测项和评测标准的制定、以及评测报告的发布工作上来。通过接入联盟成员的运维产品进行公开评测评分，并通过类 Gartner 的年度产业报告进行重点推荐，show 肌肉，增加其曝光度，实现商业的回报。

只要这个最小价值系统打通，那么其他运维产品就愿意进来评测，为了让其评分更高，就会更有意愿丰富故障注入的评测案例，同时发挥各自领域优势制定各个运维方向的标准和评测项，实现良好的循环，这就是评测和排行榜驱动的运维工具能力提升的魅力所在。

• 增加运维企业曝光度，增加宣传力度，拓宽宣传渠道。
• 引入运维工具平台到阿里云市场进行重点推荐。
• 促进运维厂商和云客户的商业合作。
• 发布产业报告，建设类 Gartner 影响力，提升运维技术水平。

​

参考：

1. 云原生背景下故障演练体系建设的思考与实践—云原生混沌工程系列之指南篇：

​​https://developer.aliyun.com/article/851555?utm_content=m_1000318166 ​​ 

2. 全链路压测：影子库与影子表之争：

​​https://developer.aliyun.com/article/982802  ​​