为了看到前文所讨论的一些原则在实践中的应用，我们将深入探讨一个谷歌重大宕机事故的现实例子。我们将回顾事件的经过，了解规模化组织结构的运作方式，并展示如何解决这个问题以及我们从中学习到的经验。
对于谷歌来说，玛雅末日并不是2012年的新纪元现象。相反，玛雅末日发生在2019年6月2日，与一个名为Maya的网络自动化工具有关。Maya负责标记管理和网络流量调度，一个微小的代码改动导致了实体类型持续被错误标记。
大约在中午，我们正在进行计划中的维护，确定了一系列将在多个服务器上运行的操作和配置变更（包括在Maya上）。当这个错误标记与我们的作业调度逻辑冲突时，我们“发现”了一种新的故障模式，与流量调度相关的作业被大规模取消调度。出入这些区域的网络流量试图将重新调度的任务塞入剩余的网络容量中，其中流量调度功能仍然有效，但最终未能成功。网络变得拥挤，我们的系统正确地对流量过载进行了分级，并自动排空了较大、对延迟不敏感的流量，以保留较小、对延迟敏感的流量。
流量拥塞开始了。结果，我们的监控系统启动了事故管理流程的第一步：告警。当组件响应者从监控系统收到告警时，这反映了其负责的系统中发生的变化。我们的监控系统注意到错误率阈值被突破了，并向负责该网络组件的值守人员发送了自动通知，值守人员开始评估情况。
与此同时，受影响区域的网络容量减少导致溢出，这种网络拥塞引发了我们网络和计算基础设施中的级联故障。总体来说，我们的网络优先考虑用户流量高于内部流量，包括员工的流量。这实际上是合理的，因为我们宁愿从无法解决问题的99.9%的员工那里重新分配容量，并尽最大努力为我们的用户服务。参与事故响应的0.1%的员工通常知道如何继续处理并绕过这个限制。但是，这次级联故障的一个影响是我们的内部工具出现了重大中断，扰乱导致了大量告警的发送，导致大量人收到了呼叫短信。当每个值守人员都切换到事故响应模式时，他们注意到了：由于网络问题导致的服务不可用。网络组件值守人员迅速确定了网络拥塞的原因，但同样的网络拥塞导致服务降级，也减缓了他们恢复正确配置的能力。
每个人都想尽最大努力支持他们的用户，并了解服务恢复的预期轨迹，因此原本负责网络组件的值守人员团队突然新加入了很多同事。
我们在谷歌将组件分为三类：
- 基础设施组件，如网络管道或存储服务。
- 产品服务组件，如 YouTube 流媒体或 Google 搜索的前端。
- 内部服务组件，如监控、零信任远程访问、Maya 和算力管理。这些内部服务组件都在经历困难。
由于网络具有广泛的依赖性，所以在网络组件值守人员解决完问题之前，其他人都无法继续工作。其他值守人员开始提供帮助，并询问他们的服务何时能开始恢复。很多不同响应者预期的并行性，并没有加速问题的解决。根本原因和次生效应开始变得模糊不清；一个团队的原因是另一个团队的结果，每个人都在尝试贡献他们的知识。虽然每个人都是其系统栈的专家，但大多数人都没有对整体系统全面的大局观，不知道哪些工具路径变得不可用。
为什么？未触及拥堵网络的路径是正常的。如果路径在那时看起来像外部用户，则拥堵网络的路径也是正常的，因为我们优先考虑了它们。因此，我们向外部用户提供的服务是可用的——例如视频通话或编辑文档。然而，如果路径是内部服务，如作业控制或 Maya 配置，它就被降级并卡住了。
我们都在观看此次火山爆发，然而，在 20 分钟后，我们得出了问题的结论 “可能与熔岩有关。”
宕机一小时后，一位组件响应者注意到，影响我们基础设施的系统级问题过于普遍，围绕事故的协调沟通变得混乱不堪。此时，已有超过40位队友加入了事故响应通信频道，试图提供帮助。监控数据显示出：当前事故影响了半个地球。Google Cloud、Gmail、Google Calendar、Google Play等服务都受到了影响——导致企业都无法运作，大量员工无法高效工作，人们无法相互沟通。一些员工试图使用那些不依赖受损网络的零星服务，而另外的人们都已经放弃了。
近40人卷入了本次事故，网络英雄并没有足够的时间和精力，用来制定和协调实施适当的缓解措施，向所有利益相关者广泛沟通，并管理各方期望。因此，他们进行了升级。我们的网络组件值守人员向技术事故响应团队（Tech IRT）发出了求助请求；他们的请求触达到了许多处于合适工作时段时区里的Tech IRT成员，能够处理事故的成员表示了他们的可用性。由于事故影响如此广泛，许多人已经参与了事故。一些Tech IRT响应者没有担任事故指挥官的角色，因为他们是处理网络问题的团队成员或经理，可以帮助解决主要根本原因，所以他们选择了协助操作的工作。
接受事故指挥官角色的 Tech IRT 的成员，以前没有处理过受故障影响的网络组件，但他们能够评估系统状态和响应人员的情况。利用他们的训练有素，这位指挥官运用一种机制访问到了生产系统，该机制立即将他们的行动标识为“事故响应”，并绕过了“内部流量降级”的标志。一旦内部流量得到了一些空间，他们就指挥网络值守人员开始介入并解决问题。
在此过程中，他们迅速对正在进行的沟通，以及所有试图“提供帮忙”的人进行了组织和结构化。一旦这种混乱的工程能量被组织起来之后，每个人都开始一起取得到了进展。他们能够更清楚地跟踪不同系统的当前状态，并看到缓解措施的实施速度。随着这些繁琐的管理工作不再让网络组件响应者们不堪重负，他们和他们的团队有了实施适当缓解计划的空间，包括丢弃大量负载，为健康重启和一些紧急强行配置变更腾出系统空间。
一旦开始步入了缓解事故的路径，Tech IRT 成员就专注于将事故推向结束。他们设定了一些退出标准，以便我们可以关闭事故，确保其他系统在任何需要执行的恢复操作中得到支持，然后确保被卷入的响应团队都能够顺利交接并离场。
事故结束后，服务都恢复正常，我们进行了深入的事后分析复盘，以分析事故，并理解根本原因的细微之处，以及这些故障模式所揭示的新兴属性。自那以后，参与的网络团队已经开展了一些非常酷的工作计划，重新构建了 Maya，来防止这种故障模式，以及类似的，但以前未考虑到的故障模式，预防它们再次困扰我们的系统。
最后，我们用内部的个人档案徽章、荣誉性的表情包和奖金等方式奖励了相关参与的人员。对大多数人来说，这次非常严重的事故，是他们职业生涯中最艰苦的一天。也为每个参与事后分析复盘的人提供一些小奖励，是他们帮助我们从中得到学习，让我们持续的增长韧性。
来源： https://sre.google ；本白皮书一共有 7 章，后续章节将陆续发布。完整中文版白皮书即将发布，敬请期待。
❤️ Photo by Pixabay: https://www.pexels.com/photo/photo-of-a-2-fireman-killing-a-huge-fire-69934/