本文主要是介绍「译文」Google SRE 二十年的经验教训，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
👉️URL: https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/
✍️Authors:
Adrienne Walcer, Kavita Guliani, Mikel Ward, Sunny Hsiao, and Vrai Stacey
Contributors:
Ali Biber, Guy Nadler, Luisa Fearnside, Thomas Holdschick, and Trevor Mattson-Hamilton
📝Description:
Site Reliability Engineering, incident management, learning, lessons learned, SRE
前言
二十年可以发生很多事情，尤其是当你忙于发展的时候。
二十年前，谷歌有一对小型数据中心，每个中心有几千台服务器，通过一对 2.4G 网络链路环形连接。我们使用 Python 脚本（如 "Assigner"、"Autoreplacer "和 "Babysitter"）运行我们的私有云（虽然当时我们并不这么称呼它），这些脚本在包含单个服务器名称的配置文件上运行。我们有一个小型的机器数据库（MDB），可以帮助整理和保存单个服务器的信息。我们的工程师小团队使用脚本和配置文件自动解决一些常见问题，并减少了管理服务器小舰队所需的人工劳动。
时光荏苒，Google 的用户为搜索而来，为免费的 GB Gmail 而去，我们的机群和网络也随之发展壮大。如今，就计算能力而言，我们的规模是 20 年前的 1000 多倍；就网络而言，我们的规模是 20 年前的 10000 多倍，而且我们在每台服务器上花费的精力比以前少得多，同时我们的服务堆栈也具有更好的可靠性。我们的工具已经从一系列 Python 脚本发展到集成的服务生态系统，再到默认提供可靠性的统一平台。我们对分布式系统的问题和故障模式的理解也在不断发展，因为我们遇到了新的故障类型。我们创建了 不幸之轮 ("Wheel of Misfortune")，我们编写了 服务最佳实践指南 ("Service Best Practices guides")，我们出版了《Google's Greatest Hits》，今天，我们非常高兴地向大家介绍：
- 本杰明-特雷纳-斯洛斯，谷歌 SRE 的创建者
网站可靠性工程二十年的经验教训
让我们从 2016 年说起，那时候 YouTube 还在提供 "阿黛尔的拼车卡拉 OK "和永远吸引人的 "Pen-Pineapple-Apple-Pen"等您最喜爱的视频。由于 YouTube 的分布式内存缓存系统出现错误，YouTube 经历了长达 15 分钟的全球中断，导致 YouTube 服务视频的能力中断。以下是我们从这次事件中学到的三个教训。
1 缓解事故的程度应与事故的严重程度成正比 (The riskiness of a mitigation should scale with the severity of the outage)
有这样一个笑话：一个人在网上发布了一张在自己家里看到蜘蛛的照片，The Captain 说："是时候搬到新房子了！"。这个笑话的意思是，对这一事件（看到一只可怕的蜘蛛）将采取严厉的缓解措施（放弃你现在的家，搬到新家）。我们在 SRE 中也有过一些有趣的经历，那就是选择一种风险大于其所要解决的故障的缓解措施。在前面提到的 YouTube 故障事件中，一个冒险的负载削减过程并没有解决故障问题。..... 反而造成了连锁故障。
我们深刻地认识到，在事故发生期间，我们应该监控和评估情况的严重性，并选择与严重性相适应的故障缓解途径。在最好的情况下，有风险的缓解措施可以解决故障。而在最坏的情况下，故障缓解措施会失灵，导致中断时间延长。此外，如果一切正常，您可以做出绕过标准程序的明智决定。
2 应在紧急情况发生前对恢复机制进行全面测试 (Recovery mechanisms should be fully tested before an emergency)
在高大的城市建筑中进行紧急消防疏散，是第一次使用梯子的绝佳机会。同样，中断也是第一次尝试危险的负载下降过程的绝佳机会。为了在高风险、高压力的情况下保持冷静，事先练习恢复机制和缓解措施并验证以下几点非常重要：
- 它们能满足您的需求
- 你知道如何去做
测试恢复机制还有一个有趣的副作用，就是可以降低执行其中某些操作的风险。自从下面这次混乱的故障后，我们加倍努力进行测试。
3 金丝雀所有变更 (Canary all changes)
有一次，我们想推送缓存配置变更。我们非常确定这不会导致任何不良后果。但 "非常确定" 并不是百分之百的确定。结果发现，缓存对 YouTube 来说是一个相当关键的功能，而配置更改带来了一些意想不到的后果，使服务完全瘫痪了 13 分钟。如果我们采用渐进式发布策略 金丝雀所有变更 (canaried those global changes)，这次故障本可以在对全球造成影响之前得到遏制。在这里阅读有关金丝雀策略的更多信息，以及 在视频中了解更多信息。
大约在同一时期，YouTube 稍微年轻一些的兄弟公司 Google Calendar 也经历了一次故障，这也是接下来两节课的背景。
4 有一个 "大红色（急停）按钮"(Have a "Big Red Button")
"急停按钮"是一种独特但非常实用的安全功能：它应该启动一个简单、易于触发的操作，将触发不良状态的因素还原为（理想情况下）关闭正在发生的一切。"急停按钮" 有很多种形状和大小--在提交潜在的危险操作之前，确定这些红色按钮可能是什么非常重要。我们曾险些触发一次重大故障，还好提交可能触发变更的工程师在变更传播之前拔掉了台式电脑的电源。因此，在计划重大部署时，请考虑什么是我的 "红色按钮"？确保每个服务依赖项都有一个 "红色按钮"，以便在紧急情况下使用。更多信息，请参阅 "通用缓解措施"！
5 仅有单元测试是不够的，还需要集成测试 (Unit tests alone are not enough - integration testing is also needed)
啊。... 单元测试。它们验证单个组件是否能按照我们的要求执行。单元测试有意限制了测试范围，而且非常有用，但它们也无法完全复制运行时环境和可能存在的生产需求。因此，我们大力提倡集成测试！我们可以使用集成测试来验证作业和任务是否可以执行冷启动。事情是否能按我们希望的方式运行？各组件能否按照我们的要求协同工作？这些组件能否成功创建我们想要的系统？我们在一次 Calendar 故障中吸取了这一教训，在这次故障中，我们的测试并没有遵循与实际使用相同的路径，结果导致大量的测试。..... 这并不能帮助我们评估变更在现实中的表现。
转到 2017 年 2 月发生的一起事件，我们找到了下两个教训。
首先，不可用的 OAuth 令牌导致数百万用户注销了设备和服务，32000 台 OnHub 和 Google WiFi 设备执行了出厂重置。由于登录失败，手动恢复账户的要求增加了 10 倍。谷歌花了大约 12 个小时才完全从故障中恢复过来。
6 通信渠道！和备份渠道！! 以及这些备份渠道的备份！!!(COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!)
是的，那是一段糟糕的时光。你想知道是什么让情况变得更糟吗？各团队都希望能够使用 Google Hangouts 和 Google Meet 来管理事件。但是，当 3.5 亿用户注销了他们的设备和服务时。..... 回过头来看，依赖这些谷歌服务是一个错误的决定。请确保您拥有非依赖性的备份通信渠道，并对其进行过测试。
然后，2017 年的同一事件让我们更好地理解了 优雅降级 (graceful degradation):
7 刻意降级性能模式 (Intentionally degrade performance modes)
人们很容易将可用性理解为 "完全正常 "或 "一切正常"...... 但是，通过降级性能模式持续提供最低限度的功能，有助于提供更加一致的用户体验。因此，我们谨慎而有意地构建了性能降级模式--因此在不稳定的情况下，用户可能根本无法看到它（可能现在就在发生！）。服务应优雅地降级，并在特殊情况下继续运行。
下一课是一项建议，旨在确保您的最后一道防线系统在极端情况下（如自然灾害或网络攻击）如期运行，从而导致生产力或服务可用性的损失。
8 测试抗灾能力 (Test for Disaster resilience)
除了单元测试和集成测试，还有其他类型的重要测试：灾难应急和恢复测试 (disaster resilience and recovery testing)。灾难应急 (disaster resilience) 测试验证您的服务或系统在发生故障、延迟或中断时能否继续运行，而恢复测试 (recovery testing) 则验证您的服务能否在完全关闭后恢复到正常状态。正如 "经受住意外" 中所述，两者都应成为业务连续性战略的关键部分。一项有用的活动还可以是让团队坐下来，以桌面游戏的方式讨论其中一些情景在理论上是如何发生的。这也是一个探索那些可怕的 "如果"的有趣机会，例如，"如果您的部分网络连接意外关闭怎么办？
9 自动化您的缓解措施 (Automate your mitigations)
2023 年 3 月，几个数据中心的多台网络设备几乎同时发生故障，导致大面积数据包丢失。在这次为期 6 天的故障中，根据网络故障发生时的位置、服务负载和配置，估计有 70% 的服务受到了不同程度的影响。
在这种情况下，您可以通过自动采取缓解措施来缩短平均解决时间（MTTR）。如果有一个明确的信号表明某个故障正在发生，那么为什么不能自动启动缓解措施呢？有时，最好先使用自动缓解措施，而将根本原因留待避免对用户造成影响之后再处理。
10 缩短两次发布之间的间隔时间，降低发布出错的可能性 (Reduce the time between rollouts, to decrease the likelihood of the rollout going wrong)
2022 年 3 月，支付系统发生大面积故障，客户无法完成交易，导致《口袋妖怪 GO》社区日被推迟。原因是删除了一个单一的数据库字段，由于事先已从代码中删除了该字段的所有用途，因此本应是安全的。不幸的是，由于系统的一部分发布速度较慢，这意味着实时系统仍在使用该字段。
由于发布之间的延迟时间较长，尤其是在复杂的多组件系统中，因此很难推段发布特定变更的安全性。频繁发布--在适当测试的情况下--可减少此类故障的意外发生。
11 单一的全局硬件版本就是单点故障 (A single global hardware version is a single point of failure)
只用一种特定型号的设备来执行关键功能可以简化操作和维护。然而，这意味着如果该型号出现问题，则不再执行该关键功能。
这种情况发生在 2020 年 3 月，当时一台存在未被发现的零日漏洞的网络设备遇到了触发该漏洞的流量模式变化。由于整个网络使用的是同一型号和版本的设备，因此出现了严重的区域性故障。幸亏有多条网络主干线，高优先级流量才得以通过仍可正常工作的替代设备进行传输，才避免了全面中断。
关键基础设施中的潜在漏洞可能潜伏未被发现，直到一个看似无害的事件触发它们。维护多样化的基础设施虽然会产生成本，但却意味着故障与完全故障之间的差别。
就是这样！从谷歌二十年的网站可靠性工程中汲取的 11 条经验。为什么是 11 条经验？嗯，你看，谷歌网站可靠性部门拥有悠久的历史，但仍处于鼎盛时期。
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.
这篇关于「译文」Google SRE 二十年的经验教训的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
