看了 OpenAI 刚发布的 11 号全球宕机 5 小时的“鞭尸”报告，非常典型的一次变更导致的宕机，正好碰到我熟悉的老本行了，简单解读一下

【背景】OpenAI 的后端服务运行在全球数百个 K8S 集群中，K8S 数据面（处理用户请求的）依靠 DNS 解析来做服务发现，这个 DNS 解析服务部署在 K8S 的控制面（管理集群的）。 OpenAI 为了提高整个集群的观测能力，打算部署一个新的观测服务来收集控制面的指标。

【事故过程】

• 10 号 OpenAI 在 staging 环境部署了一个新的观测服务，测试一切正常
• 11 号当天下午 3 点左右正式把这个服务部署上生产环境，3:13 服务报警，3:16 定位到原因：新的观测服务需要查询 K8S API，部署到控制面后，数千节点同时有大量 K8S API 的查询，导致 API Server 严重“超载”，搞垮了整个控制面。然而 K8S 数据面依赖 DNS 解析，此时的控制面的 DNS 解析服务已经受影响没有响应了，雪崩开始，控制面挂了慢慢导致所有数据面也挂了，全球宕机开始...
• OpenAI 的工程师只花了 3 分钟就定位到了原因，最直接的办法是回滚刚才的部署，但为啥这个事故拖了将近 5 个小时。很滑稽的原因，因为回滚前需要上控制面先把旧的服务删掉，但是现在控制面挂了所有人都上不去控制面，死循环（locked out effect).
• 最后通过缩减集群规模，限制各种请求，临时加资源的方式才让部分控制面能够访问，才一步一步恢复所有服务

【教训】

• 数据面依赖的核心服务竟然部署在控制面上，需要彻底解耦
• 需要有更健壮的阶段性部署流程
• 平时要有错误注入测试和演练
• 任何时候都要有紧急访问控制面的能力
• 其他的教训可以看原文： https://status.openai.com/incidents/ctrsv3lwd797

【感想】 在这个 AI hype 时代，大家往往容易忽略的是底层的 infra 在持续支撑当代互联网所有的在线服务，infra 虽然完全不被用户所感知，但是他在任何时刻都是至关重要，小小的一次变更能让数亿用户依赖的产品瞬间宕机，并且让这家企业损失惨重。所以 infra 远比大家想象中的难，这就是为什么 AWS DataDog 这样的企业这么赚钱的原因之一