Planlı Bakım Nasıl Kesintiye Dönüşür? Google Cloud us-west1 Olayı ve Tier III Dersleri
Google Cloud us-west1 bölgesindeki 20 Ağustos kesintisinin sebebi planlı bir fiber bakımıydı. Bakımın kesintiye dönüşmemesi için Tier III ilkeleri ve 7 operasyon kuralı.
Google Cloud'un us-west1 bölgesinde 20 Ağustos'ta yaşanan kesintinin sebebi planlı bir fiber bakım çalışmasıydı. Planlı bakım nasıl kesintiye dönüşür ve Tier III tasarım bunu nasıl önler?
Ne Oldu?
Google Cloud'un resmi olay kaydına göre, 20 Ağustos 2026'da Oregon'daki us-west1 bölgesinde çok sayıda üründe zaman aşımı, hata ve yüksek gecikme yaşandı. Etkilenen ürünler arasında Compute Engine, Kubernetes Engine (GKE), Cloud SQL, Cloud Storage, BigQuery, Pub/Sub, IAM ve Persistent Disk gibi temel servisler vardı.
Google'ın 24 Ağustos'ta yayımladığı ön olay raporuna göre:
Tetikleyici: Planlı (scheduled) bir fiber optik bakım çalışması, beklenmedik şekilde ağ kapasitesini düşürdü.
Büyüten etken: Trafiği alternatif kapasiteye taşıması gereken otomatik yeniden yönlendirme mekanizmaları bunu doğru şekilde yapamadı ve bölgede tıkanıklık oluştu.
Süre: Ana etki yaklaşık 2 saat 20 dakika sürdü (08:00–10:22 PDT, Türkiye saatiyle 18:00–20:22). Bazı ürünlerde toparlanma daha uzun sürdü.
Müdahale: Google, mümkün olan müşterilere başka bölgelere geçiş (failover) yapmalarını önerdi.
Kesintilerin Sessiz Kaynağı: Bakım
Kesinti denince akla genellikle elektrik kesintisi, donanım arızası ya da siber saldırı gelir. Oysa sektördeki pek çok ciddi olay, planlı bir değişiklik ya da bakım sırasında başlar. Sebebi basit: Bakım, sistemin yedekli bir bileşenini bilinçli olarak devre dışı bırakır. O anda geriye kalan bileşen tek başına yükü taşıyamazsa ya da yük doğru aktarılamazsa, planlı bir iş plansız bir kesintiye dönüşür.
us-west1 olayı bu senaryonun ders kitabı örneği: Fiber bakımı planlıydı, yedek kapasite vardı; ama trafiği oraya taşıyacak otomasyon beklendiği gibi çalışmadı.
Tier III'ün Temel İlkesi: Bakımda Kesintisizlik
Uptime Institute'un Tier sınıflandırmasında Tier III'ü tanımlayan kavram "concurrently maintainable", yani eş zamanlı bakım yapılabilirliktir. Bu, enerji ve soğutma altyapısındaki her bileşenin, BT yüküne kesinti yaşatmadan bakıma alınabilmesi demektir.
Tier II | Tier III | |
|---|---|---|
Yedekli bileşen | Var (N+1) | Var (N+1) |
Dağıtım yolu | Tek yol | Birden fazla bağımsız yol |
Planlı bakımda kesinti | Gerekebilir | Gerekmez |
Tipik hedef | Küçük ve orta işletmeler | Kurumsal ve kritik iş yükleri |
Ancak bu olay bir şeyi daha hatırlatıyor: Tasarım tek başına yetmez. Yedek yolun var olması ile bakım anında gerçekten yükü taşıyabilmesi farklı şeylerdir. Bunu güvenceye alan şey operasyon disiplinidir.
Bakımın Kesintiye Dönüşmemesi İçin 7 Kural
Kapasite kontrolü: Bir bileşeni bakıma almadan önce, kalan yolun mevcut tepe yükü taşıyabildiği ölçümle doğrulanmalı.
Otomasyona körü körüne güvenmeyin: Otomatik failover mekanizmaları düzenli olarak test edilmeli; ilk gerçek testleri bakım günü olmamalı.
Yazılı yöntem bildirimi (MOP): Her bakım adım adım yazılı bir prosedürle ve geri dönüş planıyla yapılmalı.
Doğru zamanlama: Bakımlar düşük trafik pencerelerinde yapılmalı ve müşterilere önceden duyurulmalı.
Kademeli ilerleme: Değişiklikler küçük parçalara bölünmeli; her adımdan sonra sistem gözlemlenmeli.
Anında geri alma: Beklenmeyen bir sapma görüldüğünde işlemi durdurma yetkisi ve hazır bir geri dönüş adımı bulunmalı.
Olay sonrası şeffaflık: Ne olduğu, neden olduğu ve nasıl önleneceği açıkça raporlanmalı.
Müşteri Tarafında Ne Yapılmalı?
Altyapı sağlayıcınız ne kadar iyi olursa olsun, kendi mimarinizde de önlem almalısınız:
Kritik servisleriniz için tek bölge ya da tek lokasyon bağımlılığından kaçının.
Sağlayıcınızın bakım takvimini takip edin ve bakım pencerelerinde riskli değişiklik yapmayın.
Sağlayıcınıza bakımlarda yedekliliğin nasıl korunduğunu sorun.
SLA'in planlı bakımı kesinti hesabına dâhil edip etmediğini kontrol edin. Bu konuyu uptime yazımızda ayrıntılı ele aldık.
Sık Sorulan Sorular
Planlı bakım SLA'den düşülür mü?
Sağlayıcıya göre değişir. Bazı SLA'ler önceden duyurulan bakım sürelerini kesinti hesabına katmaz. Sözleşmenizdeki tanımı mutlaka kontrol edin.
Concurrently maintainable ne demek?
Tier III veri merkezlerinin temel özelliğidir: Enerji ve soğutma altyapısındaki herhangi bir bileşen, BT ekipmanlarının çalışmasını kesmeden bakıma alınabilir.
Bulut bölgesi kesintisinde ne yapılmalı?
Uygulamanız birden fazla bölgede ya da farklı bir ortamda çalışabiliyorsa trafiği oraya yönlendirin. Bu mümkün değilse, sağlayıcının durum sayfasını takip ederek kullanıcılarınızı bilgilendirin.
Fiber kesintisi bir veri merkezini nasıl etkiler?
Veri merkezinin dış dünyaya ya da diğer kampüslere bağlantısı tek fiber güzergâhına dayanıyorsa, o hattaki bir kesinti erişimi doğrudan etkiler. Fiziksel olarak ayrı güzergâhlar ve birden fazla operatör bu riski azaltır.
Olfe'de Bakım Kesinti Demek Değil
Olfe'nin İzmir Bornova'daki veri merkezi Tier III altyapıyla, bakım sırasında bile kesinti olmadan çalışacak şekilde tasarlandı. Çift hat besleme, UPS ve jeneratör yedekliliği ile 7/24 izleme altyapısı, sözleşmeyle garanti altına alınmış %99.99 uptime taahhüdünün temelini oluşturur. Altyapınızı birlikte değerlendirmek için bizimle iletişime geçin.
Sonuç
us-west1 olayı, dünyanın en büyük bulut sağlayıcılarından birinde bile rutin bir bakımın iki saati aşan bir kesintiye dönüşebildiğini gösterdi. Ders şu: Yedeklilik bir tasarım özelliği değil, her bakımda yeniden kanıtlanması gereken bir operasyon disiplinidir.