从www.datadoghq.com网站获得消息，Datadog公司在2023年3月经历的一次全球性故障。
Datadog 是一项可观察性服务，用于监视服务和应用程序，并在发生异常时向团队发出警报。可观察性服务对于确认服务在可靠运行而言必不可少。当它们停止运行时，结果可能对公司不利。
故障现象：
2023年3月8日06:03 UTC开始，我们经历了一次故障，影响了Datadog的US1、EU1、US3、US4和US5地区所有服务。
故障开始时，用户无法通过浏览器或API访问平台或各种Datadog服务，监视器也不可用且无警报。各种服务的数据获取也在故障开始时受到影响。
故障影响：
本次故障从2023年3月8日06:03 UTC开始，至3月9日08:58 UTC所有区域的所有服务都已运行正常。（故障恢复时长：近27小时）
直到3月10日06:25 UTC才完全解决问题，并回填历史数据[1]。因此，该全球故障持续了大约48个小时。（完全消除影响时长:48小时）
这起事件代价高昂，后来的财报电话会议透露，故障直接导致收入损失了 500 万美元（3552 万人民币）。
故障原因：
本次故障从2023年3月8日06:03 UTC开始，至3月9日08:58 UTC所有区域的所有服务都已运行正常。（故障恢复时长：近27小时）
直到3月10日06:25 UTC才完全解决问题，并回填历史数据[1]。因此，该全球故障持续了大约48个小时。（完全消除影响时长:48小时）
这起事件代价高昂，后来的财报电话会议透露，故障直接导致收入损失了 500 万美元（3552 万人民币）。
故障应急：
Datadog成立了内部高严重性事件响应小组，由10名高级工程师，约70名当地事件指挥官和多达750名应急小组成员在四个班次中工作，以解决故障。解决问题思路：
初始工作重点是恢复实时遥测数据的正常摄取和处理，以便客户即使只有有限的历史数据访问权限也能使用该平台。
一旦实时数据可用，我们就将恢复工作转向了在停机开始时已被获取但未被处理的历史数据。
同时，我们开始在我们的状态页面上提供频繁的更新，以便让客户了解情况。
故障原因：
简述：
2023年3月8日06:00 UTC，一些虚拟机自动应用了一个安全更新到systemd，这导致在systemd-networkd重启时出现了一个潜在的网络堆栈负面交互（在通过systemd v249运行的Ubuntu 22.04上）。也就是说，systemd-networkd强制删除了容器网络接口（CNI）插件（Cilium）管理的路由，这导致受影响的节点下线。
具体描述：
1、安全更新对 systemd 进程进行了更新。
2、systemd 执行时，其子进程（ systemd-networkd ）也会重新启动。
3、systemd-networkd 是一个管理网络配置的进程。由于重启，该进程无意中删除了网络路由。
4、system-networkd 移除的路由由一个基于 eBPF （扩展伯克利数据包过滤器）容器路由控制平面加以管理，该控制平面又基于 Cilium。Cilium 负责处理容器之间的通信。Datadog 的网络控制平面负责管理 Kubernetes 集群。
5、由于路由已被删除，这些路由中的虚拟机（节点）从网络控制平面中消失殆尽，处于宕机状态。
6、问题是这类更新在成千上万个虚拟机上几乎同时进行。这还不是最糟糕的，失去网络控制平面才是最糟糕的。在循环依赖关系中，重置还使网络路由控制平面处于宕机状态。节点从控制平面消失很不幸，但幸好它们可以快速恢复。事后团队总结道，“一些虚拟机依赖基于 Cilium 的区域控制平面。这导致我们用来运行平台的大多数 Kubernetes 集群无法调度新的工作负载、自动修复和自动扩展。“
比较有趣的是，团队表示后面这样的问题不会再出现了。
每当我们向平台推送新代码、安全补丁或配置更改时，我们都是按区域、集群、节点逐个进行的。作为一个流程问题，我们不会就地应用更改；相反，我们以蓝/绿方式替换节点和容器。不成功的更改会触发自动回滚。我们对这个变更管理工具有信心，因为它是在大规模下每天进行数十次练习。
然而，我们用于运行Kubernetes的基本操作系统映像启用了传统安全更新通道，这导致自动更新应用。按设计，我们使用相当简单的基本操作系统映像，因此这些更新不频繁，并且直到那一天都没有造成干扰。
ps：大致理解就是一个特殊更新通道无意被触发，这也是整体变更管理、灰度切流、蓝绿发布等方式完全失效了。
几个可以汲取的教训和经验总结：
1、任何一个重大故障的出现，往往都是我们在系统、操作多个环节连续犯错了。如同这篇报告的总结透出的乐观，其实面向未来更多一点悲观主义更好。
它会再次发生吗？不会。我们已经在所有受影响的区域禁用了这个传统安全更新通道，所以它不会再次发生。我们还更改了systemd-networkd的配置，使其在重新启动时保留路由表不变。最后，我们审查了潜在类似遗留更新通道的基础设施。
今天是systemd-networkd的问题，下一次可能是别的问题。
今天是更新通道的问题，下一次可能是别的问题。
2、基础设施的稳定性和循环依赖问题。比如一个密文管理服务 Vault 依赖服务发现框架 Consul。所以当 Consul 变得运行失常时，Vault 就宕机了，但是需要 Vault 来操作 Consul：这就形成了所谓的循环依赖关系。
比如在曾经在某城市，员工需要打印核酸检测报告隐性才能入楼办公。但是访问核酸报告的服务因为访问人员过多而不能提供服务。
3、没有好办法，能不能监测到哪些绕过流程的事件。比如变更管理平台包含了99%的事件，但是出问题的就是1%。 如何做事前预防和事中监测。等到问题出现，能快速定位，也是一个必须的。
4、报告中Datadog的反思：这是我们的第一次全球性事故。我们设计Datadog区域的明确目标是实现自治和对本地故障的弹性。这就是为什么它们建在完全独立的云提供商上的多个区域，没有任何彼此之间的直接连接。这也是为什么我们没有全球共享的控制平面。为了加强恢复过程中的负载，每个服务在每个区域都有备用服务、跨可用性区域的主动-主动设置以及额外的容量。然而，我们没有想象它们如何保持间接关系，这个问题将指导我们如何继续加强我们基础设施。
5、混沌工程的加强。我们进行失败测试，但我们未考虑我们需要在测试中考虑的降级规模。从现在开始，我们将使用我们看到的基础设施破坏程度来证明平台可以在降级条件下运行而不完全崩溃。结合前面的观点，这可能采取在降级模式下只有紧急数据可用和处理的形式。
6、在部分恢复时，如何指导客户能访问系统，减少损失。即使分别服务于实时和历史数据（例如APM的实时搜索和日志管理），我们仍未为客户提供明确的指导，告知他们如何在系统可用时立即访问我们的系统，即使在更广泛的事故仍在修复的情况下。在未来，我们将优先共享关于哪些服务和数据可用以及如何访问它们的指南并提供给我们的客户。
总结：
如同所有云厂商都出现过不同级别的故障一样，对于可用性的追求，没有人能走到上帝视角，不与尘土结缘。
在各种工程方法之上，在责任人、流程SOP上也需要持续的建设。
祝天下无故障吧。
可以加入技术琐话读者群，请后台回复：读者群
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。