欢迎点击下方👇关注我，记得星标哟~
文末会有重磅福利赠送
在2024年12月11日，OpenAI的所有服务因新部署的遥测服务而经历了显著的停机时间，该服务意外地使Kubernetes控制平面超负荷，导致关键系统出现级联故障。问题在太平洋时间晚上7:38解决，API和ChatGPT在大约5:36 PM和5:45 PM开始恢复。
关键点
- 新的遥测服务部署意外地造成了大规模的Kubernetes API负载，压垮了控制平面并破坏了基于DNS的服务发现。
- 问题在测试期间未被发现，因为影响特定于较大的集群，DNS缓存延迟了问题的可见性。
- 整治过程面临挑战，因为Kubernetes控制平面不可用，阻止工程师移除有问题的服务。
- OpenAI正在实施措施以防止类似事件的发生，包括健全的分阶段发布、故障注入测试、紧急Kubernetes控制平面访问，以及将Kubernetes数据平面与控制平面解耦。
以下是原文翻译，一起来学习下故障复盘报告该怎么写吧！
https://status.openai.com/incidents/ctrsv3lwd797
API、ChatGPT和Sora面临的问题
OpenAI故障报告
Postmortem
介绍
这份报告详细介绍了2024年12月11日发生的一起故障事件，其中所有OpenAI服务都经历了严重的停机时间。该问题源于新的遥测服务部署，该部署无意中使Kubernetes控制平面不堪重负，导致关键系统之间出现级联故障。在本文中，我们分析了根本原因，概述了采取的补救措施，并分享了我们正在实施的措施，以防止将来发生类似事件。
事件影响
太平洋标准时间2024年12月11日下午3：16至晚上7：38期间，所有OpenAI服务都经历了严重降级或完全不可用。此事件是内部更改的结果，目的是在我们的队列中推出新的遥测数据，而不是由安全事件或最近的发布引起的。所有产品在下午3：16开始缓解。
- ChatGPT：太平洋标准时间下午5：45出现大幅恢复，太平洋标准时间晚上7：01完全恢复。
- API：下午 5：36发生了大量恢复，所有模型在太平洋标准时间晚上7：38进行了完全恢复。
- Sora：太平洋标准时间晚上7：01 完全恢复。
根因
OpenAI在全球运营着数百个Kubernetes集群。Kubernetes有一个负责集群管理的控制平面和一个数据平面，我们从中实际为模型推理等工作负载提供服务。
作为提高整个组织可靠性的一部分，我们一直在努力改进集群范围的可观测性工具，以增强对系统状态的可见性。太平洋标准时间下午3：12，我们部署了一个新的遥测服务来收集详细的Kubernetes控制平面指标。
遥测服务的占用空间非常广泛，因此这个新服务的配置无意中导致每个集群中的每个节点都执行资源密集型Kubernetes API操作，这些操作的成本随着集群的大小而变化。由于数千个节点同时执行这些操作，Kubernetes API服务器变得不堪重负，导致我们大多数大型集群中的Kubernetes控制平面瘫痪。这个问题在我们最大的集群中最为明显，因此我们的测试没有发现它——而DNS缓存使问题变得不那么明显，直到整个队列开始推出。
Kubernetes数据平面可以在很大程度上独立于控制平面运行，但DNS依赖于控制平面–如果没有Kubernetes控制平面，服务不知道如何相互联系。
简而言之，根本原因是新的遥测服务配置，该配置意外地在大型集群中生成了大量Kubernetes API负载，使控制平面不堪重负，并破坏了基于DNS的服务发现。
测试与部署
该更改在暂存集群中进行了测试，未观察到任何问题。影响特定于超过一定大小的集群，我们在每个节点上的DNS缓存将可见故障延迟了足够长的时间，以便继续推出。
在部署之前，我们主要关心的可靠性问题是新遥测服务的资源消耗。在部署之前，我们评估了所有集群中的资源利用率指标（CPU/内存），以确保部署不会中断正在运行的服务。虽然资源请求是按集群优化的，但没有采取任何预防措施来评估Kubernetes API服务器负载。此推出过程监控服务运行状况，但缺乏足够的集群运行状况监控协议。
Kubernetes数据平面（负责处理用户请求）设计为独立于控制平面运行。但是，DNS解析需要Kubernetes API服务器，这是我们许多服务的关键依赖项。
DNS缓存通过提供过时但功能正常的DNS记录暂时减轻了影响。但是，随着缓存记录在接下来的20分钟内过期，由于服务依赖于实时DNS解析，它们开始出现故障。这个时机很关键，因为它延迟了问题的可见性，允许在了解问题的全部范围之前继续推出。一旦DNS缓存为空，DNS服务器上的负载就会成倍增加，从而进一步增加控制平面的负载，并使即时缓解措施进一步复杂化。
修复
监控部署和恢复有问题的更改通常很简单，我们有工具来检测和回滚不良的部署。在这种情况下，我们的检测工具有效，并且在客户开始看到影响之前几分钟检测到问题。但解决此问题需要我们删除有问题的服务。为了进行该修复，我们需要访问Kubernetes控制平面——由于Kubernetes API服务器的负载增加，我们无法做到这一点。
我们在几分钟内就发现了问题，并立即启动了多个工作流，以探索不同的方法让我们的集群快速恢复在线：
一.缩减集群大小：减少了Kubernetes API的总负载。
二.阻止对Kubernetes管理API的网络访问：阻止新的昂贵请求，让API服务器有时间恢复。
三.扩展Kubernetes API服务器：增加可用资源来处理待处理请求，使我们能够应用修复程序。
通过同时处理这三项服务，我们最终恢复了足够的控制权，以删除有问题的服务。
一旦我们重新获得对某些Kubernetes控制平面的访问权限，我们就开始看到即时恢复。在可能的情况下，我们将流量转移到运行状况良好的集群，同时对其他集群进行修复。由于许多服务试图同时下载资源，因此一些集群仍处于降级状态，使资源限制达到饱和，需要额外的手动干预。
这是多个系统和流程同时失败并以意想不到的方式交互的汇合。即–
- 我们的测试没有捕捉到更改对Kubernetes控制平面的影响。
- DNS缓存在进行更改和服务开始失败之间增加了延迟。
- 由于锁定效果，修复非常缓慢。
时间线
- 2024年12月10日：新的遥测服务已部署到暂存集群，并验证其工作正常
- 2024年12月11日下午2：23：合并引入新服务的更改并触发部署管道
- 下午2：51 到下午3：20：更改已应用于所有集群
- 下午3：13：警报触发，通知工程师
- 下午3：16：开始对客户产生轻微影响
- 下午3：16：确定根本原因
- 下午3：27：工程师开始将流量从受影响的集群中移开
- 下午3：40：最大客户影响
- 下午4：36：恢复第一个集群
- 晚上7：38：恢复所有集群
预防
为防止类似事件发生，我们正在实施以下措施：
1.稳健的分阶段推出
我们将继续努力改进分阶段推出，更好地监控所有基础设施更改，以确保任何故障的影响有限并及早发现。所有与基础设施相关的配置更改都将遵循一个强大的分阶段推出流程，并改进持续监控，以确保服务工作负载和集群（包括Kubernetes控制平面）都正常运行。
2.故障注入测试
Kubernetes数据平面应该能够在没有控制平面的情况下存活更长时间，我们将运行明确执行此场景的测试。我们还将运行测试，有意识地推出不良更改，以确保我们的系统能够检测到并适当地回滚。
3.紧急Kubernetes控制平面访问
我们还没有一种机制来确保在数据平面对控制平面施加太大压力时访问API服务器。我们将实施break-glass机制，以确保工程师可以在任何情况下访问Kubernetes API服务器。
4.解耦Kubernetes数据平面和控制平面
我们依赖Kubernetes DNS进行服务发现，从而在Kubernetes数据平面和控制平面之间建立了链接。我们正在投资系统，将Kubernetes数据平面与控制平面分离，以便控制平面在处理任务关键型服务和产品工作负载时不会承担负载。
5.更快的恢复
我们将为集群启动所需的资源实施改进的缓存和动态速率限制器，并运行定期练习，以快速正确启动的明确目标快速替换整个集群。
结论
对于此事件对我们所有客户造成的影响，我们深表歉意——从ChatGPT用户到开发人员，再到依赖OpenAI产品的企业。我们没有达到自己的期望。我们认识到，为大家提供高度可靠的服务至关重要，因此将优先考虑上述预防措施，以继续提高可靠性。感谢您在此次中断期间的耐心等待。
知识星球年终发优惠券啦！感兴趣的读者千万不要错过这次优惠福利
福利一：《K8S容器基础培训》系列视频
福利二： K8S CKA考证资料分享
福利三：Azure考证资料大放送，包含AZ104,AZ305, AZ400等
更多云架构、K8S学习资料以及SRE学习手册，加入星球免费领取哦！
感兴趣的朋友们可以加我微信：sre_k8s，备注：云原生交流
