软件质量保障：故障演练介绍

目录

背景：架构变化带来的问题

什么是故障演练

为什么需要故障演练

故障演练场景有哪些

不同演练类型和目标

如何对工具进行评估

功能评测项

告警评测项

观测指标评测项

总结

---

背景：架构变化带来的问题

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

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

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

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

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

什么是故障演练

对于很多大型企业来说，经过多年的技术演进，系统工具和架构已经高度垂直化，服务器规模也达到了比较大的体量。当服务规模大于一定量（如10000台）时，小概率的硬件故障每天都会发生。这时如果需要人的干预，系统就无法可靠的伸缩。

为此每一层的系统都会面向失败做设计，对下游组件零信任，确保在故障发生时可以快速的发现和处理。但这些措施在故障发生时的有效性、故障恢复工具的真实容灾能力、处理问题人员的熟练度，沟通机制、容灾措施对上层的影响等问题，平时并没有太多的机会验证，往往都是在真实故障中暴露。

故障演练就是这个背景下诞生的，沉淀通用的故障场景，以可控成本在线上故障重放，以持续性的演练和回归方式的运营来暴露问题，不断验证和推动系统、工具、流程、人员能力的提升，从而提前发现并修复可避免的重大问题，或通过验证故障发现手段、故障修复能力来达到缩短故障修复时长的作用。

故障演练验证，是指基于混沌工程的故障演练实现对业务系统的验证。演练可以分为有损演练和无损演练，一般通过低频的有损演练发现业务架构问题、验证业务容灾能力，通过高频的无损演练实现对业务的监控发现/报警响应、组织应急等能力进行验证。

为什么需要故障演练

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

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

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

• 事前：及时发现风险，做好架构、预案、演练。

• 事中：及时发现故障，及时定位，及时止损。

• 事后：排查根因，落实复盘改进项。

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

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

故障演练场景有哪些

故障演练场景有很多，从单个系统应用的维度、集群组件视角维度去构造案例，以检验我们业务系统的稳定性，更重要的是提前发现问题的能力，这对运维工具提出越来越高的要求，挑战也越来越大。从垂直技术架构层次，设计演练场景：（下面2个图思路类似）

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

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

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

不同演练类型和目标

根据演练过程对线上业务的影响，演练可分为有损演练和无损演练。由于对业务的影响不同，两种演练可以进行的演练频次、可实现的业务验证目标都有不同。

有损演练是指直接在线上真实业务环境注入异常进行演练，演练模拟的真实有效性高，为了平衡业务影响一般会选择最核心场景、在业务最低峰期做演练，而且演练频次相对较小，例如为了验证多活容灾能力的机房断网演练，一般是一个月一次的演练频次；无损演练是指在一套无线上真实业务流量的隔离环境做演练，配合压测模拟流量注入异常进行演练，由于业务无损，可以支持较高频次的演练，比如为了类比/形变复现线上类似故障、验收故障复盘的改进action、演练监控感知能力/报警响应能力等，可以组织对不同业务团队轮流参与的每周1次的高频演练。

演练类型	演练方案优缺点	演练环境	演练频次	主要演练目标
有损演练	优点：真实有效性高 缺点：线上业务有损	线上真实业务环境	1-2月一次	容灾多活机房断网验证演练 重要架构/业务问题模拟验证 全链路生产突袭模拟演练
无损演练	优点：线上业务无损 缺点：逼真度有限	全链路灰度环境/新建业务环境	每周1-2次	监控感知能/报警应急响应 类似故障复现/改进action验收 应急组织流程、止损预案验证

如何对工具进行评估

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

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

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

• 资源占用少。运维工具本身占用 CPU、内存等资源要小，不能占用比我业务系统还大的资源，本末倒置！

• 对原业务系统无影响。上工具前，先问一句工具是否可靠，不能把我的系统搞挂。否则，我业务都没了，还要你的工具做什么。

• 响应及时性，告警有效性。有问题先告警，别乱报啊！

• 分析准确性，功能一致性。监控和 profiling 功能要稳，根因分析要准确，一致！

• 数据成本低。日志、指标、追踪数据要精简，能定位问题，但指标不宜过多。多了我可买不起，不瞎折腾！

• 易用性好，易部署、易升级。操作简便，别整高大上的花里胡哨但解决不了问题的东西！

• 架构可移植性好，不同平台、不同版本兼容。考虑 X86、Arm 及 eBPF 在不同内核版本的兼容性等。

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

功能评测项

1. 基础功能完备性：

• 系统监控：对 CPU、内存、磁盘、网络流量等基础资源的实时监控能力。

• 应用层监控：API 接口调用监测、数据库性能监控、容器/微服务状态监控等。

• 自定义指标支持：是否允许用户自定义监控指标和阈值。

2. 告警配置灵活性：

• 多条件组合告警规则设置：支持多维度数据聚合与逻辑运算进行告警触发判断。

• 告警策略管理：如重复告警抑制、告警升级机制、告警合并等功能。

3. 故障定位精准度：

• 根因分析：提供故障根因分析工具或功能，能快速定位问题源头。

• 故障排查路径追踪：记录并展示故障发生时的事件链路，辅助排查过程。

告警评测项

1. 告警延迟检测：

• 实时告警触发时间与实际故障发生时间之间的差距。

• 平均告警延迟时间统计。

2. 告警通道覆盖范围：

• 支持的告警通知方式（短信、电话、邮件、企业微信、钉钉等）。

• 第三方集成：与其他告警渠道和服务集成的能力。

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

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

4. 告警通知频率控制：

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

观测指标评测项

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

• 日志观测：日志收集、解析、搜索及关联分析能力。

• 时序数据观测：对各种时序数据（如系统性能指标、业务关键指标）的可视化展示。

• 分布式追踪：对分布式系统调用链路的跟踪能力。

2. 数据可视化效果：

• 可视化仪表盘定制能力：包括图表类型、自定义布局、颜色编码等。

• 数据实时更新速度：界面刷新率和数据同步延迟。

3. 洞察力与分析深度：

• 异常检测算法的有效性：能否准确识别出潜在问题。

• 智能诊断建议：提供基于 AI/ML 的故障预测与解决方案推荐。

4. 可扩展性和兼容性：

• 对不同架构（如云原生、混合云环境）的支持。

• 与第三方系统的兼容对接（如 Prometheus、OpenTelemetry 等标准协议）。

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

总结

稍具规模的故障演练，往往需要各个团队角色协作完成，会面临一个ROI的问题，实施时需要从上到下推动，做好充足的准备。