江苏龙网

  1. 主页 > 生活百科 > >

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

谷歌


6. 沟通渠道！还有备份通道?。∫约罢庑┍阜萃ǖ赖谋阜荩 。。?
是的 ， 那是一段糟糕的时光 。你想知道是什么让情况变得更糟的吗？团队希望能够使用 Google Hangouts 和 Google Meet 来管理事件 。但当 3.5 亿用户退出他们的设备和服务时……回想起来，依赖这些谷歌服务是一个糟糕的决定 。确保你拥有独立的备份通信通道 ， 并且已对其进行了测试 。
然后，2017 年的同一故障让我们更好地理解了优雅降级：
7. 故意降级性能模式
人们很容易将可用性视为“完全启动”或“完全关闭”……但是能够通过降级性能模式提供连续的最小功能有助于提供更一致的用户体验 。因此，我们谨慎而有意地构建了性能降级模式——因此 ， 在粗略的补丁程序中，它甚至可能不会被用户看到（它可能现在正在发生?。?。服务应该适度降级，并在特殊情况下继续运行 。
下一个经验教训建议我们确保最后一道防线系统在极端情况下能如预期的那样工作，例如自然灾害或网络攻击，这些情况会导致生产力或服务可用性的损失 。
8. 故障弹性测试
除了单元测试和集成测试之外，还有一些非常重要的其他类型的测试：故障弹性和恢复测试 。弹性测试验证我们的服务或系统在发生故障、延迟或中断时是否正常运行，而恢复测试则验证服务在完全关闭后是否能够恢复到稳态 。两者都应该是业务连续性战略的关键部分——如“抵御意外”中所描述的那样 。一个有用的活动还可以是让你的团队坐下来，研究其中一些场景在理论上是如何发挥作用的——桌面游戏风格 。这也是一个探索那些可怕的“假设”的有趣机会，例如，“如果部分网络连接意外关闭怎么办？” 。
9. 自动化故障削减措施
2023 年 3 月，几个数据中心的多个网络设备几乎同时发生故障，导致大范围的数据包丢失 。在这 6 天的宕机故障中，估计 70% 的服务受到了不同程度的影响，具体取决于网络故障时的位置、服务负载和配置 。
在这种情况下，我们可以通过手动自动化故障削减措施来减少平均解决时间（MTTR） 。如果有一个明确的信号表明某个特定的故障正在发生，那么为什么不能以自动化的方式启动故障削减措施呢？有时，最好先使用自动故障削减措施，并在避免了用户影响之后再解决根本原因 。
10. 缩短部署之间的时间间隔 ， 以降低部署出错的可能性
2022 年 3 月，支付系统大范围故障 ， 客户无法完成交易，导致 Pokémon GO 社区日被推迟了 。原因是删除了一个数据库字段，这应该是安全的 ， 因为该字段的所有使用都事先从代码中删除的 。不幸的是，系统某一部分的缓慢部署节奏意味着该字段仍在被线上系统所使用 。
部署之间有很长的间隔，尤其是在复杂的多组件系统中，会使得我们很难推断出特定变更的安全性 。间隔很近部署（并进行适当的测试）可以减少此类故障的意外发生 。
11. 单一全球硬件版本会是单点故障
只使用一种特定型号的设备来执行关键功能可以简化操作并能使运维更简单 。然而，这也意味着 ， 如果该模型出现问题，则该关键功能将不再执行 。
这一故障发生在 2020 年 3 月 ， 当时一台网络设备遇到了一个未被发现的零日漏洞，该漏洞触发了流量模式的变更 。由于整个网络都在使用相同型号和版本的设备，因此出现了严重的区域性故障 。防止这种情况全面故障的原因是存在多个网络主干网，这些主干网允许高优先级流量通过仍在工作的替代路由 。
关键基础设施中的潜在漏洞可能潜伏在未被发现的地方，直到一个看似无害的事件触发了它们 。维护多样化的基础设施虽然本身会产生成本，但可能意味着麻烦的区域故障和全面故障之间的差异 。
所以你学到了嘛！从谷歌 20 年的站点可靠性工程中汲取的 11 个经验教训 。为什么是 11 个呢？好吧，你看，谷歌站点可靠性有着丰富的历史并仍然处于鼎盛时期 。
原文链接：
https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/

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


推荐阅读


上一篇：负载均衡在大规模分布式系统中的应用：解决性能瓶颈

下一篇：HTTP/3 为什么正迅速吞噬世界？