小程序版
微信扫码，随时查命令
本文是公开报告的摘要与解读，事实以原始报告为准。
2023 年 3 月 8 日 06:03 UTC，Datadog 发生跨区域基础设施连接故障。US1、EU1、US3、US4、US5 五个区域受影响，浏览器和 API 访问中断，Monitor 服务不可用且无法告警，数据摄取受损，历史数据访问和处理也受影响。Datadog 称这是公司第一次遇到全球范围的事件。
官方复盘于 2023 年 5 月 16 日发布，作者为 Alexis Lê-Quôc；5 月 24 日又发布平台级影响的深度分析，作者为 Laurent Bernaille。报告给出的恢复节点是：09:13 恢复 Web 访问（故障后 3 小时 10 分），3 月 9 日 08:58 所有区域所有服务恢复运行（26 小时 55 分），3 月 10 日 06:25 完成历史数据回填后彻底解决（48 小时 22 分）。
以下时间均为 UTC。
| 时间 | 事件 |
|---|---|
| 3 月 8 日 06:00 | 自动 systemd 安全更新被应用 |
| 06:03 | 客户可见故障开始；内部监控在更新后 3 分钟发出告警 |
| 06:31 | 首次状态页公告，公开宣布事件 |
| 07:23 | 状态更新提示可能出现数据摄取和 Monitor 影响 |
| 09:13 | Web 访问恢复 |
| 16:44 | 第一个主要服务宣布恢复运行 |
| 3 月 9 日 08:58 | 所有区域的所有服务恢复运行 |
| 3 月 10 日 06:25 | 历史数据回填完成，事件彻底解决 |
受影响区域是 US1、EU1、US3、US4、US5，影响范围覆盖 Datadog 的整个服务目录。用户无法通过浏览器或 API 访问平台；Monitor 服务不可用，意味着客户在那段时间也不能依赖 Datadog 的告警；数据摄取最初受损，历史数据的访问和处理也受到干扰。
基础设施侧，06:00–07:00 之间有数万个节点离线。Datadog 的 estate 横跨数十个可用区和三家云厂商。深度分析给出的数字是：多个区域中超过 60% 的实例失联，三家云厂商都受影响，包括运行 CI/CD 和自动化系统的实例。
这说明：Datadog 的区域本应相互独立，但一次 OS 级更新让它们同时进入故障状态。客户侧的影响不仅是“看不到 Dashboard”，还包括“告警本身也停了”，这会放大其他系统对 Datadog 的依赖风险。
直接触发因素是一次自动 systemd 安全更新。受影响环境是 Ubuntu 22.04、systemd v249（changelog 为 249.11-0ubuntu3.7）。更新导致 systemd-networkd 重启，触发一个潜伏的网络栈缺陷：它删除了由 Cilium 管理的路由，容器网络随之断开，节点离线。
为什么全新启动或重启节点没有复现？原因是启动顺序：正常启动时 systemd-networkd 先启动，之后 Cilium 才安装路由；只有在一个正在运行的节点上原地重启 systemd-networkd，才会重现“已有路由被删除”的序列。因此常规重启测试没有提前暴露问题。
为什么五个区域同时中招？Kubernetes 基础镜像启用了 legacy security-update channel，更新会自动安装；默认维护窗口是 06:00–07:00 UTC，五个本来独立的区域在同一时间窗口内一起更新。Datadog 平时的变更管理是逐区域、逐集群、逐节点，使用蓝绿替换和自动回滚；OS 级自动更新绕过了这套流程。报告把这称为“通过共同更新时间表产生的间接耦合”。
深度分析补充：Cilium 使用云网络的 Pod IP，systemd-networkd 删除自定义 IP 规则后，AWS 和 Azure 上的 Pod 出站流量中断；删除 Cilium 的 local-lookup 规则后，访问节点 IP 的流量不再被视为本地流量，所有云厂商的主机连接都受影响。
团队先关闭 legacy security-update channel，并重新配置 systemd-networkd，使其在重启时不再改动路由表；随后审计基础设施中是否还有类似的 legacy channel。报告强调，关闭该 channel 并没有削弱安全，因为它只是重复了正常的补丁流程。
恢复顺序是：先恢复计算容量，并临时扩到高于正常水平，以便同时处理实时数据和历史数据；再恢复每个区域的内部控制面，然后修复数百个 Kubernetes 集群，最后并行恢复各项服务。团队优先恢复实时遥测，再处理历史数据积压。由于大量节点同时离线，恢复不是简单的“重启”，还要处理 quorum 依赖的元数据存储和分片存储的退化。
不同云厂商的行为差异影响了恢复：有的厂商把失联节点标记为不健康但不立即替换，重启可以保留有状态数据；有的厂商立即替换实例，导致本地临时盘数据丢失，并产生大规模替换潮，考验区域配额。深度分析提到，AWS 在 08:00 前已经替换了某个区域约 60% 的实例；Google Cloud 和 Azure 没有替换“仍在运行但不可达”的实例，Datadog 通过云 API 重启它们。后来发现，AWS 的自动替换抹掉了本地临时盘，反而让数据存储恢复更难。
响应组织方面，Datadog 成立了约 10 名高级工程领导组成的应急指挥中心，约 70 名本地 incident commander，450–750 名响应者分四班工作；沟通负责人协调了约 200 次状态更新，覆盖四个区域，数百名支持工程师参与。检测来自内部监控，而不是客户 Monitor，因为客户 Monitor 本身也不可用。
第一，常规补丁可以激活全舰队范围的隐藏行为。systemd 的小版本更新、CNI 的重启顺序、路由规则的所有权，平时都不显眼，但组合起来可以让数万节点同时离线。
第二，补丁窗口本身就是一种全局耦合。区域独立、集群独立，并不代表更新节奏独立；基础镜像的自动更新通道和默认维护窗口，必须纳入变更管理和灰度策略。
第三，要测试“原地重启”，而不只是“重启机器”。启动顺序差异会让同一组件在两种路径下表现完全不同；关键系统组件升级后，应在隔离环境验证原地重启、滚动重启和冷启动。
第四，监控和状态页要能独立工作。客户 Monitor 不可用，内部监控成为唯一发现手段；状态页也需要按产品粒度实时更新，而不是只给一个笼统的“服务异常”。
第五，恢复优先级要提前定义。实时数据和告警比历史数据更重要；被主动监控或展示的实时数据，又比其他实时数据更重要。没有这个排序，恢复团队会在错误的数据上消耗时间。
第六，云厂商的自动修复不总是优势。自动替换可以加快恢复，也可能抹掉有状态节点的本地数据；对有状态工作负载，重启与替换要有明确策略。
第七，演练要覆盖大规模降级。Datadog 计划把混沌测试扩展到本次故障的规模，验证“只剩紧急数据”时的降级运行能力，并重新审视 quorum 与 share-nothing 存储设计。
合上页面，先回答，再展开对照。
小程序版
微信扫码，随时查命令