本文主要是介绍11条SRE血泪教训，建议您了解一下，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 缓解事故的程度应与事故的严重程度成正比
在事故发生期间，应该监控和评估情况的严重性，并选择与严重性相适应的故障缓解途径。
在最好的情况下，有风险的缓解措施可以解决故障。
而在最坏的情况下，故障缓解措施会失灵，导致中断时间延长。
此外，如果一切正常，您可以做出绕过标准程序的明智决定。
2 应在紧急情况发生前对恢复机制进行全面测试
中断是第一次尝试危险的负载下降过程的绝佳机会。
为了在高风险、高压力的情况下保持冷静，事先练习恢复机制和缓解措施并验证以下几点非常重要：
-
它们能满足您的需求
-
你知道如何去做
测试恢复机制还有一个有趣的副作用，就是可以降低执行其中某些操作的风险。自从下面这次混乱的故障后，加倍努力进行测试。
3 金丝雀所有变更
有一次，我们想推送缓存配置变更。我们非常确定这不会导致任何不良后果。但 “非常确定” 并不是百分之百的确定。结果发现，缓存对 YouTube 来说是一个相当关键的功能，而配置更改带来了一些意想不到的后果，使服务完全瘫痪了 13 分钟。如果我们采用渐进式发布策略金丝雀所有变更（canaried those global changes），这次故障本可以在对全球造成影响之前得到遏制。
大约在同一时期，YouTube 稍微年轻一些的兄弟公司 Google Calendar 也经历了一次故障，这也是接下来两节课的背景。
4 有一个“大红色（急停）按钮”
“急停按钮”是一种独特但非常实用的安全功能：它应该启动一个简单、易于触发的操作，将触发不良状态的因素还原为（理想情况下）关闭正在发生的一切。”急停按钮” 有很多种形状和大小——在提交潜在的危险操作之前，确定这些红色按钮可能是什么非常重要。我们曾险些触发一次重大故障，还好提交可能触发变更的工程师在变更传播之前拔掉了台式电脑的电源。因此，在计划重大部署时，请考虑什么是我的 “红色按钮”？确保每个服务依赖项都有一个 “红色按钮”，以便在紧急情况下使用。
5 仅有单元测试是不够的，还需要集成测试
啊。… 单元测试。它们验证单个组件是否能按照我们的要求执行。单元测试有意限制了测试范围，而且非常有用，但它们也无法完全复制运行时环境和可能存在的生产需求。因此，我们大力提倡集成测试！我们可以使用集成测试来验证作业和任务是否可以执行冷启动。事情是否能按我们希望的方式运行？各组件能否按照我们的要求协同工作？这些组件能否成功创建我们想要的系统？我们在一次 Calendar 故障中吸取了这一教训，在这次故障中，我们的测试并没有遵循与实际使用相同的路径，结果导致大量的测试，….. 这并不能帮助我们评估变更在现实中的表现。
转到 2017 年 2 月发生的一起事件，我们找到了下两个教训。
首先，不可用的 OAuth 令牌导致数百万用户注销了设备和服务，32000 台 OnHub 和 Google WiFi 设备执行了出厂重置。由于登录失败，手动恢复账户的要求增加了 10 倍。谷歌花了大约 12 个小时才完全从故障中恢复过来。
6 通信渠道！和备份渠道！! 以及这些备份渠道的备份！
是的，那是一段糟糕的时光。你想知道是什么让情况变得更糟吗？各团队都希望能够使用 Google Hangouts 和 Google Meet 来管理事件。但是，当 3.5 亿用户注销了他们的设备和服务时，….. 回过头来看，依赖这些谷歌服务是一个错误的决定。请确保您拥有非依赖性的备份通信渠道，并对其进行过测试。
然后，2017 年的同一事件让我们更好地理解了优雅降级 (graceful degradation):
7 刻意降级性能模式
人们很容易将可用性理解为 “完全正常 “或 “一切正常”…… 但是，通过降级性能模式持续提供最低限度的功能，有助于提供更加一致的用户体验。因此，我们谨慎而有意地构建了性能降级模式——因此在不稳定的情况下，用户可能根本无法看到它（可能现在就在发生！）。服务应优雅地降级，并在特殊情况下继续运行。
下一课是一项建议，旨在确保您的最后一道防线系统在极端情况下（如自然灾害或网络攻击）如期运行，从而导致生产力或服务可用性的损失。
8 测试抗灾能力
除了单元测试和集成测试，还有其他类型的重要测试：灾难应急和恢复测试 （disaster resilience and recovery testing）。灾难应急测试验证您的服务或系统在发生故障、延迟或中断时能否继续运行，而恢复测试则验证您的服务能否在完全关闭后恢复到正常状态。正如 “经受住意外”中所述，两者都应成为业务连续性战略的关键部分。
一项有用的活动还可以是让团队坐下来，以桌面游戏的方式讨论其中一些情景在理论上是如何发生的。这也是一个探索那些可怕的 “如果”的有趣机会，例如，”如果您的部分网络连接意外关闭怎么办？
9 自动化您的缓解措施
2023 年 3 月，几个数据中心的多台网络设备几乎同时发生故障，导致大面积数据包丢失。在这次为期 6 天的故障中，根据网络故障发生时的位置、服务负载和配置，估计有 70% 的服务受到了不同程度的影响。
在这种情况下，您可以通过自动采取缓解措施来缩短平均解决时间（MTTR）。如果有一个明确的信号表明某个故障正在发生，那么为什么不能自动启动缓解措施呢？有时，最好先使用自动缓解措施，而将根本原因留待避免对用户造成影响之后再处理。
10 缩短两次发布之间的间隔时间，降低发布出错的可能性
2022 年 3 月，支付系统发生大面积故障，客户无法完成交易，导致《口袋妖怪 GO》社区日被推迟。原因是删除了一个单一的数据库字段，由于事先已从代码中删除了该字段的所有用途，因此本应是安全的。不幸的是，由于系统的一部分发布速度较慢，这意味着实时系统仍在使用该字段。
由于发布之间的延迟时间较长，尤其是在复杂的多组件系统中，因此很难推段发布特定变更的安全性。频繁发布——在适当测试的情况下—可减少此类故障的意外发生。
11 单一的全局硬件版本就是单点故障
只用一种特定型号的设备来执行关键功能可以简化操作和维护。然而，这意味着如果该型号出现问题，则不再执行该关键功能。
这种情况发生在 2020 年 3 月，当时一台存在未被发现的零日漏洞的网络设备遇到了触发该漏洞的流量模式变化。由于整个网络使用的是同一型号和版本的设备，因此出现了严重的区域性故障。幸亏有多条网络主干线，高优先级流量才得以通过仍可正常工作的替代设备进行传输，才避免了全面中断。
关键基础设施中的潜在漏洞可能潜伏未被发现，直到一个看似无害的事件触发它们。维护多样化的基础设施虽然会产生成本，但却意味着故障与完全故障之间的差别。
这篇关于11条SRE血泪教训，建议您了解一下的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
