12月11日OpenAIChatGPT和Sora等服务出现长达4小时10分钟的宕机，此次宕机只是个小更改导致的，而且这个小更改仅在部署3分钟后就被发现出现问题，按理说这么快发现问题应该是很容易解决的。
不过OpenAI也出现了和某些公司相同的错误：服务挂了后把工程师也给锁门外了，即工程师无法正常连接控制面进行问题处理。
OpenAI采用的后端服务架构：
OpenAI的后端服务都运行在全球数百个Kubernetes集群中，其中有个负责集群管理的控制面和和数据面，OpenAI向用户提供服务的是K8S数据面。
接下来是事故大概情况：
12月11日太平洋标准时间下午3:12，工程师部署新的遥测服务来收集K8S控制面指标，由于遥测服务覆盖范围非常广，因此这个新服务配置无意中导致每个集群上的每个节点都执行资源密集型的K8SAPI操作。
由于数千个节点同时执行资源密集型的APi操作，导致API服务器不堪重负而宕机，这导致大多数集群中的K8S数据面瘫痪无法再提供服务。
K8S数据面很大程度上确实可以独立于控制面运行，但DNS依赖于控制面，如果没有K8S控制面，那么服务就不知道如何相互联系。
而不堪重负的API操作破坏了基于DNS的服务发现，也就是导致服务无法相互连接，那为什么3分钟就成功定位问题但要花费大量时间才能解决呢？
原因在于要回滚刚刚的遥测服务需要先到K8S控制面上把旧服务删除，但现在控制面已经挂了因此工程师们也无法成功连接，这就造成了死循环，这种死循环在其他公司的事故中也挺常见，没想到OpenAI也存在类似的问题。
最终的处理方式：
OpenAI工程师探索快速恢复集群的不同方法，包括缩小集群规模减少对K8S的API负载、阻止对用于管理的K8SAPI访问让服务器能够恢复、扩大K8SAPI服务器增加可用资源来处理请求。
最终这三项工作同时进行让工程师们重新获得控制权，也就是能够重新连接K8S控制面并删除有问题的服务，一旦重新连接就可以回滚遥测服务更改逐渐恢复集群。
期间工程师们还将流量转移到已经恢复的集群或新增的健康的集群中，这样继续降低其他问题集群的负载然后进行处理，但由于许多服务试图同时下载资源导致资源限制饱和和并需要额外的手动干预，因此一些集群花费了大量时间才完成恢复。
经过这次事故相信OpenAI应该能学到解决死循环问题，至少下次再发生类似情况是可以快速连接解决问题，而不是将工程师锁在门外。
viaOpenAIStatus
相关文章
头条焦点
精彩导读
关注我们
【查看完整讨论话题】 | 【用户登录】 | 【用户注册】