对IT运维从业人员来说,事故复盘是学习提高的快捷通道。当然,不能是发生自己运维对象系统上的事故,那就不是复盘而是被业务部门复仇了。2021国庆Facebook的6小时宕机事件,对正在进行从传统运维到SRE转型过程中的同学来说,是一个非常好的样本。
画了一张图,简述一下我目前理解的事件各方面,应该基本可以说清楚。

更多信息,我们从官方信息出发。
发生了什么
10月4日中午[1],美国社交媒体脸书(Facebook)、Instagram和即时通讯软件WhatsApp出现大规模宕机,影响范围偏布全球。当天傍晚,在中断服务约6小时后,大部分服务重新上线。对脸书不太熟悉的朋友,理解成美国的腾讯就可以了,全球有超过35 亿用户。脑补一下,假设微信、QQ和腾讯视频等全部停服,国内互联网上会是一幅多么火热的画面。
为什么发生
根据脸书公司的公告[2],协调数据中心之间网络流量的主干路由器上的配置更改导致了此通信中断的问题。【又是变更窗口,运维人心中永远的痛】。
这次中断是由管理Facebook骨干网络容量的系统触发的。骨干网是 Facebook 为将所有计算设施连接在一起而建立的网络,它由光纤电缆组成,跨越全球连接所有的数据中心。网络流量中断对数据中心的通信方式产生了连锁影响,导致服务停止。 【骨干网络崩溃,出现多地多数据中心之间的脑裂】
在网络维护期间,发布了一条命令来评估可用容量。但命令适得其反,断开网络并阻止 Facebook 的数据中心进行通信,旨在捕获错误命令的审计工具未能检测到错误。【运维工具的问题:工具功能和设计目标不符,审计系统对高危命令的控制不当;开发、测试、上线、运维各环节都脱不开关系】
但这只是问题的开始。这一变化导致数据中心和互联网之间的服务器连接完全断开,并且完全失去连接导致了第二个问题,使事情变得更糟。由于 Facebook 的数据中心离线,该公司管理其互联网地址的DNS服务器无法使用。
这使得互联网上无法定位Facebook的服务器,远程修复方式不可用,Facebook 的工程师努力恢复访问权限,但因为数据中心的强保护措施,员工无法立即进入。【非常时期,有没有采用物理手段,破门而入?】
Facebook已做了大量工作来加固系统以防止未经授权的访问,当试图从不是由恶意活动而是自身错误引起的中断过程进行恢复时,看到系统加固模块如何减慢解决问题的速度这件事变得很有趣。【架构决策点,日常方便还是恢复服务的环节方便】
由于业务网络和带外网络访问都出现故障,因此只能派工程师到现场现场调试问题并重新启动系统。这一切都发生得非常快,遇到了两个巨大的障碍:首先,由于网络出现故障,无法通过正常远程的方式访问数据中心,其次,DNS 完全丢失导致通常用来问题调查和诊断的内部运维工具无法使用。 【看来应用DNS化做得非常好,运维工具也云原生了。运维决策点:现场运维团队平时驻场轮班有必要吗?】
但这需要时间,因为这些设施的设计考虑了高水平的物理和系统安全性。它们很难进入,一旦进入内部,即使可以物理访问,硬件和路由器的设计也很难修改。因此,需要额外的时间来激活让人们到现场并能够在服务器上工作所需的安全访问协议。只有这样我们才能确认问题并使我们的主干重新上线。 【运维决策点:如果有现场运维团队平时驻场轮班,密码信封这种传统实践是不是有意义?】
至此,网传热梗坐实了,能访问机器的人不会修复问题,会修复的人不能访问机器。
脸书总结的事件亮点,由于已进行了很长时间的“风暴”演习,为这次极端情况做好了准备。在风暴演练中,通过使服务、数据中心或整个区域脱机,对所有涉及的基础设施和软件进行压力测试来模拟主要系统故障。这些演习的经验给了运维团队信心和经验,让运维可以重新上线并仔细管理不断增加的负载。【风暴演练应对启动风暴,避免二次雪崩】
最后,服务相对较快地恢复了,而没有发生任何系统范围的进一步故障。虽然以前从未经历过模拟我们的全球主干离线的风暴,但未来肯定会寻找方法来模拟类似这样的事件向坏的方向发展。从现在开始,我们的工作是加强我们的测试、演练和整体弹性,以确保此类事件尽可能少发生。【全球数据中心全域网络重启,没有出现大的问题,不得不说运维能力还是厉害的】
更多的启示
上述一连串的错误叠加,导致了6个小时的全球业务停顿。从每个环节来看,都是小问题或者小概率事件,但就是这些小的环节执行的质量,决定了运维的结果,所以说运维难做呀!同时,没有一种运维模式是万能的,都是一个个坑堆出来的。在IT的世界,没有银弹、没有银弹、没有银弹!
对我们的启示,除了上述那些蓝色字体的内容,对运维同学来说,谨慎应对变更,真的还是要牢记变更四原则:预案完整、测试充分、可灰度发布,可迅速回退。
以上,都是个人不成熟的看法,是我基于已知信息作出的“有限理性”判断。如有异议,你是对的。如觉有益,请帮助点个“在看”和/或进行转发,让更多人看到。
[1] https://www.nytimes.com/2021/10/05/technology/facebook-outage-cause.html
[2] https://engineering.fb.com/2021/10/05/networking-traffic/outage-details




