小程序版
微信扫码，随时查命令
本文是公开报告的摘要与解读，事实以原始报告为准。
2019 年 6 月 2 日，Google Cloud 发生网络故障。官方状态页的详细报告《Google Cloud Networking Incident #19009》记载，事故起于 11:45（US/Pacific）在一个物理位置开始的维护事件：维护自动化把网络控制平面任务下发到了多个位置，使这些位置的网络控制平面集群同时被取消调度。11:47 至 11:49，用户侧影响开始；随后 BGP 路由在受影响位置之间被撤回，区域网络容量骤降。
报告把根因概括为“两个平时无害的配置错误加上一个具体软件 bug”：控制平面任务被配置为在维护时停止；多个集群管理实例被标记为可参与一种较少见的维护事件；维护软件又有 bug，允许它同时取消调度跨物理位置的多个独立集群。Google 的网络设计为在失去控制平面后“静态失败”一段时间，但只维持了数分钟，之后 BGP 路由被撤回。
报告对结束时间存在多个口径：状态页头部写 15:40 结束，技术正文写 16:10 全面恢复，16:56 的最终更新又说所有受影响用户在 16:00 已恢复；部分 VPN 网关直到 16:30 才恢复。另有包损数据从 11:38 开始，早于声明的 11:45。本文因此不合并出一个精确总时长。
以下时间均为 2019 年 6 月 2 日 US/Pacific，除非另注。
| 时间 | 事件 |
|---|---|
| 11:45 | 一个物理位置的维护事件开始；自动化把多个位置的网络控制平面集群取消调度 |
| 11:47–11:49 | 用户侧影响开始；BGP 路由撤回，受影响区域容量骤降 |
| 12:53 | Google 发布调查公告 |
| 13:01 | 定位根因，停止维护自动化 |
| 14:03 | 重建后的网络配置开始逐步下发 |
| 14:59 / 15:04 | 第一阶段缓解完成，第二阶段进行中 |
| 15:19 | 网络容量开始恢复 |
| 16:04 | 绝大多数用户恢复 |
| 16:10 | 技术正文称全面恢复 |
| 16:30 | us-west2、northamerica-northeast1、southamerica-east1 的 VPN 网关恢复 |
| 16:56 | 最终更新称所有受影响用户在 16:00 已恢复 |
| 6 月 6 日 09:42 | 详细报告发布 |
报告列出的核心受影响区域是 us-central1、us-east1、us-east4、us-west2、northamerica-northeast1 和 southamerica-east1；us-west1、欧洲和亚洲区域没有出现区域级网络拥塞。受影响服务包括 Compute Engine、App Engine、Cloud Endpoints、Cloud Interconnect、Cloud VPN、Cloud Console、Stackdriver Monitoring、Cloud Pub/Sub、BigQuery、区域 Cloud Spanner 和区域 Cloud Storage 桶，另有 G Suite 与 YouTube。
报告给出的具体数字显示影响并不均匀：us-east1 的 Compute Engine 在 11:38 至 12:17 经历最高 33% 丢包，12:17 至 14:50 仍最高 8%；Cloud Storage 在 us-west2、southamerica-east1、us-east4 和 northamerica-northeast1 的平均错误率分别为 96.2%、79.3%、62.4% 和 43.4%；Cloud Spanner 在 us-east4、us-west2 和 northamerica-northeast1 从 11:48 到 15:44 不可用。Google Cloud 官方博客另给出 YouTube 一小时观看量下降 2.5%、Cloud Storage 流量下降 30%、约 1% 活跃 Gmail 用户受影响等指标；这些不是状态页报告中的数字，引用时应区分来源。
报告没有给出统一的受影响客户数量。对用户而言，表现可能是实例不可达、控制台加载缓慢或失败、VPN 与 Interconnect 丢包、存储和消息服务错误率上升，以及依赖这些区域的跨区域应用超时。
第一层是维护自动化的爆炸半径失控。控制平面任务和支撑基础设施被配置为在维护事件中停止，这原本可能只是为单区域维护做准备；但多个集群管理实例同时被标记为可参与一种少见的维护事件，维护软件又没有把取消调度限制在单个集群或单个物理位置。
第二层是“静态失败”窗口不足。控制平面消失后，Google 的网络还能按既有状态运行数分钟，但之后 BGP 路由被撤回，区域间容量急剧下降，部分区域不可达。报告没有把事故归因于某条错误的 BGP 策略或外部攻击，而是强调控制平面被整体取消调度后，数据平面无法继续维持。
第三层是恢复困难。多个位置的控制平面实例都被取消调度，配置需要重建并重新分发，不能简单拉起进程；调试又受到同一场网络拥塞的影响。派工程师前往安全设施、降低非关键流量优先级等措施能恢复控制，但也拉长了时间。
工程师在故障出现约两分钟后收到告警并启动重大事故流程。13:01 停止维护自动化，随后重新启用网络控制平面、重建并分发配置，14:03 开始下发。服务团队同时把流量从受影响区域迁走。15:19 网络容量开始恢复，16:04 绝大多数用户恢复，技术正文称 16:10 全面恢复。
后续改进包括：在具备防止跨多个物理位置同时取消调度的保护前，保持维护自动化停用；加固集群管理软件，使其无论请求来自何处都拒绝这类操作；重新配置网络控制平面，拒绝本次涉及的维护请求；把控制平面配置持久化到本地，避免全部取消调度后还要重建，Google 预计可将恢复时间缩短一个数量级；延长“静态失败”的持续时间；审查并测试应急工具和客户沟通；把持续灾难恢复测试扩展到这类严重故障。
报告还提到 Cloud Endpoints 的配置推送在 6 月 2 日 12:00 至 6 月 4 日 11:30 之间有 50% 失败，恢复推送后生效时间最长约一小时。这说明“主故障恢复”不等于所有依赖服务的尾部问题都已结束。
第一，维护自动化必须把“物理位置”和“独立故障域”当作硬边界。一个集群管理实例被标记为可维护，不等于允许它连带其他位置的集群一起停机；并发取消调度需要租约、锁或全局安全检查，而不能只依赖调用方传参。
第二，配置持久化直接决定恢复上限。控制面实例全部消失后，如果配置只存在于内存或需要跨区域重建，恢复就会从“重启进程”退化为“重建系统”。把最后已知配置保存在本地，并定期验证可启动性，是控制平面的基本能力。
第三，fail-static 的窗口要覆盖现实中的修复时间。只能撑几分钟的静态失败，在多区域控制面故障面前几乎等于没有缓冲；窗口长度、降级行为和恢复触发条件都应被测量和演练。
第四，排障工具不能和故障共享同一条网络路径。报告明确提到拥塞拖慢了调试和恢复；应急工具、控制台、状态页和远程访问应有独立入口或离线备份。
第五，灾难恢复演练要覆盖组合故障。单区域、单集群演练无法暴露“多个平时无害的配置同时成立”的问题；应专门测试跨物理位置同时失去控制平面的场景，并核对复盘报告内部的时间口径。
合上页面，先回答，再展开对照。
小程序版
微信扫码，随时查命令