谷歌：二十年站点可靠性工程的经验教训

我们作为 Google 站点可靠性工程师学到的 11 件事：

1、缓解措施的风险应随着中断的严重程度而变化
我们惨痛地认识到，在事件发生期间，我们应该监控和评估情况的严重性，并选择风险适合该严重程度的缓解路径。在最好的情况下，风险缓解措施可以解决中断问题。在最坏的情况下，风险缓解措施会失败，并且本应修复的措施会导致停电时间延长。此外，如果一切都被破坏，您可以做出明智的决定来绕过标准程序。

2、在紧急情况发生之前应充分测试恢复机制
在高层城市建筑中进行紧急火灾疏散是第一次使用梯子的绝佳机会。同样，停电也是第一次尝试危险的减载过程的绝佳机会。为了在高风险和高压力的情况下保持冷静，重要的是事先练习恢复机制和缓解措施并验证：

• 他们会做你需要他们做的事

• 你知道怎么做

测试恢复机制有一个有趣的副作用，即降低执行其中一些操作的风险。自从这次混乱的停电以来，我们加倍了测试力度。

3、用金丝雀监控所有变化
有一次，我们想要推动缓存配置更改。我们非常确定这不会导致任何不好的事情。但相当确定并不是100%确定。事实证明，缓存对于 YouTube 来说是一个非常关键的功能，配置更改产生了一些意想不到的后果，导致该服务完全瘫痪了 13 分钟。

如果我们通过渐进的推出策略来应对这些全球变化，那么这种中断可能会在其产生全球影响之前得到遏制。

4、有一个“大红色按钮”
确保每个服务依赖项都有一个“红色大按钮”，可以在紧急情况下使用。

“大红色按钮”是一种独特但非常实用的安全功能：它应该启动一个简单、易于触发的操作，将触发不良状态的任何情况恢复到（理想情况下）关闭正在发生的任何情况。

“大红色按钮”有多种形状和大小，在提交潜在危险操作之前，确定这些大红色按钮可能是什么非常重要。我们曾经险些错过一次重大停机，因为提交可能触发更改的工程师在更改传播之前拔掉了台式计算机的电源插头。

因此，在规划主要部署时，请考虑我的红色大按钮是什么？

5、仅单元测试是不够的 - 还需要集成测试
单元测试有意限制了范围，并且非常有帮助，但它们也没有完全复制可能存在的运行时环境和生产需求。

使用集成测试来验证：

• 作业和任务是否可以执行冷启动：
• 事情会按照我们希望的方式进行吗？
• 组件也会按照我们想要的方式协同工作吗？
• 这些组件能否成功创建我们想要的系统？

2017 年 2 月发生的一起事件，我们找到了接下来的两个教训：
首先，不可用的 OAuth 令牌导致数百万用户退出设备和服务，并导致 32,000 个 OnHub 和 Google WiFi 设备执行出厂重置。由于登录失败，手动帐户恢复索赔猛增了 10 倍。Google 花了大约 12 个小时才从中断中完全恢复。

6、沟通渠道！和备份通道！以及这些备份通道的备份！！！
那是一段糟糕的时光。你想知道是什么让事情变得更糟吗？团队希望能够使用 Google Hangouts 和 Google Meet 来管理该事件。但当 3.5 亿用户退出他们的设备和服务时……回想起来，依赖这些 Google 服务是一个糟糕的决定。确保您拥有独立的备份通信通道，并且已经对其进行了测试。

7、优雅降级：故意降低性能模式
人们很容易将可用性视为“完全启动”或“完全关闭”……但能够通过降级性能模式提供连续的最低功能有助于提供更一致的用户体验。因此，我们精心且有意地构建了性能下降模式，因此在粗糙补丁期间，它甚至可能是用户不可见的（它可能现在正在发生！）。服务应正常降级并在特殊情况下继续运行。

8、抗灾能力测试
除了单元测试和集成测试之外，还有其他类型的非常重要的测试：灾难恢复和恢复测试。

• 弹性测试验证您的服务或系统在发生故障、延迟或中断时能否正常运行，

• 而恢复测试则验证您的服务在完全关闭后是否可以恢复到稳态。

两者都应该是业务连续性策略的关键部分。

9、自动化您的缓解措施
2023 年 3 月，几个数据中心的多个网络设备几乎同时发生故障，导致大范围的数据包丢失。在这 6 天的中断中，估计 70% 的服务受到了不同程度的影响，具体取决于网络故障时的位置、服务负载和配置。

在这种情况下，您可以通过自动执行手动执行的缓解措施来缩短平均解决时间 (MTTR)。

如果有明确的信号表明正在发生特定故障，那么为什么不能以自动方式启动缓解措施呢？有时，最好先使用自动缓解措施，并在避免用户影响后保存根本原因。

10、减少推出之间的时间，以降低推出出错的可能性
2022 年 3 月，支付系统大范围中断，导致客户无法完成交易，导致 Pokémon GO 社区日被推迟。原因是删除了单个数据库字段，这应该是安全的，因为该字段的所有使用都已预先从代码中删除。不幸的是，系统一部分的推出节奏缓慢意味着该字段仍在被实时系统使用。

部署之间存在较长的延迟，尤其是在复杂的多组件系统中，使得推断特定变更的安全性变得极其困难。频繁的推出——通过适当的测试——可以减少此类故障的意外发生。

11、单一全球硬件版本是单点故障
仅使用一种特定型号的设备来执行关键功能可以使操作和维护更加简单。然而，这意味着如果该模型出现问题，则该关键功能将不再执行。

这种情况发生在 2020 年 3 月，当时一台存在未发现的零日漏洞的网络设备遇到了触发该漏洞的流量模式变化。由于整个网络使用相同型号和版本的设备，因此出现了严重的区域中断。防止这种情况完全中断的是多个网络主干的存在，这些主干允许高优先级流量通过仍在工作的替代方案进行路由。

关键基础设施中的潜在错误可能潜伏不被发现，直到看似无害的事件触发它们。维护多样化的基础设施虽然本身会产生成本，但可能意味着麻烦的停机和完全停机之间的区别。

https://www.jdon.com/69453.html