摘要
- DigitalOcean 在 7 月 19 日 14:52 UTC 将 Volume 挂载事故转入监测，称工程团队已识别根因并成功实施修复。
- 公司称
NYC1、NYC3、SGP1、SYD1和BLR1的 Volume 到 Droplet 挂载应可恢复，但没有公开根因内容。 - “监测中”不是“已解决”。客户仍需核对请求、最终挂载状态、设备、文件系统和应用，再恢复自动化或评估合同影响。
DigitalOcean 认为，阻止五地用户把网络块存储挂到 Droplet 的故障已经修复。运营信号发生了变化：客户现在可以重新尝试挂载。信息边界却没有闭合：供应商说自己知道根因，却没有告诉公众根因是什么。
14:52 UTC 的更新称，工程团队已识别根因、成功实施修复，用户不应再遇到错误。事故从调查转入监测，而不是关闭。受影响地点仍是纽约两地、新加坡、悉尼和班加罗尔。
恢复的是一项控制操作
DigitalOcean Volume 是网络附加块存储。Volume 与使用它的 Droplet 位于同一地区和项目，经过挂载与文件系统加载后才能服务应用。创建新机器、移动 Volume、扩容与灾难恢复都会经过这条控制路径。
本次事故没有证明已经挂载的存储全部停止读写，也没有证明数据丢失、所有 Droplet 失效或五座完整数据中心同时宕机。
但控制操作并非无关紧要。恢复站点可以拥有可用计算与正确快照，却因为无法把存储绑定到替代机器而停在最后一步。
一个 Volume 同时只能挂到一台 Droplet。移动数据因此需要明确的最终状态。Volume 也不包含在 Droplet 备份里；需要这类保护的客户必须单独维护 Volume 快照。
“已识别”不等于“已披露”
“已识别根因”关闭了供应商内部的问题，却没有回答客户的架构问题。
公开记录没有说明五地是否共享控制服务、发布版本、API 依赖或容量约束，也可能只是多个故障由同一团队统一处理。不能把五个地点写成五个独立故障，更不能据此断言全球控制面失效。
在不知道机制的情况下，客户无法判断多地区隔离是否绕过了出错依赖，也无法知道哪一种自动化路径会再次经过同一风险面。
托管云允许供应商保留实现细节，但代价是客户只能用实测验证恢复，并继续为未知的共同故障模式设计冗余。
状态页不能替代账户测试
客户应通过实际使用的控制入口验证：控制台、API 或 doctl。需要保存请求时间、资源标识、错误或成功结果、最终挂载状态、Droplet 能否看见设备、文件系统是否加载，以及应用是否读取了正确数据。
自动化重试前要先核对真实资源状态。对改变状态的操作盲目重复，可能在供应商修好原问题之后制造第二个问题。
挂载成功也只说明控制动作完成。它不能证明正确文件系统已经加载、应用完全恢复，也不能抹去延迟恢复产生的业务影响。
SLA 仍需要客户证据
DigitalOcean 的 Volume SLA 承诺每月 99.99% 可用性，但“不可用”按某项资源的全部请求连续失败超过五分钟定义。客户必须提出申请，DigitalOcean 再验证。
公开状态页没有提供账户级请求历史、各地起止时间或补偿结论，公告时间也不是每个客户的故障时间。
下一条真正有价值的信息，是 DigitalOcean 已经掌握却尚未公开的故障机制，以及监测在没有复发的情况下结束。现在可以确认修复已落地，不能确认架构教训已经公开。