启动混沌工程之前的基准指标

混沌实验旨在通过主动注入故障来提升系统韧性，但在启动之前，需要收集全面的指标作为基准，以科学评估实验效果，并设定合理的优化目标。这些指标涵盖应用程序、故障事件、告警信息以及基础设施等方面。

应用程序指标包括面包屑导航（记录用户操作路径，如浏览到下单）、上下文信息（捕捉请求环境，如浏览器类型）、堆栈跟踪（用于定位代码错误根因，如微服务调用失败）和事件数据（量化业务影响，如订单提交失败率），为故障分析提供行为追踪依据。

高严重性事件（SEV）指标聚焦系统可靠性，主要包括 MTBF（平均故障间隔时间，如支付服务的稳定性）、MTTR（平均恢复时间，如数据库宕机后的修复时长）、MTTD（平均检测时间，如发现网络延迟所需的时间），以及每周 SEV 总数和分级事件数量，用于识别高风险服务。

告警与值班指标用于优化应急响应能力，常见包括每周 Top 20 告警（揭示高频问题，如请求超时）、噪声告警（可自动恢复的问题，如网络抖动）、告警解决时间（衡量处理效率，如修复死锁的耗时）以及每周告警总数（帮助发现问题集中区域）。

基础设施指标关注系统底层健康状况，涵盖网络（如数据包丢失、延迟、DNS 异常）、状态（如时钟同步情况、关键进程是否存活）和资源使用（如内存、磁盘、I/O、CPU），确保系统运行稳定。

在完成这些指标的收集后，团队可以评估混沌实验的实际效果，例如在模拟 CPU 峰值负载后，MTTR 是否有所缩短。同时还可以回答几个关键问题：CPU 峰值是否影响上下游服务？造成峰值的三大原因是什么？事故是否有减少？哪些服务拥有最多高事件和高告警？这些指标就像系统的体检报告，确保混沌实验既精准又有效，帮助系统在复杂环境中稳健运行。

混沌工程实验序列

设设想一个共享的 MySQL 数据库架构，包含 100 台主机，每台主机承载多个数据分片。区域 A 部署有一个主数据库节点和两个副本，区域 B 部署一个伪主节点和两个伪副本。在这样的分布式系统中，我们按阶段执行混沌实验，逐步揭示系统的韧性与潜在问题。

已知领域

此阶段实验聚焦在系统已知且可控的部分，旨在验证基本操作流程的可靠性。初始步骤是将区域 A 的副本数量从两个增加到三个，具体做法是从主节点克隆一个新副本，并将其加入到集群中。

实验过程中，若某个副本被关闭，系统会自动将其从集群中移除。为了测试整个恢复流程，我们故意关闭一个副本，并依次测量以下各阶段的耗时：检测副本关闭、移除节点、启动克隆、克隆完成以及新副本加入集群。整个实验需保持稳定的节奏，确保任意时刻副本数量不为零，避免影响系统基本可用性。

实验结束后，需生成详细报告，记录副本关闭后的平均恢复时间，并按照天和小时进行分解，分析不同时间段（如业务高峰时段）下系统的表现，进一步指导容量规划和告警优化。

已知 - 未知

这一阶段聚焦的是我们部分了解、但尚未完全掌握的场景。比如我们已知副本克隆操作会发生，日志中也会记录克隆成功或失败，但我们并不清楚每周克隆操作的平均耗时。

实验基于上一阶段的结果进一步展开。例如，当集群中只剩一个副本时，系统会在五分钟内触发告警，但我们并不确定这个五分钟的阈值是否合理。通过汇总并分析故障发生到新副本成功加入的平均耗时，我们可以评估当前的告警机制是否足以预防高严重性事件（SEV），并据此优化告警策略，提高系统的响应效率和可靠性。

未知 - 已知

此阶段关注的是那些我们虽已理解机制，但尚未真正意识到其潜在风险的场景。例如我们知道事务可以通过区域 B 的伪主节点和两个伪副本完成，但尚不清楚在高压场景下，例如周一早高峰同时关闭两个副本后，系统克隆新副本的及时性有多重要。

实验方案是在周一早上将副本数量从默认的两个提升至四个，然后故意关闭其中两个，测量新副本克隆完成所需的时间。若主节点在高负载状态下无法高效完成克隆操作，可能暴露资源竞争、备份冲突等问题。这类实验有助于我们意识到，在关键时间点副本资源调度策略的优化空间，为后续系统扩展和容灾设计提供数据支持。

未知的未知

最终阶段面向完全未知的领域，旨在测试系统在极端故障场景下的表现。例如关闭区域 A 的整个集群，包括主节点和所有副本，观察系统是否能正确识别故障，并切换到区域 B 的伪主架构继续提供服务。

这类突发性停机事件往往是现实中最具破坏性的场景。实验前需制定明确的工程方案，确保有完整的切换机制、数据一致性保障和快速回滚能力。实验完成后，根据系统表现进一步优化切换逻辑，提升区域 B 的容灾能力。

重复执行优化后的实验，确保系统在面对此类黑天鹅事件时，依然能保持稳定运行，为未来不可预测的挑战构筑坚实的防线。

混沌工程的最佳实践

混沌实验以三大支柱为指导，确保实验高效、可控且富有洞察力，从而为分布式系统的韧性保驾护航。下面分别从覆盖范围、生产环境实验和爆炸半径控制三个方面，阐述其核心实施原则。

提供足够的覆盖范围

软件测试很难做到百分之百覆盖，全面测试不仅耗时，而且难以覆盖所有可能的场景。因此，为了提升测试效率，混沌实验应聚焦于对系统影响最大的关键场景，比如网络故障、网络拥塞或存储服务不可用等。举例来说，模拟数据库不可用的场景可以暴露备份切换时的延迟问题，从而提前发现潜在风险。实验应定期运行，融入 CI/CD 流水线，随着代码或配置的变更自动触发执行。由于基础设施、系统和软件状态变化频繁，流水线中的持续实验能够及时捕捉修改带来的隐患，逐步建立对系统稳定性的信任。比如某电商平台在上线新功能时，模拟流量峰值环境，及时发现缓存失效，提前优化避免了生产事故。

在生产环境中进行实验

生产环境承载着真实用户的活动，流量和负载的峰值反映了系统的实际压力。在生产环境开展混沌实验，能够更全面地检验系统的韧性并揭示隐藏的问题。举例来说，某视频平台曾在生产环境模拟 CDN 故障，发现备用线路切换耗时过长，优化后显著提升了用户体验。虽然生产实验能提供最真实的反馈，但设计时必须格外谨慎，确保实验不会影响正常服务，保证用户体验不受干扰。

最小化爆炸半径

混沌实验虽然追求发现系统弱点，但绝不能以牺牲生产稳定性为代价。为此，应通过控制实验范围，将 “爆炸半径” 降到最低，降低风险。比如测试两个微服务间的网络延迟，而不是直接关闭整个服务集群。小规模实验不仅风险更低，也便于快速定位问题根源，比如及时发现配置超时不合理。混沌工程团队应遵循严格的方法论，覆盖四类场景：完全未知、不完全理解、理解但未完全掌握、完全掌握的情况。通过分层测试，确保实验既全面又可控，助力系统在复杂环境下稳健运行。

结论

在现代软件开发生命周期中，混沌实验如同一剂催化剂，显著提升系统的速度、灵活性和弹性，保障分布式系统的平稳运行。通过主动注入故障，混沌实验能够提前暴露潜在问题，让团队在问题影响用户之前及时修复。

例如，某金融平台通过模拟支付服务故障，发现并优化了事务重试机制，成功避免了交易中断带来的风险。随着越来越多的组织意识到混沌实验的重要性，它不仅增强了系统的韧性，也为持续交付提供了坚实保障。

展望未来，科学而系统地实施混沌实验，将帮助企业更自信地应对复杂挑战，把不确定性转化为发展机遇，实现系统更加稳定、高效的运行，推动数字化转型迈向卓越。

FunTester 原创精华

从 Java 开始性能测试

故障测试与 Web 前端

服务端功能测试

性能测试专题

Java、Groovy、Go

测试开发、自动化、白盒

测试理论、FunTester 风采

视频专题