유럽-서부2 지역의 문제점을 경험했습니다.
- resolved
** 일정 ** 유럽-서부2지역의 여러 서비스들이 있습니다. ** 설명** 우리는 월요일, 2026-10-19 23:08 PDT에 유럽 서두에서 여러 서비스를 가진 문제점을 경험하고있다. 우리의 엔지니어링 팀은 계속해서 문제를 조사합니다. 우리는 화요일, 2026-10-20 02 : 30 PDT 현재의 세부 정보를 제공합니다. 우리는 혼란에 의해 영향을받는 모든 사람들에게 사과합니다. **석** 다중 Google Cloud 서비스는 유럽-서부2 지역의 높은 오류 및 간헐적인 네트워크 실패를 경험하고 있습니다. ** 주변 ** 현재 위치
- resolved
** 일정 ** 유럽-서부2지역의 여러 서비스들이 있습니다. ** 설명** 우리는 월요일, 2026-10-19 23:08 PDT에 유럽 서두에서 여러 서비스를 가진 문제점을 경험하고있다. 우리의 엔지니어링 팀은 계속해서 문제를 조사합니다. 우리는 화요일, 2026-10-20 04:00 PDT에 의해 현재 세부사항을 제공할 것입니다. 우리는 혼란에 의해 영향을받는 모든 사람들에게 사과합니다. **석** 다중 Google Cloud 서비스는 높은 오류와 경험 유럽-서부2 지역의 간헐적인 네트워크 실패. 참고 : Looker Studio는이 정전에 영향을 미치지 않습니다. ** 주변 ** 가능한 경우, 충격 고객은 다른 사용 가능한 위치에 영향을 미칩니다 (zone 또는 지역).
- resolved
** 일정 ** 유럽-서부2지역의 여러 서비스들이 있습니다. ** 설명** 우리는 월요일, 2026-10-19 23:08 PDT에 유럽 서두에서 여러 서비스를 가진 문제점을 경험하고있다. 우리의 엔지니어링 팀은 계속해서 문제를 조사합니다. 우리는 화요일에 의해 업데이트를 제공 할 것입니다, 2026-10-20 05:00 PDT 현재 세부 사항. 우리는 혼란에 의해 영향을받는 모든 사람들에게 사과합니다. **석** 다중 Google Cloud 서비스는 높은 오류와 경험 유럽-서부2 지역의 간헐적인 네트워크 실패. 참고 : Looker Studio는이 정전에 영향을 미치지 않습니다. ** 주변 ** 가능한 경우, 충격 고객은 다른 사용 가능한 위치에 영향을 미칩니다 (zone 또는 지역).
- resolved
** 일정 ** 유럽-서부2지역의 여러 서비스들이 있습니다. ** 설명** 우리는 월요일, 2026-10-19 23:08 PDT에 유럽 서두에서 여러 서비스를 가진 문제점을 경험하고있다. 유럽-서부2-b 영역 내에서 정전을 겪은 전력 이벤트로 인해. 힘 사건은 mitigated. 인프라 서비스에 대한 부적 완화는 다음 30 분 이내에 관찰되며 나머지 서비스는 다음 후 수행됩니다. 우리는 화요일에 의해 업데이트를 제공 할 것입니다, 2026-10-20 05:00 PDT 현재 세부 사항. 우리는 혼란에 의해 영향을받는 모든 사람들에게 사과합니다. **석** Google Cloud 서비스는 유럽-서부2-b 영역에서 사용할 수 없습니다. 유럽-서부2 지역의 일부 서비스는 오류 및 간헐적인 네트워크 문제를 경험할 수 있습니다. ** 주변 ** 가능한 경우, 충격 고객은 다른 사용 가능한 위치에 영향을 미칩니다 (zone 또는 지역).
- resolved
** 일정 ** 유럽-서부2지역의 여러 서비스들이 있습니다. ** 설명** 우리는 월요일, 2026-10-19 23:08 PDT에 유럽 서두에서 여러 서비스를 가진 문제점을 경험하고있다. 유럽-서부2-b 영역 내의 정전이 발생했습니다. 힘 사건은 mitigated. 우리는 서비스의 회복을보고 기존의 워크로드의 복구를 우선 순위. 고객은 아직 새로운 워크로드를 만들 수 없습니다. 기존 작업 부하의 전체 복구 완료되어야, 화요일에 의해 일시적으로, 2026-10-20 06:00. 우리는 화요일, 2026-10-20 06:00 PDT 현재의 세부 사항에 의해 업데이트를 제공 할 것입니다. 우리는 혼란에 의해 영향을받는 모든 사람들에게 사과합니다. **석** Google Cloud 서비스는 유럽-서부2-b 영역에서 사용할 수 없습니다. 유럽-서부2 지역의 일부 서비스는 오류 및 간헐적인 네트워크 문제를 경험할 수 있습니다. ** 주변 ** 가능한 경우, 충격 고객은 다른 사용 가능한 위치에 영향을 미칩니다 (zone 또는 지역).
- resolved
** 일정 ** 유럽-서부2지역의 여러 서비스들이 있습니다. ** 설명** 우리는 화요일, 2026-10-20 05:10 PDT로 유럽 서 2에서 대부분의 작업 부하에 대한 서비스의 복구를보고 있습니다. 우리는 화요일, 2026-10-20 07:00 PDT에 의해 업데이트를 제공합니다. 우리는 혼란에 의해 영향을받는 모든 사람들에게 사과합니다. **석** Google Cloud 서비스는 유럽-서부2-b 영역에서 사용할 수 없습니다. 유럽-서부2 지역의 일부 서비스는 오류 및 간헐적인 네트워크 문제를 경험할 수 있습니다. ** 주변 ** 가능한 경우, 충격 고객은 다른 사용 가능한 위치에 영향을 미칩니다 (zone 또는 지역).
- resolved
** 일정 ** 유럽-서부2 지역의 문제점을 경험했습니다. ** 설명** 충격을 입힌 GCP 제품을 가진 문제점은 고객의 대부분을 위해 mitigated 이고 현재 고객의 아주 작은 수 및 우리의 기술설계 팀에 영향을 미치기 위하여 믿어집니다. 궁금한 점이 있거나 충격이 있으신 경우, 지원팀으로 케이스를 열어주시면 이 문제가 해결될 때까지 함께 일할 것입니다. 더 이상 업데이트는 없습니다. 우리는 우리의 내부 조사를 완료 한 번이 사건의 분석을 게시합니다. 우리는 문제를 해결하기 위해 노력하고 있습니다. **석** Google Cloud 서비스는 유럽-서부2-b 영역에서 사용할 수 없습니다. 유럽-서부2 지역의 일부 서비스는 높은 오류와 간헐적인 네트워크 문제를 경험할 수 있습니다. ** 주변 ** 문제로 아무도 mitigated.
- resolved
## Preliminary Incident 보고서 우리는 Google Cloud 서비스가 조직에 중요한 것을 인식하고, 우리는이 사건이 귀하의 사업에 발생할 수 있는 붕괴를 위해 진심으로 사과합니다. 우리는 뿌리 원인을 해결하고 미래에 발생하는 것을 방지하기 위해 노력하고 있습니다. 참고,이 정보는 우리의 가장 좋은 지식에 근거하여 게시물의 시간에 따라 계속 우리의 조사로 변경 될 수 있습니다. 우리의 조사가 완료되면 예방 조치와 최종 소득 보고서가 게시됩니다. 아래 나열된 내용의 외부에 대한 경험이있는 경우, [**https\://cloud.google.com/support**](https://cloud.google.com/support)를 사용하여 Google Cloud Support에 도달하십시오. ## 발행일/시간 법인 시작:19 10월 2026 23:00 미국/태평양 / 20 10월 2026 07:00 BST 유효 기간: 20 Oct 2026 05:10 US/Pacific/20 Oct 2026 13:10 BST 소요 시간: 6 시간, 10 분 ## 요약 월요일, 19 10 월 2026 (화, 20 10 월 BST), 유럽-서부2 지역의 여러 Google Cloud Platform 서비스 경험 서비스 중단, 높은 오류율, 응용 프로그램 프로그래밍 인터페이스 (API) 타임 아웃 및 6 시간 및 10 분의 기간 동안 처리 대기 시간. 중단은 일시적으로 물리적 호스트 서버, 네트워크 라우팅 하드웨어 및 스토리지 시스템 오프라인으로 물리적 호스트 서버, 네트워크 라우팅 하드웨어 및 스토리지 시스템에서 데이터 센터 시설 호스팅 가용성 영역 유럽-서부 2-b에 전력 중단에 의해 유발되었습니다. 이 후속에 발생되는 이차 실패 및 누락 지연은 지역 인프라에 영향을 미칩니다. ## 예비 뿌리 원인 이 사건은 데이터 센터 시설 호스팅 가용성 영역 europe-west2-b에서 전력 그리드 붕괴가 발생했을 때 방아쇠를 겪었습니다. 중단 도중 지속적인 힘을 유지하기 위하여, 시설 백업 힘 체계에 자동적인 이동은 즉각 방아쇠를 이었습니다. 시설 부하는 현장 비상 디젤 발전기의 시퀀스에서 무정전 전원 공급 (UPS) 배터리 은행으로 전송되었습니다. 풀그릴 논리 관제사 (PLC) 자동화 체계 (제 1 차 및 지원 PLCs)는 발전기의 논리 자동적인 시작/전송 가동을 개시하는 실패했습니다, 짐을 assuming에서 백업 발전기를 방지하. UPS 건전지 예비 품목이 depleted 때, 육체적인 주인 서버, 네트워크 엇바꾸기 직물 및 유럽-서부 2b에 전념한 지역 저장 배열은 힘을 잃고 따로따로 갔습니다. 고객 영향에 대한 이벤트의 순서는 다음과 같습니다. * 22시 53분의 US/Pacific (20 Oct, 06:53 BST)에서 전기 전력 중단은 데이터 센터 시설 호스팅 가용성 구역 유럽-서부2-b 및 PLC (Programmable Logic Controller) 시작 오류가 전기 부하를 섭취하는 장치 비상 발전기에서 발생했습니다. 시설 부하는 배터리가 depleted 될 때까지 UPS 배터리 은행에 의해 지속적으로 지원됩니다, 에서 시작 23:00 미국 / 태평양 (20 10 월, 07:00 BST). * 물리적 호스트 서버, 로컬 스토리지 인프라 및 유럽-서부2b 손실 전력의 네트워크 통합 하드웨어가 발생하면 해당 영역의 인스턴스, 데이터베이스 복제 및 작업 노드가 즉시 허용되지 않습니다. * 지역 트래픽 라우팅 메커니즘 및 클라이언트 애플리케이션은 지역 내의 인접 가용성 영역에서 사용 가능한 인프라를 통해 자동화 된 고장 발생을 초래했습니다. * 지역 서비스 제어 비행기에서 Cross-zone 원격 절차는 메타데이터 및 카탈로그 구성 요소를 오프라인 영역에서 만남 된 타임 아웃으로 호출하여 초기 작업 제출 축 및 API 대기 시간 스파이크를 발생시킵니다. * 리디렉션된 쿼리 실행, 높은 가용성 데이터베이스 장애의 급격한 영향, 및 다른 가용성 영역에서 포화 가능한 compute 슬롯 및 처리 용량을 준수, 높은 입학 큐 생성, 지연된 데이터베이스 실패 완료 및 지역 전체에 걸쳐 500 및 503 API 오류. Google 엔지니어는 전체 루트 원인 분석 (RCA)을 시작하고 추가 정보를 한 번 사용할 수 있습니다. ## 구제 Google 엔지니어는 19 Oct (20 Oct, 07:08 BST)에 23:08 US / Pacific에서 자동화 된 모니터링 시스템 및 프로버터를 통해 중단에 경고했다. 높은 API 오류 비율, 작업 제출 시간, 유럽-서부 2b의 인프라 가용성의 손실. 엔지니어링 팀은 즉시 영향을받는 인프라 및 commence Recovery를 격리했습니다. * **Traffic 고립: ** Google 엔지니어는 영향을받는 인프라에서 벗어나 지역 서비스 라우팅을 조정함으로써 오프라인 가용성 구역 (European-west2-b)에 격리되어 오프라인 엔드포인트에 대한 타이밍을 방지합니다. * ** Workload Reprioritization 및 리소스 Safeguards:** 엔지니어는 가동 가능한 고객 예약을 우선적으로 하기 위하여 unimpacted 기반을 통해 스케줄러 할당 및 수용량 한계를 조정하고, 실행 구멍에 자원 contention를 감소시키고, 지역 workloads를 위한 queue backlogs를 구호합니다. * ** 전력 그리드 복원 : ** 현장 시설 엔지니어는 1 시간 이내에 안정적인 유틸리티 전력 공급을 한 번 업그레이드했습니다. 이 뒤에, 그들은 집중하고 재시동을 완료하고 비상 백업 발전기 자동화 컨트롤러를 테스트하여 시설 전력을 복원합니다. * **Progressive Infrastructure Re-activation: ** Google 엔지니어 체계적으로 핵심 Google Cloud 인프라 및 서비스를 재시작했습니다. * **제어된 교통 재출발:** 일단 체계 건강 및 저장 무결성은 확인되었습니다, 엔지니어는 점차적으로, 지역 europe-west2-b에 통제된 교통 re-admission는 매끄럽게 명확한 일 backlogs를 축적했습니다. By 05:10 US/Pacific on Tuesday, 20 Oct(13:10 BST), 서비스 이용 가능성은 대다수의 고객 워크로드를 위해 복구되었으며, Google Cloud Platform 서비스에 대한 대부분의 고객에 대한 해결책이 확인되었습니다. 나머지 고립 된 작업 부하의 작은 꼬리의 복구에 따라, 사건에 대한 폐쇄 통지는 07:03 미국 / 태평양 (15:03 BST)에 의해 게시되었습니다. ## 충격의 묘사 월요일부터 19 Oct 2026, 23:00 US/Pacific (화, 20 Oct 2026, 07:00 BST) 및 화요일, 20 10 월 2026, 05:10 US/Pacific (13:10 BST), 유럽-서부2 지역의 Google Cloud Platform 서비스를 활용하여 6 시간, 10 분의 총 기간을 지속하는 2 연속 단계의 서비스 중단을 경험했습니다. 23:00에서 04:29 US/Pacific (07:00에서 12:29 BST) (현도 5 시간, 29 분)까지의 초기 단계 동안 고객은 높은 오류율, API 타임 아웃을 경험했으며 대부분의 Google Cloud Platform 서비스까지 지연을 처리했습니다. 플랫폼 서비스 복원 후, Compute Engine 인스턴스에서 실행되는 일부 고객 작업로드는 더 긴 복구 꼬리를 경험했습니다. 04:46 US/Pacific (12:46 BST) 새로운 가상 머신 생성 재개 및 by 05:10 US/Pacific (13:10 BST) 99% 이상의 컴퓨터 엔진 가상 머신은 건강한 상태였습니다. 가상 머신 문제를 경험한 나머지 고객은 정상적인 절차에 의하여 고객 지원 문제점을 파일로 지시되었습니다. 물리적 전력 부족은 유럽-서부2-b의 데이터 센터 시설에 엄격히 격리되었지만, 일부 고객은 잘못된 영역 (유럽-서부2-a 및 유럽-서부2-c)의 워크로드를 실행하거나 지역 아키텍처를 통해 예상치 못한 영향을 경험했습니다. 주요 원인은 1 \) 즉시 수요가 발생했습니다. 손상되지 않은 보상 용량과 2 \) zonal 경계를 가로지르는 비동기 제어 비행기 유효성. 포함 된 제품 : BigQuery, Looker, Google Compute Engine, Google Kubernetes Engine, Regional Persistent Disk 및 Cloud SQL. 이 서비스는 예상치 못한 분해와 실패한 문제로 인해 갑작스런 컴퓨팅 용량 배출에 의해 구동, 그리고 제어 비행기 API 타임 아웃은 오프라인 영역에서 검증을 기다리고 있습니다. europe-west2-b 내에서 전적으로 호스팅되는 워크로드 및 리소스가 허용되지 않았습니다. Cloud SQL, AlloyDB, Redis용 Memorystore, Cloud Bigtable과 같은 장애 기능이있는 데이터 저장 서비스는 유럽-서부2-b 아웃리지 동안 인근 손상되지 않은 영역에 실패했습니다. 유럽-서부2 지역 주변의 다존성 및 지역 서비스들은 높은 대기 시간, 과도한 API 오류 (HTTP 500 및 503 오류와 같은)를 경험하고, 실패 트래픽이 중단되지 않은 지역 자원과 교차 영역 통화로 집중하여 중단 된 구성 요소에 대한 작업 입수. 저장은 지역에 있는 가동은 초기 실패 기간 도중 일시적인 과실율을 경험하고, 지역 조회 입장은 수용량 re-balanced로 급속하게 subsiding의 앞에 일시적으로 최고봉했습니다. 다음 Google Cloud Platform 서비스는 충격을 경험했습니다. * PostgreSQL용 AlloyDB * 아피지 * BigQuery 데이터 전송 서비스 * 클라우드 데이터 융합 * 클라우드 파일스토어 * 클라우드 저장소 * 클라우드 로드밸런싱 * 클라우드 메모리스토어 * 클라우드 NAT * 클라우드 실행 * 클라우드 스패너 * 클라우드 워크스테이션 * 데이터스트림 * 대화 흐름 CX * Google 앱 엔진 * 구글 BigQuery * 구글 클라우드 Bigtable * 구글 클라우드 Dataflow * 구글 클라우드 Dataproc * Google Cloud NetApp 볼륨 * 구글 클라우드 펍/Sub * 구글 클라우드 SQL * 구글 클라우드 스토리지 (GCS) * Google 컴퓨터 엔진 (GCE) * Google 쿠버네티스 엔진 (GKE) * Google SecOps (보안 정보 및 이벤트 관리 \[SIEM \] 및 보안 오케스트라, 자동화 및 응답 \[SOAR \]) * 뷰어 (Google Cloud Core) * 뷰어 스튜디오 * 관리된 기류 (Google Cloud Composer) * Apache Kafka에 대한 관리 서비스 * Memcached를 위한 Memorystore * Redis를 위한 Memorystore * Redis 클러스터용 Memorystore * Valkey를 위한 Memorystore * 네트워크 연결 센터 * 영구 디스크 * 개인 서비스 연결 * 발음-문자 * 가상 프라이빗 클라우드(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 ----------
공식 인시던트 업데이트를 자동 번역했습니다.