服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 2026年10月20日的物理停电发生在 europe-west2-b；Google 报告称，转移的负载和跨可用区依赖也影响了 europe-west2 的其他服务，没有识别出区域之外的影响。
- 最终报告将客户影响窗口记为 10月19日 23:00 至 10月20日 05:08 US/Pacific，即 6小时08分，对应状态 feed 的 06:00 至 12:08 UTC；早期 6小时10分数字已被最终报告取代。
- API 重新可用、区域后台恢复接收流量、大多数工作负载恢复，是三个不同时间点；BigQuery、GKE、Cloud SQL、AlloyDB 和 Apigee X 另有各自的恢复记录。
- 11月5日修改的报告将部分设施整改标为完成，其他工作仍列预计日期；截至11月6日核对该报告，未获得后续完成确认。
为什么一个可用区的故障会影响整个区域？
这次事件不是只有 europe-west2-b 的资源受到影响。英国的一处数据中心设施承载该可用区；设施失电后，区域服务要处理转移来的查询、数据库高可用切换和计算工作负载。Google 的报告说，额外需求挤占邻区的计算槽位和处理能力，排队、数据库切换延迟以及间歇性 500 和 503 错误随之出现在 europe-west2 的更广范围。
报告把物理电力故障限定在 europe-west2-b，但也记录了未失电可用区和区域架构受到的影响，主要涉及瞬时需求增加与跨可用区的控制面依赖——也就是管理资源和调度任务的系统之间的依赖。Google 表示没有识别出 europe-west2 之外的影响。这一区别很重要：同一区域内出现错误，不等于所有相关设施都断了电。
双路电源与 UPS 为什么没有阻止断电？
设施原本有 A、B 两路独立市电，按 2N 架构为关键负载准备重复供电路径。但在事件前，B 路断路器因10月14日发电机负载测试发现问题而保持打开，等待维修；设施暂时处于由 A 路独自承载负载的 1N 维护状态。报告称，不间断电源（UPS）的电池可支撑关键负载约五分钟，为电压异常检测和发电机启动、同步与切换提供过渡时间。
10月19日 22:53 US/Pacific（即10月20日 05:53 UTC），公用事业网络的地下电缆故障切断了 A 路供电。可编程逻辑控制器（PLC）的电压传感输入位于馈线断路器上游，逻辑没有同时核对欠压与断路器位置。B 路虽已隔离、下游无电，上游仍带电；两套使用相同控制逻辑的 PLC 因此误以为健康电源仍在，没有给发电机组发送启动信号。UPS 储能耗尽后，数据大厅失去供电。双路设计和双控制器本身并不能抵消临时单路状态与共同的传感、逻辑缺陷。
状态 feed 的六小时窗口代表什么？
最终 incident report 记载，客户影响从10月19日 23:00 US/Pacific 开始，到10月20日 05:08 US/Pacific 达到大多数工作负载恢复；换算为 UTC 是10月20日 06:00 至12:08，共6小时08分。保存的状态 feed 条目也给出 06:00 至12:08 UTC。早期状态更新曾写 05:10 和6小时10分，后续最终报告改为05:08和6小时08分；应采用最终数字，不要把两个版本拼在一起。
报告还给出几个不同的恢复界点：04:11 US/Pacific，Google Cloud 服务与 API 对客户恢复可用，但仍有 Compute Engine 虚拟机不可用；04:29，区域服务和后台计算管理系统完全恢复接收流量，结束核心平台层面的中断；05:08，大多数工作负载恢复，Compute Engine 虚拟机有99.5%运行健康并可新建虚拟机。因此 feed 的 06:00 至12:08 UTC 是主影响记录的窗口，不是所有产品、磁盘或实例的统一故障时长。
哪些产品有自己的恢复尾差？
以下产品时间均按报告使用 US/Pacific（这些日期为 UTC−7）：23时的记录是10月19日，凌晨至白天的记录是10月20日。BigQuery 的区域服务中断从23:03到04:12，约5小时09分，期间有查询排队、任务延迟、作业 API 间歇性 503 和部分作业失败。
GKE 的报告给出23:02开始、05:22初步缓解、06:37最终解决，并把总时长记为7小时34分；这是报告注明的时长。europe-west2-b 的单可用区集群在23:05至04:30不可用，到06:00完全恢复。04:30是该产品章节的恢复界点；数据大厅电力已在更早的00:20恢复，不能将两者混为一谈。
Cloud SQL 的区域高可用实例会自动切换，但受 Regional Persistent Disk 问题影响的一部分恢复更晚：多数剩余实例在10月20日 01:00恢复，少量实例到11:00才全部恢复。AlloyDB 报告称，受影响实例超过99%在06:16健康，最后的 zonal primary 到08:28恢复。Apigee X 运行时的 HTTP 5xx 升高持续7小时19分；报告将其归因于三份数据存储副本中有两份位于失电区，导致失去维持运行所需的多数副本（quorum）。以上均是报告中的产品记录，不能据此推定其他实例的状态。
标记为可用，是否表示所有实例都已恢复？
在本次保存的 feed 中，该事件条目状态为 AVAILABLE，当前受影响地点列表为空。这说明的是状态条目当时的记录状态；报告本身仍描述了 VM、数据库、集群和 API 的不同恢复时间。区域公告关闭或 API 重新可用，不能单独证明某个项目、实例或磁盘已经回到正常状态。
报告记录 PLC 已于10月26日重新配置和验证。它把主电源 A 路修复预计完成日列为11月13日，把设施切回 A、B 两路并做配合测试列为11月17日；全面 PLC 代码审查则预计在11月6日完成，并要求早于发电机切换测试。以上仍是11月5日修改的报告所列状态。截至11月6日核对同一报告，未获得这些预计工作后续完成的确认，不能仅因日期到来就写成已完成。
排查自己的影响时，先对齐什么？
保留请求或作业发生时间及其时区，并记下产品、区域、可用区以及具体资源类型。把自己的错误时间与服务状态记录中的产品章节对照，而不只看总体 6小时08分标题或事件状态徽标；这次事件中，API 可用、平台恢复接收流量与具体产品恢复并不同步。
随后按平常的产品面板核对实例、磁盘、集群或数据库状态；若个别资源仍异常，带上这些时间点和资源标识走既有支持流程。事故复盘说明了已公开的设施和服务时间线，但没有判断每位客户的请求、数据或资源最终结果。
资料来源
常见问题
请求超时是否说明数据已经丢失，或可以直接重跑全部任务？
超时本身不能确定请求是否执行或数据是否丢失。先核对既有任务结果、资源状态和应用记录，识别尚未完成的操作；有写入或收费效果的请求，还应遵循原应用的重复执行防护规则。报告没有替每位客户判断具体请求结果。
这份复盘是否给出了 SLA 抵扣、补偿金额或申请截止日？
本文核对的事故报告没有提供这些具体条件。是否符合服务抵扣、适用金额和申请期限仍需按实际产品、合同及官方支持答复核实；不能由区域事故持续时间直接推定。