前言
二十年内可能会发生很多事情，尤其是当你忙于开发时。
二十年前，谷歌有一对小数据中心，每个中心有几千台服务器，通过一对 24G网络链路环连接。 我们使用 python 脚本，例如"assigner"、"autoreplacer "跟"babysitter"运行我们的私有云（尽管我们当时没有这么称呼它），这些脚本在包含单个服务器名称的配置文件上运行。 我们有一个小型机器数据库 （MDB），可以帮助组织和存储来自各个服务器的信息。 我们的小型工程师团队使用脚本和配置文件来自动解决常见问题，并减少管理服务器群所需的体力劳动。
随着时间的流逝，谷歌的用户开始搜索，免费获得GB Gmail，我们的车队和网络也在增长。 今天，我们的计算能力是 20 年前的 1,000 多倍;在网络方面，我们的规模是 20 年前的 10,000 多倍，我们在每台服务器上花费的精力比以前少得多，而我们的服务堆栈更可靠。 我们的工具已经从一系列 python 脚本发展到一个集成的服务生态系统，再到一个默认提供可靠性的统一平台。 随着我们遇到新型故障，我们对分布式系统的问题和故障模式的理解也在不断发展。 我们创造了不幸之轮（"wheel of misfortune"[1]、服务最佳实践指南（"service best practices guides"[2]，出版了《谷歌》一书'最热门的歌曲“，今天，我们非常高兴地向大家介绍：
Benjamin Trainor Sloss，Google SRE 的创建者
从二十年的可靠性工程中吸取的经验教训
让我们从 2016 年开始，当时 YouTube 仍然可用"阿黛尔的拼车卡拉OK"而且总是令人着迷"pen-pineapple-apple-pen"等待你的最爱**。 由于 YouTube 的分布式内存缓存系统出现错误，YouTube 经历了 15 分钟的全球中断，导致 YouTube 服务功能中断**。 以下是我们从这次事件中吸取的教训。
1.缓解措施的风险应与中断的严重程度成正比
有一个笑话，说一个人在网上发了一张他家里蜘蛛的照片，船长说"是时候搬到新房子了！"。这个笑话的意思是，对于这个事件（看到一只可怕的蜘蛛），将采取严厉的缓解措施（放弃你现在的家，搬到一个新的家）。 我们在 SRE 方面也有一些有趣的经验，即选择一种比它试图解决的失败风险更大的缓解措施。 在前面提到的 YouTube 故障事件中，一个有风险的负载切割过程并没有解决故障。 ......相反，它导致了级联故障。
我们敏锐地意识到，在事件发生期间，我们应该监控和评估情况的严重性，并选择适合严重性的缓解路径。 在最好的情况下，有风险的缓解措施可以解决故障。 在最坏的情况下，故障缓解措施可能会失败，从而导致更长的中断时间。 此外，如果一切正常，您可以做出明智的决定，绕过标准程序。
2.在紧急情况发生之前，应全面测试恢复机制
在高层城市建筑中进行紧急消防疏散是首次使用梯子的绝佳机会。 同样，中断是首次尝试危险的负载下降过程的绝佳机会。 为了在高风险、高压力的情况下保持冷静，重要的是要事先练习习恢复机制和缓解措施，并验证以下内容：
他们为您提供保障。
你知道怎么做。
测试恢复机制的另一个有趣的方面是，它降低了执行其中一些操作的风险。 自从下面出现这个混乱的故障以来，我们已经加倍努力来测试它。
3.Canary 所有更改
有一次，我们想推动缓存配置更改。 我们非常确定这不会导致任何不良后果。 但"很确定"这不是100%确定的。 事实证明，缓存对 YouTube 来说是一个相当关键的功能，配置更改产生了一些意想不到的后果，使服务完全瘫痪了 13 分钟。 如果我们采用渐进式发布策略，Canaried These Global Changes[3]，这种失败本可以在它产生全球影响之前得到控制。 在此处阅读有关金丝雀策略的更多信息[4]，并在** [5]中了解更多信息。
大约在同一时间，YouTube 稍微年轻的兄弟姐妹 Google 日历也经历了崩溃，这是接下来两节课的背景。
4.有一个"大红色（紧急停止）按钮"(h**e a "big red button")
急停按钮"这是一个独特但非常有用的安全功能：它应该启动一个简单、易于触发的操作，该操作可以恢复触发错误状态的原因，以（理想情况下）关闭正在发生的一切。 "急停按钮"有多种形状和大小——在采取潜在危险行动之前，确定这些红色按钮可能是什么非常重要。 我们差点触发一个重大故障，但幸运的是，提交潜在触发更改的工程师在更改传播之前拔下了台式计算机的电源。 因此，在规划重大部署时，请考虑我的内容"红色按钮"？确保每个服务依赖项都有一个"红色按钮"在紧急情况下使用。 有关详细信息，请参阅："一般缓解措施"[6]！
5.仅靠单元测试是不够的，还需要集成测试
是的。。。。。。。单元测试。 它们验证各个组件是否按照我们的要求执行。 单元测试故意限制了测试的范围，并且很有用，但它们也不能完全复制运行时环境和可能的生产要求。 这就是为什么我们是集成测试的大力倡导者！我们可以使用集成测试来验证作业和任务是否可以执行冷启动。 事情会按照我们想要的方式进行吗？这些组件是否按照我们的要求协同工作？这些组件能否成功创建我们想要的系统？我们在日历失败中吸取了这一教训，我们的测试没有遵循与我们实际使用的路径相同的路径，导致大量测试......这无助于我们评估更改在现实世界中的表现。
继续讨论 2017 年 2 月发生的事件，我们找到了接下来的两个教训。
首先，不可用的 OAuth 令牌导致数百万用户注销设备和服务，32,000 台 Onhub 和 Google WiFi 设备执行了恢复出厂设置。 由于登录失败，手动恢复帐户的要求增加了 10 倍。 谷歌花了大约12个小时才从故障中完全恢复过来。
6.沟通渠道！还有备用频道！！和备份！！ 这些备份通道communication channels! and backup channels!! and backups for those backup channels!!!
是的，那是一段糟糕的时光。 你想知道是什么让它变得更糟吗？团队希望能够使用 Google Hangouts 和 Google Meet 来管理活动。 但是，当 35 亿用户注销其设备和服务。 ......回想起来，依赖这些谷歌服务是一个错误的决定。 确保您有一个不依赖且已经过测试的备用通信通道。
然后，2024年的同一事件让我们对优雅的退化有了更好的理解：[7]。
7.故意降低性能模式
可用性很容易理解为："完全正常"或"一切正常"...但是，通过性能降级模式始终如一地提供最少的功能有助于提供更一致的用户体验。 因此，我们仔细而刻意地构建了一种性能下降模式，因此在不稳定的情况下，用户可能根本无法看到它（这可能正在发生！）。服务应正常降级，并在特殊情况下继续运行。
下一课是一项建议，旨在确保最后一道防线系统在极端情况下（如自然灾害或网络攻击）按预期运行，从而导致生产力或服务可用性损失。
8.抗灾能力测试
除了单元测试和集成测试之外，还有其他类型的重要测试：灾难弹性和恢复测试。 灾难恢复测试用于验证您的服务或系统在发生故障、延迟或中断时是否可以继续运行，而恢复测试则验证您的服务是否可以在完全关闭后恢复到正常状态。 因此"在意想不到的环境中生存下来"[8] 两者都应该是业务连续性战略的关键部分。 一个有用的活动也可以是与团队坐下来讨论其中一些场景在理论上如何以棋盘游戏的形式发生。 这也是对那些可怕的探索"如果"有趣的机会，例如，"如果部分网络连接意外关闭，该怎么办
9.自动执行缓解措施
2023 年 3 月，多个数据中心的多个网络设备几乎同时发生故障，导致大面积丢包。 在这 6 天的中断期间，估计有 70% 的服务受到不同程度的影响，具体取决于网络故障时的位置、服务负载和配置。
在这种情况下，您可以通过自动采取缓解措施来缩短平均解决时间 （MTTR）。 如果有明确的信号表明正在发生故障，为什么不能自动启动缓解措施有时，最好先使用自动缓解措施，并保留根本原因，直到它避免影响用户。
10.缩短推出之间的时间，以降低推出出错的可能性
2022 年 3 月，支付系统出现大范围故障，导致客户无法完成交易，导致 Pokemon GO 社区日推迟。 原因是删除了单个数据库字段，这应该是安全的，因为该字段的所有使用都已事先从 ** 中删除。 不幸的是，由于系统的一部分发布速度较慢，这意味着该字段仍在被实时系统使用。
由于发布之间的延迟时间很长，尤其是在复杂的多组件系统中，因此很难从发布中推断出特定更改的安全性。 频繁发布 [9] – 通过适当的测试 – 可以减少此类故障的意外发生。
11.单个全局硬件版本是单点故障
仅使用一种特定型号的设备执行关键功能可简化操作和维护。 但是，这意味着如果模型出现问题，则不再执行该关键功能。
这发生在 2020 年 3 月，当时具有未发现的零日漏洞的网络设备经历了触发该漏洞的流量模式更改。 由于整个网络使用相同型号和版本的设备，因此存在严重的区域故障。 得益于多个网络骨干网，高优先级流量能够通过仍在运行的替代设备传输，从而避免了完全中断。
关键基础设施中的潜在漏洞可能无法被发现，直到看似无害的事件触发它们。 维护多样化的基础设施虽然成本高昂，但可能意味着失败和完全失败之间的区别。
就是这样！从 Google 二十年的可靠性工程中吸取的 11 个教训。 为什么是 11 节课？嗯，你看，谷歌的可靠性部门有着悠久的历史，但它仍然处于鼎盛时期。
引用
1] 不幸之轮 （"wheel of misfortune")
2] 服务最佳实践指南 （"service best practices guides")
3] 对那些全球变化进行抨击
4] 在此处阅读有关金丝雀策略的更多信息。
5] 在**中了解更多信息。
6] "一般缓解措施"
7] 优雅退化
8] "在意想不到的环境中生存下来"
9] 频繁发布。
作者丨Adrienne Walcer 编译丨***东风未明科技博客（ID：ewhisperCN） DBAPLUS社区欢迎技术人员投稿，投稿邮箱：editor@dbapluscn