摘要

  • Cloud Storage 在 10 月 8 日和 9 日发生的两次事件合计持续 18 小时 11 分钟，范围涉及 us-central1 区域及 us-central1-b 可用区；公开症状主要集中在写入。
  • Google 把首起事件归因于绕过容量感知逻辑的路由优化，把次日复发归因于不完整回滚；公开报告没有列出受影响客户或量化损失。

谈到云存储中断，人们常先问数据副本存放在哪里。Google 的事故记录提出了另一个问题：一次写入请求在成为存储对象之前，究竟经过什么路径？10 月 8 日，使用 us-central1 的 Cloud Storage 客户遇到写入延迟上升和错误增加，持续 12 小时 30 分钟。次日，同一问题在 us-central1-b 可用区复发，持续 5 小时 41 分钟。Google 给出的合计时长是 18 小时 11 分钟；但这是两段故障，中间有恢复，不应写成连续 18 小时停摆。

公开症状也有明确边界。Google 称客户主要在 WriteObject 操作中收到 HTTP 503 UNAVAILABLE，并遇到客户端超时；成功完成的写入也明显变慢。最终报告说，其他 Cloud Storage 区域和其他 Google Cloud 服务未受这起特定事件影响。较早的初步报告提到读取有轻微影响，最终影响摘要却没有量化读取情况。因此，能够确认的是某个区域的写入路径出现局部问题，复发时范围又落在一个可用区。记录不能证明该区域的所有客户都受影响、所有写入都失败，或已存储对象发生丢失。

Google 将 10 月 8 日的触发点描述为一次流量排序配置更新，原意是缓解局部容量限制。这项优化绕开了通常会考虑容量的路由逻辑。于是，一小部分可用处理能力不足的后端节点承接了不成比例的写入流量。节点资源耗尽后，对象接入服务开始超时，发往这些节点的请求就变慢或失败。首段故障期间，另一个数据库问题还造成了部分元数据处理错误。事故因果不是单一组件坏掉：流量分配改变请求去向，工作负载随之集中，同时元数据路径又出现并行问题。

次日复发，是运行记录中更值得管理层关注的部分。Google 将其归因于上传规划功能的回滚不完整；该状态破坏负载均衡，并使较小的存储后端节点过载。换言之，首次缓解没有彻底恢复先前的安全状态。这并不意味着回滚普遍不可靠，也不能据此说整座区域又发生了更大范围故障。它说明事故“看似结束”与配置“确已恢复”是两种判断：服务恢复后，残余变更仍可能保留同一故障入口。

恢复措施也揭示出一个实际约束。Google 首先尝试给区域动态增加应急容量，但称区域容量上限阻止了这一方案。工程团队随后从最过载的节点排出流量、禁用或撤销优化，回退另一项数据库更新并重定向流量。待流量与资源利用率稳定后，被排空的节点才重新投入服务。容量并非总能作为紧急出口；当区域不能即时扩容时，路由、流量隔离和准确回滚可能才是手边的控制手段。

Cloud Storage 的公开架构文档有助于界定这次事故，但不能替代事故证据。Google 说明，区域型存储桶会在所选区域内至少两个可用区保存冗余数据。双区域和多区域存储桶则在首次写入已存至一个区域的两个可用区后，再异步跨区域复制。Google 称这些更广域配置可在区域故障时自动从其他区域提供服务，同时明确复制是异步的。其一致性文档还说，成功写入的对象会立即可读。这些承诺涉及副本、故障切换和确认语义，却没有说明本次客户实际用了哪类存储桶。

这个区别不应被抹平。事故报告没有说多区域复制失败、数据丢失或地理副本不可用；它描述的是接收新写入请求的路径出现瓶颈。地理冗余可以降低单一地点故障的影响，但架构仍需处理写入服务共享的软件和容量控制。存储韧性并非单一指标：副本持久性、写入接收、元数据处理、读取访问和应用恢复各有不同依赖。

Google 宣布的预防措施沿着这条链路展开：先在较小区域验证负载均衡变化，再部署到规模更大、利用率更高的区域；严格执行路由容量约束，防止流量逻辑绕过预先扩容保护；改善高利用率存储单元内部的数据迁移。这些是 Google 报告的未来行动，并非已由外部验证完成的控制。公开记录没有给出测试结果、受影响请求数、客户名单、存储桶地域分布或量化损失。可得出的结论更有限也更有用：一次路由优化和一次回滚缺陷，两次突破了局部容量保护；至于地理冗余是否适用于受影响工作负载，是另一个尚未由记录回答的问题。

来源：Google 最终事故报告、Cloud Storage 可用性与持久性、存储桶位置、一致性模型, 重试策略。