摘要

  • 8月19日11时10分起，DigitalOcean的MKC1区域发生严重级别事故，多个机架和节点受到影响，GPU、DOKS与集群管理能力在不同时段出现中断。
  • 19时34分，区域控制平面和多项通用服务已经正常，DigitalOcean随即关闭公开事故；同一则更新却仍说GPU Droplets受到影响，所有节点的恢复工作尚未结束。

在云服务状态页上，一个绿色结果可能只回答了一个范围明确的问题。DigitalOcean于8月19日关闭Kansas City MKC1事故时，回答的是区域控制平面和一组通用服务是否已经稳定；它并没有声称所有GPU工作负载都在同一时刻恢复。

事故于11时10分06秒（UTC）开始。DigitalOcean报告多个机架和节点出现问题，GPU工作负载可能中断，DigitalOcean Kubernetes（DOKS）的工作节点可能进入NotReady。该公司把整体影响定为严重级别。

12时22分，DigitalOcean说已经找到根因并开始采取修复措施，但没有公开根因的具体机制。这次更新列出的影响面更广：GPU工作负载和Serverless Inference可能受阻，DOKS工作节点可能持续NotReady，受影响集群的Kubernetes API端点和集群管理操作也可能无法使用。到15时28分，工程团队仍在恢复连接并让节点重新上线；公开信息没有给出机架、节点、集群或客户数量。

18时59分的更新划出了关键界线。DigitalOcean称区域控制平面已经完全健康，CPU Droplets、Managed Databases、Load Balancers、Block Storage和Spaces运行正常；Droplet创建、调整规格与其他管理操作已经可用；DOKS控制平面也可以访问。这意味着区域共用能力和管理入口确实取得了实质恢复。

但同一段状态说明紧接着写道：MKC1中的GPU Droplets仍处于离线或无法访问状态，DOKS的GPU工作节点可能继续显示NotReady，依赖GPU的推理端点也可能不可用。DigitalOcean计划短暂观察控制平面后关闭区域事故，后续改用Slack和电子邮件向GPU客户提供个性化更新。

19时34分54秒，公开状态变为resolved。最后一则更新再次确认控制平面、CPU Droplets与多项平台服务正常，同时也再次确认GPU Droplets仍受影响，团队还在恢复全部节点。因此，从开始到关闭的8小时24分48秒只是公开事故管理窗口，期间受影响的服务集合不断变化。它既不是所有服务持续中断的统一时长，也不是所有GPU客户的恢复时刻。

这条时间线还处在新区域投产的早期。DigitalOcean在8月4日上线MKC1，距离事故只有15天。发布公告称该数据中心采用全液冷，运行NVIDIA B300 GPU，并在启动时提供计算、DOKS、数据库、对象与块存储、网络、App Platform和Functions等广泛服务。现有证据没有把事故归因于液冷或B300，也不能据此断言新区域不成熟；可以确认的是，一项以GPU能力为重要卖点的新区域很快经历了第一次公开恢复考验。

DOKS的分层结构解释了为何控制平面健康并不等于工作负载健康。DigitalOcean负责托管Kubernetes控制平面，客户应用则运行在工作节点上。API恢复后，客户可以查看和管理集群，却不会因此自动获得仍位于NotReady节点上的GPU容量。DigitalOcean也提供自动工作节点修复功能，但文档把它列为需要主动配置的公开预览能力，触发条件、宽限时间、替换动作和并发预算都由规则控制。事故记录没有说明受影响客户启用了它，更没有说明它完成了本次恢复。

公开证据还缺少几个决定性答案。DigitalOcean虽然说根因已经确定，并提到与机房协作，却没有说明是电力、制冷、网络、硬件、软件还是其他机制。它也没有公布受影响客户数、全部GPU节点恢复的准确时间、是否存在数据丢失或工作负载完整性问题，以及防止复发的具体计划。事后组件显示为正常，不能反向补出这些缺失事实。

对云服务运营者而言，正确做法不是简单否定状态页，而是把状态拆成可验证的层级：控制平面能否访问、工作节点是否Ready、加速器能否分配、推理端点是否响应、应用自身是否达到服务目标。8月19日，这些信号没有同时恢复。DigitalOcean的时间线把差异写得很清楚：区域事故达到了公开关闭门槛，价值更高、替代性更低的GPU资源仍在另一条恢复队列中。

来源