混沌工程实践：谷歌灾难恢复测试，治混沌系统于未病

谷歌SRE团队的座右铭体现了混沌工程的核心理念：希望没问题，这不是策略。

当共享基础设施和存储系统出现故障时，工程师可以立即使用预先构建的自动化测试来验证共享系统的行为。自动化测试可以连续运行以防止可靠性下降。并在极端情况下验证SLO，自动化测试比传统测试的数量要高一个数量级。将可靠性做到极致意味着要挑战有关系统可靠性的假说，面对罕见的故障组合，要对其熟悉并为应对做准备。你必须预期事情会失败，在考虑到失败的情况下对系统进行设计，并不断证明这些设计仍然有效。

灾难测试计划以测试计划文档开始，谷歌使用一个标准的文档模板。该模板列出了评估给定测试的风险和潜在收益所需的最重要的信息，并随着时间的推移不断完盖，该文档包括特定的执行过程，回退过程，众所周知的风险，潜在影响，依赖性以及测试的目的。测试计划文档和结果文档均为半结构花格式，能够推输在断式进行解析。既往的测试存储库经常用于设计新测试，或者在工程师有兴趣了解其团队过去执行过的测试时使用。

灾难恢复测试不能破坏外部系统或用户的SLO。尽可能地选择受控混沌。测试应有经过深思熟虑，且具有可快速执行的回滚策略。有安全网或大红按钮将使你能在适当时候停止测试。

生产紧急情况始终优先于灾难恢复测试紧急情况。如果在演练时发生了实际的生产事故，则应停止或推迟演练，以将重心转移到应对实际事故上。

透明地运行灾难恢复测试。尽可能清楚地表明灾难恢复测试中的紧急情况是演练的一部分。如果值班工程师不知道两个紧急情况中哪个是测试，就无法有效降低测试紧急情况的优先级，来应对真实的紧急情况。有关灾难测试的沟通也是测试的一部分。尽可能清楚地表达出来。要尽早经常和明确地就测试进行沟通。

最小化成本，最大化价值。在设计测试时，要在内部用户服务中断和商誉损失的成本和你所学的内容之间进行权衡。测试不是为了搞破坏，它的价值来源于发现未知的故障模式。如果已知系统已损坏，则优先进行工程工作以解决已知的风险。要彻底考虑测试的影响，在计划和实际测试过程中不断重新评估测试所造成的影响。

像对待实际停机事故一样对待灾难测试。如果收到测试的影响，那么请按正常流程升级汇报并处理。事故升级过程是用于收集有关测试影响信息的重要管道，并且揭示系统之间的意外连接。如果忽略一个问题，将错过这些有价值的信息。

从一些提示性问题(WHAT IF)开始，帮你指出正确的方向。哪些系统让你彻夜难眠?是否存在独一份的数据或服务?是否存在依赖于位于单个地点或单个供应商中的人员的流程?是否100%确信监控和告警系统会预期发出警报?上次切换到后备应急系统是什么时候?上次从备份还原系统是什么时候?当系统的非关键依赖项不可用时，是否验证了系统的行为?

灾难测试是科学化的，要像进行科学实验一样进行灾难测试。应尽可能控制系统中的无关变量。尽可能做到一次只测试一个假说。警惕在一个测试中将自动化的系统反应和人员的反应混杂起来。

完成了规划并顺利执行测试之后，要记录好所发现的内容。工程师在每一次测试中编写一份轻量级的文档。

混沌工程的拥护者不拒绝混沌，而是接受混沌，为意外情况做最好的准备。灾难测试提供了一种方法以验证猜想，证明系统的行为，使人们对系统的理解更加深入，并最终让系统更加稳定。定期、正规化和精心设计的灾难测试将使你能够以受控的方式探测系统优化灾难的假设。