混沌工程

第 5 章. 谷歌 DiRT：灾难恢复测试

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

杰森-卡洪

"希望不是战略"。这句 是谷歌网站可靠性工程（SRE）团队的座右铭，它完美地体现了 混沌工程的核心理念。一个系统的设计可以容忍故障，但在大规模明确测试故障条件之前，总是存在期望与现实不符的风险。谷歌的 DiRT（灾难恢复测试）项目是由网站可靠性工程师（SRE）于 2006 年创立的，目的是故意在关键技术系统和业务流程中制造故障，以暴露出无法估量的风险。倡导 DiRT 计划的工程师们提出了一个重要观点：当实际情况并不紧急时，分析生产中的紧急情况就会变得容易得多。

灾难测试 有助于证明系统在故障处理得当的情况下的恢复能力，并在处理不当的情况下以受控方式暴露可靠性风险。在受控事件中暴露可靠性风险，可以进行全面分析并预先减轻影响，而不是仅仅等待问题暴露，因为问题的严重性和时间压力会放大失误，迫使人们根据不完整的信息做出危险的决定。

DiRT 从 开始，由谷歌工程师进行角色扮演演练。¹类似于其他公司的 "游戏日 "活动。他们尤其关注灾难和自然灾害会如何扰乱谷歌的运营。尽管谷歌的员工分布在全球各地，但其在旧金山湾区的业务却不成比例地庞大，该地区尤其容易发生地震。谷歌将如此多的内部基础设施集中在一个地区，这就提出了一个耐人寻味的问题："如果山景城园区及其员工在几天内完全无法使用，现实中会发生什么？这会如何扰乱我们的系统和流程？

研究 在山景城托管的服务中断所造成的影响激发了谷歌最初的许多灾难测试，但随着熟悉度（或许是臭名昭著......）的增加，对提高可靠性感兴趣的团队开始利用全公司范围内的 DiRT 事件作为深入探究自身服务的机会。纯理论和桌面演练让位于服务所有者注入真实但可控的故障（增加延迟、禁用与 "非关键 "依赖关系的通信、在关键人员缺席的情况下演练业务连续性计划等）。随着时间的推移，参与的团队越来越多，实际测试也越来越多；随着测试范围的扩大，谷歌整体架构中需要学习和改进的地方也越来越多：不为人知的硬性依赖、回退策略失灵、保障措施完全失效、规划中大大小小的缺陷，这些缺陷在事后显而易见，但在事前却几乎看不到，或者只有在 "恰到好处"（或错误，取决于你如何看待它）的不幸条件组合下才会暴露出来。

该计划自推出之初就不断发展壮大，目前谷歌全球各地的团队已经开展了数千次 DiRT 演习。大型协调活动贯穿全年，团队定期主动测试系统和自身。SRE 团队必须在一定程度上参与 DiRT，公司也大力鼓励各处的服务所有者参与 DiRT。很大一部分参与不仅来自软件工程和 SRE 组织：物理安全、信息安全、数据中心运营、通信、设施、IT、人力资源和财务业务部门都设计并执行了 DiRT 测试。

近年来， ，重点是为网络和软件系统提供一套标准化的自动测试。工程师可以使用开箱即用的预构建自动测试，在共享基础设施和存储系统出现故障时验证系统行为。自动测试可持续运行，以防止可靠性倒退，并在极端或异常情况下验证服务水平目标。这些测试降低了入门门槛，为更复杂的特定架构故障测试提供了跳板。自动测试的执行次数已超过传统 DiRT 测试总数的数量级，在短短几年内就达到了几百万次测试运行，这充分体现了自动测试的威力。

谷歌属性以其大规模的高可靠性而闻名，但谷歌闻名的可靠性并不是魔术。提高可靠性意味着要挑战对系统的假设，熟悉并准备应对不常见的故障组合（在谷歌这样的规模中，百万分之一的故障几率每秒就会发生数次）。仅仅希望系统在极端情况下表现可靠并不是一个好的策略。你必须预料到事情会失败，在设计时考虑到失败，并不断证明这些设计仍然有效。 ...