Google Cloud Londra kesintisi: Jeneratörler çalışmadı, piller 7 dakikada bitti

Ne oldu?

Google Cloud’un Londra bölgesinin adı europe-west2. Bölge üç erişilebilirlik alanından (availability zone) oluşuyor: europe-west2-a, -b ve -c. Her alan, kendi elektriği ve soğutması olan ayrı bir altyapı gibi düşünülüyor. Fikir basit: Biri düşerse öbür ikisi işi sürdürür.

20 Ekim 2026 sabahı, Londra saatiyle 06:53’te, europe-west2-b’yi barındıran tesiste şebeke elektriği kesildi. Normalde olması gereken şu: Yük önce UPS pillerine geçer, piller birkaç dakika idare ederken dizel jeneratörler çalışıp yükü devralır. Bu sefer jeneratörleri başlatıp yükü aktaracak otomasyon, yani PLC denen endüstriyel kontrol bilgisayarları, hem asıl hem yedek olanı, bu sırayı başlatamadı. Piller yaklaşık 7 dakika sonra, 07:00’de bitti. Alandaki sunucular, ağ donanımı ve depolama bir anda kapandı.

Şebeke elektriği bir saat içinde geri geldi. Ama sistemleri sırayla ayağa kaldırmak, sağlık ve depolama kontrollerini yapmak, trafiği kontrollü şekilde geri almak saatler sürdü. Google’a göre ilk evre 5 saat 29 dakika sürdü, ön rapordaki bitiş saati de Londra saatiyle 13:10. Etkilenen ürün listesi 38 kalemi buluyor: Compute Engine, GKE, Cloud SQL, BigQuery, Cloud Run, Pub/Sub ve daha fazlası.

Neden sağlam alanlar da zorlandı?

Raporun en öğretici kısmı burası. Sadece bir alan elektriksiz kaldı, ama Google iki sebeple öbür alanların da etkilendiğini yazıyor:

• Ani kapasite talebi. Düşen alandaki iş yükleri aynı anda europe-west2-a ve -c’ye kaymaya çalıştı. Herkes aynı anda yeni makine isteyince bu alanlardaki kapasite tükendi. Kuyruklar oluştu, veritabanı devir işlemleri (failover) gecikti, aralıklı 500/503 hataları görüldü.
• Alanlar arası bağımlılık. Bölge düzeyindeki bazı kontrol servisleri, düşen alandaki meta veri ve katalog bileşenlerine eşzamanlı (synchronous) sorgular atıyordu. Cevap gelmeyince zaman aşımına düştüler. İş gönderme durdu, API’ler yavaşladı.

Yani kâğıt üzerinde bağımsız olan alanlar, pratikte birbirine görünmeyen iplerle bağlıydı.

Revolut neden düştü?

İngiltere’de Revolut kartla ödemeler ve para yükleme dahil uzun süre aksadı. Lloyds ve HSBC müşterileri de sorun bildirdi. Revolut, aksaklığı açıkça Google Cloud kesintisine bağladı ve müşteri parasının güvende olduğunu söyledi. Videoya göre Revolut, Google’ın çoğu müşteri için toparlandığını söylediği saatten sonra da akşama kadar tam düzelmedi. Bu, servisin kendi mimarisinin de en az bulut kadar belirleyici olduğunu gösteriyor: Tek alana bağlı bileşenler, soğuk bekleyen yedekler ya da toparlanma sırasında biriken iş kuyrukları kesintiyi uzatabiliyor.

Senin için dersler

• Çok alanlı kurulum, yedek kapasite garantisi değil. Kriz anında herkes aynı alanlara koşuyor. Kritik bir servisse, öbür alanlarda önceden ayrılmış (rezerve) kapasiteyi düşün.
• Bağımlılıklarını haritala. Servisin “bölgesel” görünse de içeride tek bir alana bağlı bir parça var mı? Bunu en iyi, bir alanı bilerek kapatıp test ederek öğrenirsin.
• Bölge de düşebilir. Alan seviyesindeki yedeklilik bir bölgenin tamamen kaybına karşı korumaz. Bunun en sert örneğini AWS’nin kalıcı veri kaybı yazısında anlatmıştık.

Google bu ön rapordan sonra kök neden analizini bitirip önlemleri de içeren son raporu yayımlayacağını söylüyor.

Düşün

• Kullandığın bulut sağlayıcısında bir alan kapansa, servisin hangi parçası ilk düşer?
• Felaket senaryonu en son ne zaman gerçekten denedin?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.