一个监控服务的部署，让OpenAI的全球服务瘫痪了！
这次事故的根本原因终于水落石出：一个用于收集Kubernetes指标的监控服务成了”罪魁祸首”。
事故的导火索
太平洋标准时间下午3:12，OpenAI部署了一个新的遥测服务，目的是为了提升集群级可观测性。
这本是一个提高系统可靠性的举措，谁知却引发了一连串的连锁反应：
-
监控服务定期从所有节点收集指标
-
这些指标采集操作触发了资源密集型的Kubernetes操作
-
控制平面因此崩溃
-
DNS服务随之失效
-
最终导致服务完全不可用
TDM (e/λ)(@cto_junior) 对此事件进行了专业解读：
我理解OpenAI的困境，Prometheus指标导出器的部署有时确实很棘手。简单来说，他们部署了一个指标服务，这个服务会定期从所有节点轮询指标。其中一些指标调用了资源密集型的k8s操作，导致控制平面崩溃，进而影响DNS正常工作，最终导致服务不可用。
专家观点
Loki(@chillgates_) 则从技术角度提出了一个有趣的观点：
最可能是忘记为指标命名空间设置资源请求/限制这样的小问题。k8s API本身具有足够的容错性和分布式特性，无论用户空间的需求如何，它都不太可能失败。
这提醒我们：在云原生架构中，即使是最基础的配置疏忽也可能引发灾难性后果。
深层思考
这次事故揭示了现代云服务架构的一个重要特点：看似简单的监控部署，也可能成为系统稳定性的重大威胁。
OpenAI在全球范围内运营着数百个Kubernetes集群，这些集群分为：
-
控制平面：负责集群管理
-
数据平面：提供实际工作负载（如模型推理）
在追求更好的可观测性时，我们需要在监控的全面性和系统的稳定性之间找到平衡点。
这次事故也给所有运营大规模分布式系统的团队敲响了警钟：
再小的变更也要谨慎对待，监控系统本身也需要被监控。
不过，从这也可以看出：
OpenAI 内部应该还没实现AGI。
（文：AGI Hunt）