「译文」Google SRE 二十年的经验教训

这篇具有很好参考价值的文章主要介绍了「译文」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):](https://sre.google/sre-book/addressing-cascading-failures/#:~:text=Graceful degradation takes the concept,decreasing the quality of responses.)

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 编写.文章来源地址https://www.toymoban.com/news/detail-745421.html

到了这里,关于「译文」Google SRE 二十年的经验教训的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Vulnhub之Inplainsight靶机详细测试过程及经验教训

    利用Kali Linux的netdiscover工具识别目标主机的IP地址为192.168.56.254 NMAP扫描结果表明目标主机有3个开放端口:21(ftp)、22(ssh)、80(http) 用户:mike, joe 可能有backdoor文件 目标站点是wordpress? Gobuster工具识别出目录/wordpress,访问该目录,发现页面显示不完整,查看页面源代码,可知需

    2023年04月16日
    浏览(39)
  • 关于大一上学期STM32培训的经验及教训(完全初学)

          主要是写出来给要直接学习STM32的人的一些经验或者是教训以及踩坑点,我后续也会开始写STM32的一些我已经学会的基础性的初学者应用型教程(如没有前置知识点亮LED,我会在这里说GPIO是个啥,怎么选口,怎么查手册等基础入门方法) 我也要期末考试后回家了,我想

    2024年02月03日
    浏览(35)
  • 钻研流行风格三十年的老设计师告诉你“西班牙”风格应该怎么去营造,纯干货!

    ”西班牙风格“并不是一个流行词。然而,它却是永恒的—可以追溯到 1600 年代,当时加利福尼亚和佛罗里达等州的西班牙风格建筑蓬勃发展。  虽然 \\\"西班牙风格 “一词最常让人联想到的是建筑(灰泥墙、红瓦屋顶、圆形拱门),但也有一种西班牙风格美学可归结到住宅内

    2024年02月10日
    浏览(38)
  • 消息队列二十年

    2003 至今有很多优秀的消息队列诞生,其中就有被大家所熟知的就是 kafka、阿里自研的 rocketmq、以及后起之秀 pulsar。首先我们先来了解一下每一时期消息队列诞生的背景以及要解决的核心问题是什么? 如图所示,我把消息队列的发展切分成了三个大的阶段。 第一阶段:解耦

    2024年02月14日
    浏览(57)
  • Building AI-Copilot:构建 LLM 支持的生成应用程序的一些经验教训和模式

    我们正在构建一个用于产品策略和生成创意的实验性人工智能副驾驶,名为“Boba”。一路上,我们学到了一些关于如何构建此类应用程序的有用经验,我们已经根据模式制定了这些应用程序。这些模式允许应用程序帮助用户更有效地与大语言模型 (LLM) 交互,编排提示以获得

    2024年02月14日
    浏览(43)
  • 揭示十年数据库经验,告诉你如何轻松应对常见问题(SQL 小虚竹)

    回城传送–》《数据库问题解决方案》 ❤️作者主页:小虚竹 ❤️作者简介:大家好,我是小虚竹。2022年度博客之星评选TOP 10🏆,Java领域优质创作者🏆,CSDN博客专家🏆,华为云享专家🏆,掘金年度人气作者🏆,阿里云专家博主🏆,51CTO专家博主🏆 ❤️技术活,该赏 ❤

    2023年04月18日
    浏览(55)
  • 复旦-华盛顿大学EMBA 二十年20人丨徐欣:从外企转战民企的变身

    复旦大学-华盛顿大学EMBA20周年校友系列访谈。 2008年堪称转折之年,中国举行北京奥运会向全世界展示“和而不同”的理念,入世7年让中国在贸易、金融领域与全球市场紧密相连,一大批最优秀的中国民营企业也加速踏上全球化之路。 就在这一年,从微软起步一路“春风得

    2024年02月07日
    浏览(39)
  • 三本光电从颓废到武汉年薪30w的本科经历经验与浅谈(毕业工作一年的嵌入式软件工程师经验分享)

    三本光电从颓废到武汉年薪30w的本科经历经验与浅谈(毕业工作一年的嵌入式软件工程师经验分享) 我目前工作岗位为嵌入式软件工程师(雷达射频方向)。 我选择了武汉的一家做雷达的小企业,算上项目奖,年薪能拿到30。 我之前被坑的经历可以看我上一次发的文章。 我

    2024年02月04日
    浏览(58)
  • Java服务端集成Google FCM推送的注意事项和实际经验

    公司的app要上海外,涉及到推送功能,经过综合考虑,选择Google FCM进行消息推送。 查看一些集成博客和官方文档,看的似懂非懂,迷迷惑惑。本篇文章除了将我实际集成的经验分享出来,也会对看到的博客及其中产生的疑惑、注意事项一一评论。 从官方文档和众多博客中,

    2024年02月10日
    浏览(42)
  • [经验教程]谷歌浏览器google chrome网站不安全与网站的连接不安全怎么办?

    使用google chrome谷歌浏览器访问某些网站打开时google chrome谷歌浏览器提示网站不安全,与网站的连接不安全,您之所以会看到此警告,是因为该网站不支持https造成的怎么办? google chrome谷歌浏览器网站不安全与网站的连接不安全怎么办? 1、打开谷歌google chrome浏览器点击右上

    2024年02月07日
    浏览(70)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包