Google Cloud Londra Kesintisi: Tek Veri Merkezi Elektrik Sorunu Bankaları Nasıl Durdurdu?

Google Cloud'un Londra bölgesinde yaşanan elektrik kaynaklı kesinti, birkaç bankayı, fintech uygulaması Revolut'u ve mahkemelerde kullanılan bir video kamera sistemini aynı anda etkiledi. Google özür diledi ve hizmetlerin kademeli olarak geri geldiğini duyurdu. Olay, bulut yoğunlaşma riski tartışmasını yeniden gündeme taşıyor: bu kadar farklı kurum neden tek bir fiziksel arızaya bağlıydı?

Ne oldu?

Google Cloud'un Londra bölgesinde bir güç sorunu, bölgedeki hizmetlerde geniş çaplı aksamaya yol açtı. Bankacılık uygulamaları, Revolut ve adli süreçlerde kullanılan video altyapısı etkilendi. Google bir özür yayımladı ve toparlanma çalışmalarının sürdüğünü bildirdi. Kesintinin tam kök nedeni ve süresi hakkında ayrıntılı bir son rapor henüz yok; bu nedenle aşağıdaki değerlendirmeler ilk bilgilere dayanıyor.

Neden bir elektrik sorunu bu kadar yayıldı?

Bulut sağlayıcıları altyapıyı üç katmanda sunar: bölge (region), bölge içindeki bağımsız zonlar (availability zone) ve bu zonlardaki fiziksel veri merkezleri. Zonlar normalde ayrı güç ve soğutma hatlarına sahip olacak şekilde tasarlanır. Bir zonun düşmesi, diğerlerini etkilememelidir. Bu mimariye güvenen birçok kurum, uygulamasını bölge içinde birden çok zona yaydığında "yüksek erişilebilirlik" sağladığını düşünür.

Sorun şu: bir güç arızası beklenenden geniş yayılıyorsa, ya ortak bir bağımlılık (şebeke bağlantısı, ortak yedekleme sistemi, kontrol düzlemi) devredeydi ya da arıza zincirleme büyüdü. Kamuya açık bilgiyle hangisinin olduğunu söyleyemeyiz. Ama örüntü tanıdık: kâğıt üzerindeki izolasyon ile fiilî izolasyon her zaman aynı şey değil.

İkinci mesele ekonomik. Çoklu bölge mimarisi, maliyeti ve karmaşıklığı kabaca katlar. Veri tutarlılığı, bölgeler arası gecikme ve devreye alma testleri ayrı mühendislik işidir. Birçok kurum "çoklu bölge" desteğini satın alır, ama yedek bölgeye gerçek yük aktarımını hiç denemez. Kriz anında yedek plan, ilk kez çalıştırılan bir plana dönüşür.

Önceki büyük kesintilerle karşılaştırma

Bu olay tek başına istisna değil. Farklı kesintiler farklı zayıflıkları gösterdi:

CrowdStrike olayı bize çoklu bölgenin her riske çare olmadığını gösterdi: aynı hatalı güncelleme her yere ulaştıysa, coğrafi dağılım işe yaramaz. Londra olayı ise tersini söylüyor: yazılım sağlıklı olsa bile fiziksel altyapı tek noktada toplandığında, kullanıcılar aynı anda etkileniyor. İki olay birlikte okunduğunda ortaya çıkan sonuç net: dayanıklılık tek bir önlemle değil, farklı arıza türlerine karşı ayrı ayrı tasarlanır.

Düzenleyici cephe: İngiltere ne yapıyor?

İngiltere, bu tür bağımlılıkları düzenlemek için bir çerçeve geliştirdi. Maliye otoriteleri ve finansal düzenleyiciler, finans sektörünün yoğun biçimde kullandığı bulut sağlayıcılarını "kritik üçüncü taraf" olarak belirleyip doğrudan denetime almayı hedefleyen bir rejim kurdu. Mantık şu: bir banka kendi sistemini denetlenebilir kılmak zorundadır, ama hizmetini aldığı sağlayıcı denetim dışındaysa, sistemik risk bankanın görüş alanının dışında kalır.

Bu kesinti, rejimin neden gerekli olduğunu gösteren somut bir örnek. Ancak denetim, tek başına kesintiyi önlemez. Asıl soru, düzenleyicilerin sağlayıcılardan hangi şeffaflığı isteyeceği: zonların gerçek bağımsızlığı, ortak bağımlılıklar ve kurtarma testlerinin sonuçları.

Türkiye'deki bankalar için hangi dersler var?

Türkiye'de bankacılık düzenlemeleri, kritik verilerin ve sistemlerin yurt içinde tutulmasını esas alıyor. BDDK'nın bilgi sistemleri ve bulut kullanımına ilişkin kuralları, hassas verilerin yerelliğini ve bankanın sağlayıcı üzerindeki denetim hakkını öne çıkarıyor. Bu yaklaşım, veri egemenliği açısından anlamlı. Ama dayanıklılık açısından iki ucu keskin.

Yerellik kuralı, sağlayıcı seçeneklerini daraltıyor. Ülke içinde az sayıda bölge ve veri merkezi varsa, yoğunlaşma riski Londra'dakine benzer biçimde büyüyebilir. Yani yerellik, gizlilik riskini azaltırken kullanılabilirlik riskini artırabilir. Pratik çıkarım şu: bankaların yurt içinde farklı sağlayıcılar veya şirket içi altyapıyla kurduğu hibrit düzenler, tek bölgeli bir bulut mimarisinden daha dayanıklı olabilir. Bunun maliyeti var, ama kesinti maliyetiyle kıyaslanmalı.

Sırada ne var?

Üç gelişme izlenmeli. Birincisi, Google'ın yayımlayacağı kök neden analizi: güç arızasının zonlar arasında nasıl yayıldığı açıklanırsa, "zon izolasyonu" vaadinin gerçek sınırları görünür olur. İkincisi, İngiliz düzenleyicilerin bu olayı kritik üçüncü taraf denetimlerinde nasıl kullanacağı. Üçüncüsü, kurumların kendi tarafı: kaç banka ve kamu kurumu yedek bölgeye geçişi gerçekten test ediyor?

Editöryal değerlendirmemiz şu: bu olay bir Google sorunundan çok bir mimari alışkanlık sorunu. Sağlayıcılar izolasyonu daha şeffaf belgelemeli, ama kurumlar da "çoklu bölge" kutusunu işaretlemekle yetinmemeli. Kurtarma planı, yılda en az bir kez gerçek trafikle denenmedikçe plan sayılmaz. Bunu yapmayan kurum, bir sonraki kesintide aynı haberin konusu olur.