摘要

  • DigitalOcean 于 8 月 8 日 18:57:49 UTC 建立故障记录，8 月 9 日 01:01:02 UTC 宣布完全恢复，公开生命周期为 6 小时 3 分 13 秒。
  • 官方称，多区域内的账户注册、Droplet 创建、Reserved IP 分配、自动备份与快照、自动扩缩容、DOKS、GenAI、Droplet 控制台和数据库集群创建受到影响。
  • 20:02:35 UTC，DigitalOcean 表示已识别根因，但没有公开根因内容；22:02:55 UTC 开始通报修复正在实施和滚动部署。
  • 00:31:29 UTC 进入监控，29 分 33 秒后结案。
  • 证据支持“资源配置与控制面故障”，不支持把它写成所有存量工作负载、数据、网络路径或 GenAI 请求全部中断。
  • 官方没有公布具体区域、客户数量或比例、错误率、积压处理、SLA 结果、补偿和永久整改措施。

真正被拿走的是“下一步”

云服务的价值不只在于机器此刻是否在线，也在于客户能否在需要时创建下一台机器。此次故障覆盖的动作，几乎都与“改变现状”有关：创建 Droplet、分配 Reserved IP、生成备份或快照、扩展实例池、操作 DOKS 集群、进入控制台，以及建立新的数据库集群。

这类故障未必立即让网站变黑。只要现有容量够用，表面服务可能继续运行；一旦流量上升、节点损坏、发布需要回滚，或者团队准备灾备资源，创建能力的缺失就会转化为真实停机风险。

DigitalOcean 没有说所有客户的每一次请求都失败，也没有给出分产品成功率。因此，既不能把事件缩写成“只是后台有点慢”，也不能扩大成“DigitalOcean 全部宕机”。可以确认的是，客户在多个产品上失去了部分扩容和恢复选择。

六小时不是一个状态，而是一条修复链

18:57:49 UTC 的首条通知提到新账户、Reserved IP、快照、Droplet 及其相关服务。19:38:23，官方扩大范围，加入 GenAI、Droplet 控制台和卡在“Creating”状态的数据库集群。

20:02:35，也就是首报后 1 小时 4 分 46 秒，DigitalOcean 称工程团队已识别根因。这里的“识别”只说明内部诊断有了方向，并没有公开是身份系统、队列、数据库、证书、网络还是发布变更导致故障。

22:02:55，官方说修复正在实施并滚动部署，同时明确此前的中断仍可能持续。直到 00:31:29，DigitalOcean 才表示相关错误应不再出现并进入监控。01:01:02 完全结案。识别、部署、监控和恢复代表四个不同风险阶段，不应被一个“resolved”标签抹平。

产品名单指向共同入口，但不能代替根因

官方组件历史把 Droplets Global、Kubernetes Global、Managed Databases Global 和 Reserved IP 标记为降级；文字更新又列出注册、备份、快照、自动扩缩容、GenAI 和控制台。计算、网络、编排、托管数据和 AI 服务同时出现，使“共同的资源配置或控制能力”成为合理的编辑判断。

但这仍然只是根据症状形成的判断，不是 DigitalOcean 公布的内部架构。官方没有说明哪个内部服务承担共同依赖，也没有发布根因细节。若直接点名某个控制面、认证系统或消息队列，就会把未知写成事实。

产品文档只能帮助解释客户侧关系。DOKS 是带托管控制面的 Kubernetes 服务，并与 Droplet、存储、API 等产品结合；Droplet API 覆盖创建、镜像、备份、快照和自动扩缩容池。它们说明客户为什么会把这些动作视为同一平台体验，却不能证明事故由文档中的某一组件引发。

创建失败与存量服务失败必须分开

官方反复使用的动词是创建、分配、扩缩、执行备份与快照、进入控制台。它没有说运行中的 Droplet 大面积关机，没有说已建立的网络流量全部中断，也没有说已存储数据丢失或现有数据库查询普遍失败。

保持这条边界不是替供应商淡化责任。自动扩缩容无法加节点，可能让当前健康的服务随后过载；数据库长期卡在创建状态，可能耽误恢复；控制台不可达，可能拿走小团队最熟悉的排障通道。这些都是具体的经营风险。

只是它们与数据面全面中断属于不同事件。客户复盘时，应先找出故障窗口内尝试过哪些变更，再核对每项操作的最终状态，而不是预设“什么都没发生”或“所有东西都停了”。

备份能力本身也依赖供应商

自动备份和快照从首条通知起就位于影响范围内。它们常被当作主业务之外的保险，但创建和记录这份保险仍需经过云平台控制面。

DigitalOcean 没有称已有备份被删除、损坏或无法读取；它说相关操作可能失败。客户需要分别回答三个问题：备份请求是否被接受，任务是否完成，生成的内容是否可恢复。故障页面恢复绿色，并不能替代对窗口内历史任务的核验。

官方也没有公布失败或延迟任务的数量，没有说明队列中的工作是否自动重放。最稳妥的做法是对照 API 日志、任务历史和实际库存，把每项操作归类为完成、失败、取消或仍待确认。

小团队最容易在恢复环节付出代价

大型云用户可能保留闲置容量、多云工具和专门值守团队。中小企业和开发者往往按需创建资源，把“随时可扩”当作备用容量。它们没有提前买下的第三台服务器，只有平台承诺在需要时创建第三台服务器。

当这个承诺暂时失效，成本会以等待、重试和人工核验的形式出现。更棘手的是，DigitalOcean 的故障未必是客户事故的起点，却可能阻止客户修复另一场事故：应用先出问题，团队随后发现无法创建替代节点或数据库。

目前没有客户数量、企业规模分布或财务损失数据，无法计算总成本。状态页上的“minor”是供应商分类，不是影响分母。DigitalOcean 也没有披露服务积分或 SLA 判定。

恢复服务不等于完成对账

最终更新称所有受影响服务已完全恢复，并建议仍有问题的客户提交支持工单。这关闭了公开故障周期，却没有解释六小时内每一笔请求去了哪里。

客户仍需要知道：明确失败的有多少，卡住的有多少，平台自动重试了多少，是否有重复创建，哪些操作需要人工处理。没有具体区域，跨区域架构也无法准确判断自己的暴露；没有根因和长期整改，则无法判断修复是否只消除了症状。

有价值的事后报告应把原因、影响半径、修复机制、请求对账和防复发措施分开说明。它不必泄露安全敏感细节，但必须让客户能够验证自己的“期望状态”是否与“实际状态”一致。

客户现在能做的是把窗口变成清单

复盘范围可以明确锁定为 18:57:49 至次日 01:01:02 UTC。需要检查的对象包括账户注册、Droplet 创建、Reserved IP 分配、自动扩缩容事件、DOKS 操作、备份与快照记录、控制台访问，以及数据库集群创建请求。

对 DigitalOcean 而言，下一步证据应包括具体区域、按操作划分的失败率、受影响客户分母、积压处置和永久修复。若未来再次出现相同产品组合，才会增强共同依赖反复失效的疑问；本次事件本身不能证明它与 8 月 6 日的写路径故障同因。

这次事件的核心并非“整朵云是否熄灭”，而是弹性基础设施的一项基本权利：客户必须能够改变容量。存量资源的冗余，如果依赖同一条不可用的创建路径来补位，只完成了连续性的一半。

来源