複数のサービスは、ヨーロッパ西部2地域で問題が発生していました.
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生しています。 **記述** 2026-10-19 23:08 PDTの月曜日から始まるEURPE-west2での複数のサービスの問題が発生しています。 当社のエンジニアリングチームは、問題を調査し続けています。 弊社では、火曜日、2026-10-20 02:30 PDT のアップデートを最新の内容でご提供いたします。 被災された皆様、お詫び申し上げます。 **症状** 複数のGoogleクラウドサービスは、欧州の2地域におけるエラーと断続的なネットワーク障害を経験しています。 **ワークアラウンド** 只今
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生しています。 **記述** 2026-10-19 23:08 PDTの月曜日から始まるEURPE-west2での複数のサービスの問題が発生しています。 当社のエンジニアリングチームは、問題を調査し続けています。 2026-10-20 04:00 PDT のアップデートは、現在の詳細にて行います。 被災された皆様、お詫び申し上げます。 **症状** 複数のGoogleクラウドサービスは、エラーが高まっています。 europe-west2地域における断続的なネットワーク障害。 注意:Looker Studioは、この停電の影響を受けません。 **ワークアラウンド** 可能であれば、インパクトのある顧客は、別の利用可能な場所(ゾーンまたは地域)に影響されたワークロードを移行しようとするかもしれません.
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生しています。 **記述** 2026-10-19 23:08 PDTの月曜日から始まるEURPE-west2での複数のサービスの問題が発生しています。 当社のエンジニアリングチームは、問題を調査し続けています。 弊社では、火曜日、2026-10-20 05:00 PDT のアップデートを最新の内容でお届けいたします。 被災された皆様、お詫び申し上げます。 **症状** 複数のGoogleクラウドサービスは、エラーが高まっています。 europe-west2地域における断続的なネットワーク障害。 注意:Looker Studioは、この停電の影響を受けません。 **ワークアラウンド** 可能であれば、インパクトのある顧客は、別の利用可能な場所(ゾーンまたは地域)に影響されたワークロードを移行しようとするかもしれません.
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生しています。 **記述** 2026-10-19 23:08 PDTの月曜日から始まるEURPE-west2での複数のサービスの問題が発生しています。 パワーイベントのせいで、ヨーロッパ西2-b圏内の停電に遭遇しました。 パワーイベントが緩和されます。 インフラサービスの部分的な緩和は、次の30分以内に観察され、残りのサービスはその後緩和されます。 弊社では、火曜日、2026-10-20 05:00 PDT のアップデートを最新の内容でお届けいたします。 被災された皆様、お詫び申し上げます。 **症状** Google Cloud サービスは、ヨーロッパ西2-b ゾーンで利用できません。EURPE-west2 地域の一部サービスは、高いエラーと断続的なネットワークの問題が発生する可能性があります。 **ワークアラウンド** 可能であれば、インパクトのある顧客は、別の利用可能な場所(ゾーンまたは地域)に影響されたワークロードを移行しようとするかもしれません.
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生しています。 **記述** 2026-10-19 23:08 PDTの月曜日から始まるEURPE-west2での複数のサービスの問題が発生しています。 europe-west2-b ゾーン内の停電が発生しました。 パワーイベントが緩和されます。 私たちはサービスの回復を見て、既存のワークロードの回復を優先しています。 新規のワークロードをまだ作成できません。 既存のワークロードの完全な回復は、火曜日、2026-10-20 06:00までに暫定的に完了する必要があります。 火曜日、2026-10-20 06:00 PDT による更新を現在の詳細に提供します。 被災された皆様、お詫び申し上げます。 **症状** Google Cloud サービスは、ヨーロッパ西2-b ゾーンで利用できません。EURPE-west2 地域の一部サービスは、高いエラーと断続的なネットワークの問題が発生する可能性があります。 **ワークアラウンド** 可能であれば、インパクトのある顧客は、別の利用可能な場所(ゾーンまたは地域)に影響されたワークロードを移行しようとするかもしれません.
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生しています。 **記述** 火曜日、2026-10-20 05:10 PDT のヨーロッパの最もワークロードのためのサービスの回復を見ています。 弊社では、火曜日、2026-10-20 07:00 PDT のアップデートを随時更新いたします。 被災された皆様、お詫び申し上げます。 **症状** Google Cloud サービスは、ヨーロッパ西2-b ゾーンで利用できません。EURPE-west2 地域の一部サービスは、高いエラーと断続的なネットワークの問題が発生する可能性があります。 **ワークアラウンド** 可能であれば、インパクトのある顧客は、別の利用可能な場所(ゾーンまたは地域)に影響されたワークロードを移行しようとするかもしれません.
- resolved
**概要** 複数のサービスは、ヨーロッパ西部2地域で問題が発生していました。 **記述** GCP製品に影響を受けた問題は、ほとんどの顧客にとって緩和されてきました。現在、非常に少数の顧客と当社のエンジニアリングチームに影響を及ぼしていると考えられています。 ご質問や影響が生じた場合は、サポートチームにてお申し付けください。この問題が解決されるまでお任せください。 詳しくはこちらをご覧ください。 社内調査が完了したら、この事件の分析を公開します。 問題の解決に取り組んでいる間、あなたの忍耐に感謝します。 **症状** Google Cloud サービスは europe-west2-b ゾーンで利用できませんでした。 欧州地域における一部のサービスは、エラーや断続的なネットワークの問題が発生する可能性があります。 **ワークアラウンド** 問題が緩和されたとはいえません.
- resolved
**予備事件報告** 当社は、Google Cloudサービスがお客様の組織に重大な影響を及ぼすと認識し、本件事故がお客様の事業に及ぼす可能性があることをお詫び申し上げます。 根本原因に対処し、これから起こることを防ぎます。 なお、この情報は投稿時に最高の知識に基づいており、調査が継続して変更される場合があります。 調査が完了すると、予防措置による最終事件報告が掲載されます。 以下に記載されたもの以外に影響を受けた場合、https://cloud.google.com/support を使用して Google Cloud サポートにご連絡ください。 **発行日/時刻(米国/太平洋時間)** 開始:10月19日 2026 23:00 事件終了:20 10月2026 05:10 所要時間:6時間10分 **概要** 2026年10月19日(月)、ヨーロッパ西2地域における複数のGoogleクラウドプラットフォームサービスは、サービスの中断、エラー率の上昇、アプリケーションプログラミングインターフェイス(API)のタイムアウト、6時間と10分の遅延の処理を経験しました。 中断は、データセンター施設で電力の中断によってトリガーされ、一時的に物理的なホストサーバー、ネットワークルーティングハードウェア、およびストレージシステムをオフラインで取った可用性ゾーンEURPE-west2-bをホスティングしました。 これにより、二次的障害が発生し、不当な地域のインフラを横断する遅延をキューイングしました。 **予備ルート原因** データセンター施設で電力網の破壊が発生したときに発生した事故は、可用性ゾーンEURPE-west2-bをホスティングしていた。 破壊時の連続電力を維持するために、施設のバックアップ電源システムへの自動転送がすぐにトリガーされました。 設備の負荷はオンサイトの緊急のディーゼル発電機の開始順序の間に無停電電源装置(UPS)電池銀行に移されました。 プログラマブル・ロジック・コントローラー(PLC)の自動化システム(第一次およびバックアップPLC)は、バックアップ・ジェネレーターが負荷を想定しないように、発電機の論理自動始動/搬送操作を開始できなかった。 UPS 電池の予備が、物理的なホスト サーバー、ネットワークの切換えの生地および europe-west2-b の失われた力に捧げられたローカル貯蔵の配列がオフラインで行なわれたとき。 顧客のインパクトにつながるイベントのシーケンスは以下の通りです。 - 22:53 アメリカ/太平洋では、データセンター施設で電力の崩壊が発生し、可用性ゾーンのヨーロッパ-西2-b、PLC(プログラム可能な論理コントローラ)の起動障害が発生し、電気負荷を想定した施設の緊急発生器を防止しました。 バッテリーが枯渇するまで、UPSのバッテリーバンクによって、施設の負荷は米国/太平洋23:00から始まります。 - 物理ホストサーバー、ローカルストレージインフラ、およびネットワーク集計ハードウェアが、EURPE-west2-b の失われた電力の場合、インスタンス、データベースのレプリカ、およびそのゾーンのワーカーノードが即座に到達不能になるようにしました。 - 地域のトラフィックルーティング機構とクライアントアプリケーションは、地域内の隣接する可用性ゾーンで利用可能なインフラに向けた自動フェイルオーバーを開始しました。 - オフラインゾーンのメタデータとカタログコンポーネントに向けた地域サービス制御平面からのクロスゾーンリモート手順呼び出しは、初期のジョブ投稿が停止し、APIレイテンシーのスパイクを引き起こします。 - リダイレクトされたクエリ実行、高可用性データベースのフェイルオーバー、およびコンピュートワークロードの突然のインフルエンザは、利用可能なコンピュートスロットと処理能力を他の可用性ゾーンで飽和させ、高額な入学キューを作成、遅延されたデータベースのフェイルオーバー完了、および領域全体で500と503 APIエラーを断続的に作成します。 Google のエンジニアは完全な根本的な原因の分析(RCA)を始め、利用できると付加的な情報を提供します。 **是正** Googleのエンジニアは、自動化された監視システムとプローブを経由して混乱に警告しました 23:08 月曜日に米国/太平洋, 19 10 月 2026, 上昇した API のエラー比率を検出しました, ジョブの送信タイムアウト, ユーロ/西2-b のインフラの到達可能性の損失. エンジニアリングチームは、影響を受けたインフラストラクチャを隔離し、回復を開始するために直ちに動員しました。 - トラフィックの分離: Google のエンジニアは、オフラインの可用性ゾーン(ヨーロッパ西2-b)を分離し、影響を受けるインフラから離れた地域サービスルーティングを調整し、クロスゾーンのクライアントのリクエストをオフラインのエンドポイントからタイミングで防止します。 - Workload Reprioritizationとリソース・セーフガード: エンジニアは、スケジュールの割り当てと容量の制限を調整し、不当なインフラ全体で有効な顧客の予約を優先し、実行スロットのリソースの内容を削減し、地域のワークロードのキュー・バックログを緩和します。 - 電力網の回復:オンサイト施設のエンジニアは1時間以内に、供給が戻ったら安定した電力供給の優雅な回復を行ないました。 これにより、設備の電力を回復させるために、リセットと緊急バックアップジェネレータの自動化コントローラーをテストしました。 - プログレッシブ・インフラの再活性化: Google のエンジニアは、根本的な Google のクラウドインフラとサービスを体系的に再起動しました。 - 制御された交通再入場:システム健康とストレージの整合性が検証されたら、エンジニアは段階的に実行され、管理されたトラフィック再入場をゾーンのヨーロッパ西2-bに戻し、蓄積されたジョブのバックログがスムーズにクリアできるようにしました。 2026年10月20日(火)に米国/太平洋に拠点を置くことで、顧客ワークロードの大半にサービスの利用状況が回復し、地域のGoogle Cloud Platformサービスに関するほとんどの顧客の解決が確認されました。 残りの隔離されたワークロードの小さな尾の回復に続いて、事件の閉鎖通知は、投稿されました 07:03 アメリカ/太平洋. **影響の記述** 2026年10月19日(月)、23日(火)、20日(火)、2026年10月20日(火)、14日(日)、14日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日(日)、22日)、22日(日)、22日(日)、22日)、22日(日(日)、22日(日)、22日(日)、22日(日)、22日(日(日)、22日(日(日(日(日)、22日)、22日)、22日(日(日)、22日)、22日(日(日(日(日)、22日(日(日)、22日) 初期段階では、23:00から0429 US/Pacific(duration 5時間、29分)、顧客は、ほとんどのGoogle Cloud Platformサービスが回復するまで、高度なエラー率、APIタイムアウト、および処理遅延を経験しました。 プラットフォームサービス修復後、コンピュートエンジンインスタンスで稼働している一部の顧客のワークロードは、より長いリカバリテールを経験しました。 によって 04:46 米国/太平洋の新しい仮想マシンの作成は再開し、コンピュートエンジンの仮想マシンの99%以上PM0米国/太平洋は健康な状態でした。 仮想マシンの問題を経験している残りの顧客は、通常の手順に従ってカスタマーサポートの問題を提出する必要があります。 物理的な停電は、欧州のデータセンター施設に厳格に隔離されていましたが、不正確なゾーン(ヨーロッパ西2-aおよび欧州西2-c)または地方のアーキテクチャ全体で作業負荷を実行している一部の顧客は、予期しない影響を経験しました。 第一次原因は 1) 瞬時の需要は、非影響の計算能力と 2) 星の境界を横断する同期制御平面検証の依存性を急増しました。 感染した製品: BigQuery、Looker、Google Compute Engine、Google Kubernetes Engine、地域永続ディスク、およびクラウドSQL。 これらのサービスは、急激な容量の枯渇、およびオフラインゾーンからの検証を待っている制御プレーンAPIタイムアウトによって駆動される予期しない劣化と故障の問題を経験しました。 europe-west2-b 内で完全にホストされているワークロードとリソースは到達できませんでした。 Cloud SQL、AlloyDB、Redis 用の Memorystore、および Cloud Bigtable などの不正な機能を備えたデータストレージサービスが、欧州の 2 b の停電時に、近隣の不当なゾーンに引き渡されました。 europe-west2 地域を網羅する多角的および地域サービスは、高レイテンシー、過渡的な API エラー(HTTP 500 や 503 エラーなど)を経験し、障害のあるトラフィックが不当な地域資源に集中し、オフライン コンポーネントへのクロス・ゾーン・コールに集中するようにキューイングするタスク・インクルード。 地域におけるストレージ書き込み操作は、初期のフェイルオーバー期間中に一時的なエラー率を経験し、容量のリバランスとして急速にサブスライディングする前に、地域のクエリ入学キューを一時的にピークしました。 次のGoogleクラウドプラットフォームサービスは、影響を経験しました。 - PostgreSQL 用の PostgreSQLDB - アピギー - BigQueryデータ転送サービス - クラウドデータ融合 - クラウドファイルストア - クラウドファイヤーストア - クラウド負荷分散 - クラウドメモリストア - クラウドNAT - クラウドラン - クラウドスパーナー - クラウドワークステーション - データストリーム - ダイアログフローCX - Googleアプリエンジン - GoogleのBigQuery - Google クラウド ビッグテーブル - Googleクラウドデータフロー - GoogleクラウドDataproc - GoogleクラウドNetAppボリューム - Googleクラウドパブ/サブ - GoogleクラウドSQL - Googleクラウドストレージ(GCS) - Google Computeエンジン(GCE) - Google Kubernetesエンジン(GKE) - Google SecOps (セキュリティ情報とイベント管理 [SIEM] およびセキュリティオーケストレーション、オートメーション、応答 [SOAR]) - Looker(Googleクラウドコア) - ルッカースタジオ - マネージド・エアフロー(Google Cloud Composer) - Apache Kafka の管理サービス - Memcachedのメモリストア - Redisのメモリストア - Redis Clusterのメモリストア - バルキーのメモリストア - ネットワークコネクティビティセンター - 持続的なディスク - プライベートサービス接続 - スピーチ・ツー・テキスト - 仮想プライベートクラウド(VPC) - 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 ----------
公式のインシデント更新を自動翻訳しています。