欧洲西部地区2 出现了多种服务问题.
- resolved
** 概要** 在欧洲西部地区,多种服务正面临问题。 ** 说明** 从2026-10-19 23:08开始,我们正面临欧洲西部2 多种服务的问题。 我们的工程组继续调查这个问题。 我们将在2026-10-20 02:30之前提供最新资料,说明最新详情。 我们向所有受到干扰影响的人道歉。 ** 现象** 多个Google Cloud服务正在欧洲-西2区域出现高出错和间歇性网络故障. ** 工作** 暂时没有
- resolved
** 概要** 在欧洲西部地区,多种服务正面临问题。 ** 说明** 从2026-10-19 23:08开始,我们正面临欧洲西部2 多种服务的问题。 我们的工程组继续调查这个问题。 我们将在2026-10-20 04:00PDT 20:00之前提供最新资料,提供最新详情。 我们向所有受到干扰影响的人道歉。 ** 现象** 多个 Google Cloud 服务正面临更高的错误 欧洲西部2区间歇性网络故障. 注意: Looker Studio没有受到这次停电的影响. ** 工作** 如果可行,受影响的客户可能试图将其工作量转移到另一个可用的地点(地区或区域).
- resolved
** 概要** 在欧洲西部地区,多种服务正面临问题。 ** 说明** 从2026-10-19 23:08开始,我们正面临欧洲西部2 多种服务的问题。 我们的工程组继续调查这个问题。 我们将在2026-10-20:00PDT上介绍最新情况。 我们向所有受到干扰影响的人道歉。 ** 现象** 多个 Google Cloud 服务正面临更高的错误 欧洲西部2区间歇性网络故障. 注意: Looker Studio没有受到这次停电的影响. ** 工作** 如果可行,受影响的客户可能试图将其工作量转移到另一个可用的地点(地区或区域).
- resolved
** 概要** 在欧洲西部地区,多种服务正面临问题。 ** 说明** 从2026-10-19 23:08开始,我们正面临欧洲西部2 多种服务的问题。 由于一场电力事件,我们遭受了欧洲西部2-b区的停电。 电能事件得到缓解. 在今后30分钟内将观察到对基础设施服务的部分缓解,其余服务将在30分钟后在那里得到缓解。 我们将在2026-10-20:00PDT上介绍最新情况。 我们向所有受到干扰影响的人道歉。 ** 现象** Google Cloud服务在Europe-West2-b区不可用;在Europe-West2区的一些服务可能会遇到更高的错误和间歇性网络问题. ** 工作** 如果可行,受影响的客户可能试图将其工作量转移到另一个可用的地点(地区或区域).
- resolved
** 概要** 在欧洲西部地区,多种服务正面临问题。 ** 说明** 从2026-10-19 23:08开始,我们正面临欧洲西部2 多种服务的问题。 一次电力事件导致欧洲西部2-b区内部停电. 电能事件得到缓解. 我们看到服务正在恢复,并正在优先恢复现有工作量。 客户可能尚不能产生新的工作量。 现有工作量应初步在2026-10-20:00之前全部收回。 我们将在2026-10-20:00之前提供最新消息,说明最新详情。 我们向所有受到干扰影响的人道歉。 ** 现象** Google Cloud服务在Europe-West2-b区不可用;在Europe-West2区的一些服务可能会遇到更高的错误和间歇性网络问题. ** 工作** 如果可行,受影响的客户可能试图将其工作量转移到另一个可用的地点(地区或区域).
- resolved
** 概要** 在欧洲西部地区,多种服务正面临问题。 ** 说明** 我们看到,截至2026-10-20 05:10 PDT周二,西欧大部分工作量的服务正在恢复。 我们将在2026-10-20:00的星期二之前提供最新资料,说明最新详情。 我们向所有受到干扰影响的人道歉。 ** 现象** Google Cloud服务在Europe-West2-b区不可用;在Europe-West2区的一些服务可能会遇到更高的错误和间歇性网络问题. ** 工作** 如果可行,受影响的客户可能试图将其工作量转移到另一个可用的地点(地区或区域).
- resolved
** 概要** 欧洲西部地区2 出现了多种服务问题。 ** 说明** 受影响全球氯化石蜡产品的问题对于大多数客户来说已经缓解,据信它正在影响到目前极少数的客户,我们的工程队正在研究这个问题。 如果你有问题或受到影响,请与支助小组立案,我们将与你合作,直到这个问题得到解决。 这里将不提供进一步的最新资料。 一旦完成内部调查,我们将公布对这一事件的分析。 我们感谢你在努力解决问题时的耐心。 ** 现象** 欧洲-西2-b区无法提供谷歌云服务;欧洲-西2区的一些服务可能会出现更高的错误和间歇性网络问题。 ** 工作** 这个问题没有得到缓解.
- resolved
□ 初步事件报告 我们承认Google Cloud服务对于你的组织至关重要,我们诚恳地为这次事件可能对你的生意造成的干扰道歉. 我们正在努力解决根源问题,防止今后发生这种情况。 请注意,这一信息是根据我们公布时的最好知识提供的,随着我们调查的继续进行,可能会有所改变。 我们调查完成后,将公布一份包含预防行动的最后事件报告。 如果您在下文所列项目之外曾遇到过影响,请使用[**https\://cloud.google.com/ support**](https://cloud.google.com/ support)向Google Cloud Support联系。 □ 发行日期/时间 事件开始: 2026年10月19日 23:00 US/Pacific / 20 October 2026 07:00 BST 事件结束: 2026年10月20日 05:10 美国/太平洋 / 2026年10月20日 13:10 BST 会期:6小时10分 □ 总结 2026年10月19日(星期二,10月20日 BST)星期一,欧洲西部2区的多家Google Cloud平台服务经历了服务中断,出错率高,应用程序编程接口(API)超时,处理休息时间为6小时10分. 中断是由托管提供区欧洲-西2-b的数据中心设施的电力中断引发的,该设施暂时占用了实际主机服务器、网络路由硬件和储存系统。 这随后造成二次故障并排出未受影响的区域基础设施的延误。 □ 初步根源 事件发生时,位于欧洲西部2-b的数据中心设施发生电网中断。 为了在中断期间保持连续供电,立即启动自动转接设施备用电力系统. 在启动现场紧急柴油发电机序列期间,设施负荷被转移到不间断供电(UPS)电池库。 可编程逻辑控制器(PLC)自动化系统(主机和备用PLC)未能启动发电机的逻辑自动启动/转移操作,使备用发电机无法承担负载. UPS电池储备耗尽后,物理主机服务器,网络切换织物,以及专用于欧洲-西-B的本地存储阵列失去动力并下线. 导致影响客户的事件顺序如下: * 22:53美国/太平洋(10月20日,06:53 BST),位于提供区欧洲-西-b的数据中心设施发生电力中断,以及一个PLC(可编程逻辑控制器)启动故障,使设施紧急发电机无法承担电负载。 设施负荷继续由UPS电池库支持,直至电池耗尽,从美国/太平洋23:00(10月20日,07:00 BST)开始. * 当欧洲西2-b的物理主机服务器、本地存储基础设施和网络聚合硬件失去供电时,该区的事件、数据库复制件和工人节点立即无法接通。 * 区域交通线路机制和客户应用系统开始自动故障,导致本区域相邻可用区现有基础设施无法使用。 * 区域服务控制飞机向离线区元数据和编目部分发出的跨区远程程序电话出现超时,导致初始工作提交档和API延迟高峰。 * 重新定向的查询处决、高可用性数据库故障以及计算工作量,使其他可用区域可用的计算档和处理能力饱和,造成入学队列增加,数据库故障完成被推迟,整个区域间歇性500和503个API出错。 Google工程师已经开始进行全面的根源分析(RCA),一旦得到这些信息,将提供更多信息. □ 补救 Google工程师在10月19日(10月20日,07:08 BST)23:08通过自动监测系统和探测器发现中断, 工程小组立即动员起来,隔离受影响的基础设施并开始恢复: * ** 隔离:** Google工程师通过调整区域服务线路远离受影响的基础设施,将离线可用区(europe-west2-b)隔离出,防止跨区客户请求与离线端点对接. * ** 工作量调整和资源保障:** 工程师调整了未受影响的基础设施的排行器分配和容量限制,以优先安排积极的客户预留,减少执行时段的资源争议,并减少区域工作量排队积压。 * ** 电源网修复:** 现场设施工程师在公用事业供应恢复后,在1小时内,对稳定的公用事业供电进行优雅的恢复。 在此之后,他们集中并完成了重置并测试了应急备用发电机自动化控制器以恢复设施功率. * ** 逐步恢复基础设施:** 谷歌工程师系统重启了谷歌云核心基础设施和服务. * ** 控制下交通重新接纳:** 一旦系统健康和储存完整性得到核实,工程师将逐步、有控制的交通重新进入欧洲西区2-b,使累积的工作积压得以顺利清理。 至10月20日星期二05:10美国/太平洋(13:10 BST),绝大多数客户工作量恢复了服务可用性,地区Google Cloud平台服务的大部分客户的解决方案得到确认. 在回收了剩余孤立工作量的小尾巴后,事件关闭通知于07:03 US/Pacific(15:03 BST)发布. □ 影响描述 在2026年10月19日星期一至2026年10月20日星期二至2026年10月20日星期二至2026年10月20日05:00至05:00至05:00至10:10(13:10 BST)之间,欧洲-西2地区使用谷歌云平台服务的客户经历了连续两个阶段的服务中断,总持续时间为6小时10分. 在从23:00至04:29 US/Pacific(07:00至12:29 BST)(期限为5小时29分)的初始阶段,客户遭遇了较高的出错率,API超时,处理延迟,直到大多数Google Cloud平台服务恢复. 在平台服务恢复后,一些在计算引擎实例上运行的客户工作量经历了较长的恢复尾巴. 至04:46美国/太平洋(12:46 BST)恢复了新的虚拟机创建,至05:10美国/太平洋(13:10 BST)超过99%的计算引擎虚拟机处于健康状态. 其余遇到虚拟机器问题的任何客户都接到指示,按照正常程序提出客户支助问题。 虽然物理停电被严格隔离到西欧2-b的数据中心设施,但一些客户在未受影响的地区(西欧2-a和西欧2-c)或跨区域建筑运行工作量也受到出人意料的影响。 主要原因有1\)对未受影响的计算能力瞬间需求激增和2\)跨区界线同步控制-飞机验证依赖性. 受影响的产品包括: BigQuery, Looker, Google计算引擎, Google Kubernetes 引擎,区域持久磁盘,和 Cloud SQL. 这些服务出现了出乎意料的退化和故障问题,其驱动因素是突然计算能力因需求激增而耗尽,以及控制飞机API在离线区等待验证。 完全设在欧洲西部2-b范围内的工作量和资源变得无法达到。 Cloud SQL、AlloyDB、Redis的记忆库、Cloud Bigtable等数据存储服务, 跨欧洲西部2 区域的多区和区域服务经历了高纬度,瞬间API出错(如HTTP 500和503出错),任务接收排队,因为故障后流量集中在未受影响的区域资源上,跨区呼叫离线组件超时。 该区域的存储写作业务在最初的故障期间出现了瞬间出错率,区域查询录入队列暂时达到高峰后,随着容量的再平衡而迅速减少. 下列谷歌云平台服务受到了影响: * PostgreSQL 的合金DB * 爱奇艺 *大查询数据传输服务 * 云数据融合 * 云层文件 云火炉 * 云载平衡 * 云记忆店 * 云号NAT * 云奔腾 "云层" * 云工作站 * 数据流 * 对话框 CX * 谷歌应用引擎 * 谷歌大查询 * Google Cloud Bigtable (Google Cloud Bigtable) (Google Cloud Bigtable 互联网档案馆的存檔,存档日期2014-10-02.). * 谷歌云数据流 * 谷歌云数据程序 * Google Cloud NetApp 音量 * Google Cloud Pub/Sub (英语). * Google Cloud SQL (Google Cloud SQL) (英语). * 谷歌云存储(GCS) * Google 计算引擎(GCE) * Google Kubernetes 引擎(GKE) *Google SecOps(安全信息和事件管理\[SIEM\] 和安全管弦乐、自动化和反应\[SOAR\]) *取景者 (谷歌云核心) * 浏览器工作室 * 管理气流(谷歌云作曲) * Apache Kafka的管理服务 * 记忆存储器 * Redis 存储器 * Redis 集群存储器 * Valkey的存储器 * 网络连接中心 * 持久性磁盘 * 私人服务连接 * 发言文本 *虚拟私人云 * VMWARE引擎
- resolved
## Incident Report ### **Summary** On Monday, 19 Oct 2026 (Tuesday, 20 Oct BST), a data center facility that hosts europe-west2-b, experienced an external electrical power disruption. This resulted in service unavailability for workloads located in this zone. As traffic was redirected to alternative cloud regions or unaffected zones within europe-west2 cloud region, these workloads experienced transient latency and elevated errors affecting services across europe-west2. The primary impact was mitigated after 6 hours 8 minutes. ### **Root Cause** **Facility architecture and background:** The data center facility in the UK region hosts Cloud clusters serving the europe-west2-b zone, which form part of the multi-zonal europe-west2 Cloud region. The site relies on a 2N utility power architecture—meaning the facility has complete duplicate power paths for every critical load—backed by a central high-voltage generator bank managed by a dual-redundant Programmable Logic Controller (PLC). Primary utility power is supplied to the facility via two independent feeders (A and B), supplemented by a standby utility connection configured for manual campus-wide transfer during maintenance operations or emergency events. The two high-voltage primary feeders terminate at separate primary intake switchboards capable of closed-loop operation if either board is taken offline. Switching between the primary and standby utility providers utilizes open transitions and key interlocks to prevent parallel connections across sources. Static Uninterruptible Power Supply (UPS) battery systems provide 5 minutes of autonomous runtime. This bridge power ensures uninterrupted operation while the PLC detects utility undervoltage events, initiates diesel generator startup, synchronizes the generators, and transfers the site load. Prior to the utility disruption, the facility had been placed in a temporary single-feed (1N) bridged maintenance posture on the primary utility. Circuit breaker feeder B was physically opened and key-interlocked (Locked Out Tagged Out) to allow for corrective repairs following issues identified during a quarterly generator load test on 14 Oct 2026. Consequently, primary utility feed A was supporting the total critical load while repairs were conducted on the B feeder pathway. **Root Cause:** On Monday, 19 Oct 2026 at 22:53 US/Pacific (Tuesday, 20 Oct 06:53 BST), the primary utility provider experienced an outage on primary utility feed A, caused by an external underground cable fault on the utility network outside the data center facility. When the primary utility feed A was lost, the facility’s generator plant failed to receive a signal to automatically start and take critical load due to a design voltage-sensing and misconfiguration in the PLCs. The facility's static UPS battery banks carried the critical load as designed until their battery reserves depleted resulting in a complete power loss across data halls. The investigation of the PLC configuration identified the root cause as a misconfiguration of the PLC logic that did not verify both an undervoltage condition and physical breaker position for both utility feeders. Instead, the PLC undervoltage sensing inputs were wired upstream (line side) of the isolated utility feed B breaker. The PLC was programmed to verify whether voltage was present on the feeder before commanding a generator start. As the utility feed B remained energized upstream, both PLCs sensed live upstream voltage on the disconnected path. As a result, the PLC logic indicated that a healthy utility source was available, even though the primary and secondary distribution feeds were de-energized, and did not issue a start command to the generator plant.; The onsite facilities team attempted to execute a remote load transfer via the PLC; however, the system inhibited the action. Recognizing that the UPS battery reserves would be exhausted before further remote operations could be resolved, the team transferred the facility load to the standby utility source, restoring the critical load that was lost once batteries depleted during this process. Once utility power was restored via the standby utility source, and UPS batteries started recharging, the onsite facility teams and OEM vendors reconfigured and validated PLC functionality on both undervoltage and breaker status. After the power loss was initially detected, Google engineers began work to mitigate failover failures and prepare service recovery. Upon restoration of the utility source, UPS and generator capabilities, they began the process to re-enable services in europe-west2-b. ### Remediation and Prevention The sequence of events leading to customer impact was as follows: * **19 Oct 22:53 US/Pacific (20 Oct BST 06:53 BST) -** An electrical power disruption occurred at the data center facility hosting availability zone europe-west2-b, and a PLC (Programmable Logic Controller) startup fault prevented facility emergency generators from assuming the electrical load. Facility load continued to be supported by UPS battery banks until the batteries were depleted. * **19 Oct 23:00 US/Pacific (20 Oct 07:00 BST)** **Impact start -** As battery backups were exhausted, physical host servers, local storage infrastructure, and network aggregation hardware in availability zone europe-west2-b lost power, causing instances, database replicas, and worker nodes in that zone to become immediately unreachable. * **19 Oct 23:04 US/Pacific (20 Oct 07:04 BST) -** Google engineers were alerted to the disruption via automated monitoring systems and probers, which detected elevated API error ratios, job submission timeouts, and loss of infrastructure reachability in zone europe-west2-b. Engineering teams immediately mobilized to isolate the affected infrastructure and commence recovery. * **19 Oct 23:09 US/Pacific (20 Oct 07:09 BST) -** Regional traffic-routing mechanisms and client applications initiated automated failover toward available infrastructure in adjacent availability zones within the region. * Cross-zone remote procedure calls from regional service control planes directed to metadata and catalog components in the offline zone encountered timeouts, causing initial job submission stalls and API latency spikes. * The sudden influx of redirected query executions, high-availability database failovers, and compute workloads saturated available compute slots and processing capacity in other availability zones, creating elevated admission queues, delayed database failover completions, and intermittent 500 and 503 API errors across the region. * **Traffic Isolation:** Google engineers isolated the offline availability zone (europe-west2-b) by adjusting regional service routing away from the affected infrastructure, preventing cross-zone client requests from timing out against offline endpoints. * **Workload Reprioritization and Resource Safeguards:** Engineers adjusted scheduler allocations and capacity limits across unimpacted infrastructure to prioritize active customer reservations, reduce resource contention on execution slots, and relieve queue backlogs for regional workloads. * **19 Oct 23:54 US/Pacific (20 Oct 07:54 BST) Utility Power Restoration** **\-** Power supply from the standby utility source was restored and power restoration to the data hall began. * **20 Oct 00:20 US/Pacific (08:20 BST) Datahall Power Restoration** **\-** Utility power was re-established to the datahalls. Mains utility power normalized; power feed to data hall verified. Following this, the site operations and engineering teams focused on and completed a reset and tested the emergency backup generator automation controllers to restore facility power. * **20 Oct 00:40 US/Pacific (08:40 BST)** **\-** Clusters began to recover, cluster manager systems started rescheduling compute jobs. * **20 Oct 00:45 US/Pacific (08:45 BST) \-** Network devices were back online. * **20 Oct 00:50 US/Pacific (08:50 BST) \-** Due to the immediacy of power loss, storage devices with unclean shutdowns began recovery. Responders recognized this and chose not to restore services that would otherwise make this worse. Because of the large volume of storage devices involved, this process required a substantial period to finish prior to restoring service to customers. * **20 Oct 03:13 US/Pacific (11:06 BST)** **\-** Power redundancy was verified and the storage infrastructure was sufficiently restored to prepare the initiation of controlled traffic re-admission. The remaining storage systems continued recovery operations. * **20 Oct 03:45 US/Pacific (11:45 BST) Controlled Traffic Re-admission** **\-** Once system health and storage integrity were verified, engineers executed gradual, controlled traffic re-admission back to zone europe-west2-b allowing accumulated job backlogs to clear smoothly. * **20 Oct 04:11 US/Pacific (12:11 BST)** **\-** Google Cloud Platform services and APIs were made fully available to customers. Some Google Compute Engine virtual machines were still not yet available. * **20 Oct 04:29 US/Pacific (12:29 BST) \-** Regional services and backend compute management systems were fully undrained, marking the end of core platform-level disruption. * **20 Oct 05:08 US/Pacific (13:08 BST) Majority Workload Recovery** **\-** GCE virtual machines were 99.5% operational and healthy, and creating new VMs was fully supported. Service availability was restored for most customer workloads, with resolution confirmed for the majority of users across Google Cloud Platform services in the region. Following the recovery of a small tail of remaining isolated workloads, the closure notification for the incident was posted by 07:03 US/Pacific (15:03 BST). Google is committed to preventing a repeat of this issue in the future and is completing the following actions: **Data Center Action Items:** * Restoration of normal utility configuration (both A & B feeds) * Utility provider to locate the damaged cable fault, using low-frequency radar penetration testing procedures. **\[Completed 26 Oct\]** * Utility provider to send on-site engineers to repair the cable fault and restore the impacted primary utility feed A source. **\[Estimated Completion Date 30 Oct\]** * Onsite Operations teams with a controlled method of procedure (MOP) to transfer the facility to its primary utility source (feeds A and B) from standby utility feed through coordinated switching with the utility provider **\[Estimated Completion Date 31 Oct\]** * Generator confidence testing * Full generator load transfer tests with utility power cutover of the active utility feed. Test automatic startup of generators through PLC signals within the backup battery timer and detailed review of backup procedures **\[Completed on 20 Oct and 26 Oct (full critical load transfer test including updated EOPs)\]** * Full generator load transfer tests in coordination with the primary utility source feeds (A and B) after restoration work completed by the primary utility provider. **\[Estimated Completion Date 31 Oct\]** * PLC configuration fix * Reconfigured and validated the PLC after the outage on 20 Oct and then again on 26 Oct **\[Completed 26 Oct\]** * Google engineers to work in collaboration with the facility vendor teams to perform a comprehensive PLC code review and system resiliency to multiple failure scenarios. **\[Estimated Completion Date (prior to generator transfer test) estimated 31 Oct\]** * Validate PLC telemetry once primary utility feed A and B lineup is restored. **\[Estimated Completion Date 31 Oct\]** * Validate global PLC configurations at all global sites with similar topologies and PLC manufacturers, to ensure confidence in automatic generator starts. **\[Estimated Completion Date 15 Nov\]** * Emergency Operating Procedures (EOP) documentation update: * Comprehensive update to the EOP for site’s response to unexpected loss of active utility source. Update includes \- manual steps to attempt to restore active utility feed, manual restart of generators and manual transfer to other utility sources within the UPS battery run time. **\[Completed 26 Oct\]** * Ensure updated EOP is practiced twice per shift by on-site facility team. **\[Completed 24 Oct and checked with Google DC Operations daily\]** * Strengthen change management: * Freeze planned maintenance activities at other sites with similar topologies, and implement elevated approvals and reviews for data center configuration changes which are outside their standard designs. **\[Estimated Completion Date 30 Oct\]** **Cloud Service Action Items:** * **Communications Enhancement:** Bolster notification speed by developing an automated alert-to-communication mechanism for location-impacting incidents. * **Platform Testing:** Expand platform-wide testing outcomes for infrastructure-level events. ### **Detailed Description of Impact** Between Monday, 19 Oct 2026, 23:00 US/Pacific (Tuesday, 20 Oct 2026, 07:00 BST) and Tuesday, 20 Oct 2026, 05:08 US/Pacific (13:08 BST), customers utilizing Google Cloud Platform services in the europe-west2 region experienced service disruptions across two consecutive phases, lasting a total duration of 6 hours, 08 minutes. During the initial phase from 23:00 to 04:29 US/Pacific (07:00 to 12:29 BST) (duration 5 hours, 29 minutes), customers experienced unavailability of zone-scoped resources in products, including: * **Compute Engine** \- VM instances, zonal MIGs, unmanaged instance groups, zonal NEGs, sole-tenant node groups, zonal reservations, target instances, zonal API operations. * **Persistent Disk / Hyperdisk** \- Zonal PD, zonal Hyperdisk, Hyperdisk storage pools, instant snapshots. * **GKE \-** Zonal clusters (control plane), node pool nodes in \-b, PVs on zonal disks. * **Cloud SQL \-** Non-HA instances, read replicas in \-b. * **AlloyDB \-** Basic (non-HA) primaries in \-b. * **Bigtable \-** Single-cluster instances in \-b. * **Other products with affected zonal resources:** Cloud Batch, Cloud Build, Cloud Storage, Cloud Workstations, Composer, Dataproc, Filestore, Managed Lustre, Migrate to VMs, NetApp Volumes, Pub/Sub Lite, Vertex AI Workbench, VMware Engine. The unavailability of those resources scoped to a zone that undergoes disruption is working within the design of a zonally-scoped system. Requests made to these resulted either in a timeout or error code during the disruption. Any workloads and resources hosted entirely within europe-west2-b became unreachable due to this event. Google Compute Engine's zonal resources such as VMs require customers to provision failover or cross-zone recovery resources if needed, and to set up a recovery mechanism that matches their needs. Some failovers were unsuccessful due to capacity constraints and difficulty in replicating the underlying storage mechanism. Following platform service restoration, some customer workloads running on Compute Engine instances as well as products that rely on Compute Engine experienced a longer recovery. By 04:46 US/Pacific (12:46 BST) new Virtual Machine creation resumed and by 05:08 US/Pacific (13:08 BST) over 99% of Compute Engine Virtual Machines were in a healthy state. Any remaining customers that were experiencing Virtual Machine problems were directed to file a customer support case as per normal procedure. While the physical power outage was isolated strictly to data center facilities in zone europe-west2-b, some customers running workloads in unimpacted zones (europe-west2-a and europe-west2-c) or across regional architectures also experienced unexpected impact. The primary causes of impact outside of zone europe-west2-b were: 1\) Instantaneous demand surges on neighboring zones (a and c) and 2\) Control-plane dependencies across zonal boundaries Affected products included: AlloyDB, Apigee Infra and Apigee Edge, BigQuery, Cloud Dataflow, Cloud Pub/Sub, Cloud SQL, Google Compute Engine, Google Kubernetes Engine, Looker, Regional Persistent Disk, Vertex AI Prediction, and Cloud Speech-to-Text. These services experienced unexpected degradation and failover issues driven by sudden compute capacity exhaustion from surging demand, and control-plane API timeouts. Customers would have experienced the inability to create, update, or delete some regional resources during this period. This was not a full regional control-plane outage, but certainly a degraded state. Multi-zonal and regional services that spanned across the europe-west2 region experienced elevated latency, transient API errors (such as HTTP 500 and 503 errors), and task admission queuing as failover traffic concentrated onto unimpacted regional resources and cross-zone calls to offline components timed out. Storage write operations in the region experienced a transient error rate during the initial failover period, and regional query admission queues temporarily peaked before rapidly subsiding as capacity re-balanced. We did not identify any impact of the outage outside of the europe-west2 region. The following Google Cloud Platform services experienced impact within europe-west2: * AlloyDB for PostgreSQL * Apigee * BigQuery Data Transfer Service * Cloud Data Fusion * Cloud Filestore * Cloud Firestore * Cloud Load Balancing * Cloud Memorystore * Cloud NAT * Cloud Run * Cloud Spanner * Cloud Workstations * Datastream * Dialogflow CX * Google App Engine * Google BigQuery * Google Cloud Bigtable * Google Cloud Dataflow * Google Cloud Dataproc * Google Cloud NetApp Volumes * Google Cloud Pub/Sub * Google Cloud SQL * Google Cloud Storage (GCS) * Google Compute Engine (GCE) * Google Kubernetes Engine (GKE) * Google SecOps (Security Information and Event Management \[SIEM\] and Security Orchestration, Automation, and Response \[SOAR\]) * Looker (Google Cloud core) * Looker Studio * Managed Airflow (Google Cloud Composer) * Managed Service for Apache Kafka * Memorystore for Memcached * Memorystore for Redis * Memorystore for Redis Cluster * Memorystore for Valkey * Network Connectivity Center * Persistent Disk * Private Service Connect * Speech-to-Text * Virtual Private Cloud (VPC) * VMWare engine ----------
自动翻译自官方事件更新。