SRE 从谷歌 20 年的站点可靠性工程中学到的 11 个经验教训 _谷歌

作者 | Adrienne Walcer, Kavita Guliani, Mikel Ward, Sunny Hsiao, and VrAI Stacey
译者 | 刘雅梦
策划 | Tina
让我们回到 2016 年，当时 YouTube 提供了大家最喜欢的视频，例如“Carpool Karaoke with Adele”和一直很吸引人的“Pen-PineApple-Apple-Pen” 。由于 YouTube 的分布式内存缓存系统的一个 bug，YouTube 经历了长达 15 分钟的全球宕机故障，中断了 YouTube 的视频提供能力。以下是我们从这次故障中学到的三个经验教训。
1. 故障削减措施的风险应与故障的严重程度成比例
有一个表情包，其中一个人发布了一张在他们家里看到蜘蛛的照片，家长说：“是时候搬新家了!” 。可笑的是，这一事件（看到一只可怕的蜘蛛）会得到严厉的削减措施（放弃你现在的家，搬到新家中）。我们 SRE 在选择比宕机风险更大的削减措施方面有一些有趣的经验。在上述 YouTube 宕机期间，一个有风险的减载过程并没有解决宕机问题……反而造成了级联故障。
我们得到了惨痛的教训，在故障发生期间，我们应该监控和评估情况的严重性，并选择一条风险适合该严重程度的故障削减路径。在最好的情况下，风险削减措施可以解决宕机问题。在最坏的情况下，风险削减措施会失灵，并且本应修复问题的措施会导致宕机时间的延长。此外，如果一切都坏了，我们可以做出明智的决定来绕过标准程序。
2. 在发生紧急情况之前，应对恢复机制进行全面测试
在高层城市建筑中进行紧急消防疏散是首次使用梯子的可怕时机。同样，在故障中首次尝试风险减载过程也是一个糟糕的时机。为了在高风险和高压力的情况下保持冷静，事先演练恢复机制和故障削减措施很重要，并需要验证：

它们会做你需要它们做的事
你知道怎么做

演练恢复机制有一个有趣的副作用，即可以降低执行其中一些操作的风险。自从这次混乱的宕机以来，我们加倍努力地进行演练。
3. 金丝雀所有变更
有一次，我们想要推送缓存配置变更。我们很肯定那不会导致任何坏事。但相当肯定并不是百分之百确定。事实证明，缓存对于 YouTube 来说是一个非常关键的功能，而配置变更产生了一些意想不到的后果，导致该服务完全瘫痪了 13 分钟。如果我们采用渐进式的发布策略来应对这些全球变更，那么这次故障本可以在产生全球影响之前得到遏制。可以阅读这篇论文中了解有关金丝雀策略的更多信息，也可以通过本视频以了解更多信息。
大约在同一时间段，比 YouTube 稍微年轻的兄弟公司谷歌日历（google Calendar）也经历了宕机故障，这也是接下来两个经验教训的背景。
4. 有一个“大红色按钮”
“大红色按钮”（Big Red Button）是一种独特但高度实用的安全功能：它应该启动一个简单、易于触发的动作，该动作将触发不良状态恢复到（理想情况下）关闭正在发生的任何情况。“大红色按钮”有多种形状和大?。?谔峤灰桓鲇星痹诜缦盏牟僮髦?埃?识别这些大红色按钮可能是什么非常重要的。我们曾经差点就能避免一次重大的宕机故障，因为提交可能触发变更的工程师在更改传播之前拔掉了台式电脑的电源插头。因此，在计划重大部署时，请考虑大红色按钮是什么？确保每个服务依赖项都有一个“大红色按钮”，以便在紧急情况下使用。请参阅“通用削减措施”以了解更多信息！
5. 仅仅进行单元测试是不够的，还需要进行集成测试
啊……单元测试。它们验证单个组件是否可以按照我们需要的方式执行。单元测试的范围是有意限制的，而且非常有用，但它们也不能完全复制可能存在的运行时环境和生产需求。因此，我们大力提倡集成测试！我们可以使用集成测试来验证作业和任务是否可以执行冷启动。事情会按照我们希望的方式进行吗？组件也会按照我们想要的方式协同工作吗？这些组件会成功创建我们想要的系统吗？这一教训是在谷歌日历（Calendar）的故障处理中学到的，在这次故障中，我们的测试没有遵循与实际使用相同的路径，导致了大量的测试...... 但这并不能帮助我们评估变更在现实中的执行情况。
转到 2017 年 2 月发生的一个故障，我们学到了接下来的两个经验教训。
首先，不可用的 OAuth 令牌导致数百万用户退出设备和服务，并导致 32000 个 OnHub 和 Google wifi 设备执行出厂重置。由于登录失败，手动帐户恢复索赔增加了 10 倍。谷歌花了大约 12 个小时才从这次故障中完全恢复过来。