Azure'ın California Bölgesini Çökerten 6 Saatlik Olay
23 Temmuz 2026'da saat 14:44 UTC'de Microsoft'un Azure West US veri merkezinde rutin bir donanım bakımı başladı. Altı saat sonra, 27 Azure hizmeti çökmüş durumdaydı. Sorun fiziksel bir arıza değildi; Microsoft'un bakım yönetim sistemindeki bir yazılım hatası, bakım kapsamında olmaması gereken cihazları yanlış işaretlemiş ve veri merkezi ile geniş alan ağı arasındaki kritik IP yollarını kaldırmıştı. Bölgeye giren ve çıkan tüm trafik kesildi.
Bu olay Microsoft'un bulut altyapısında iki önemli tasarım zayıflığını ortaya koydu: bakım otomasyon sistemleri yanlış cihazları işaretleyebildiğinde geri dönüşü olmayan ağ değişiklikleri yapabiliyor; ve geniş kaplı ağ kesintileri tanılaması Microsoft mühendislerine 2 saat almıştı. Azure'u kullanan şirketler için bu, bölgesel çeşitlendirme ve failover stratejilerini yeniden değerlendirme zamanı.
Yazılım hatası IP yollarını nasıl sildi
Kesintinin kök sebebi, Microsoft'un "request conversion system" adını verdiği bakım yönetim aracındaki bir hataydı. Bu araç, mühendislerin bakım taleplerini alıp hangi cihazların ne zaman bakıma alınacağını belirliyor. 23 Temmuz'daki rutin fiber bakımı sırasında sistem, bakım kapsamında olmaması gereken ek cihazları yanlış işaretledi.
Ardından gelen adım bölgesel ağı kapattı: Sistem, bu cihazların IP yollarını veri merkezi ile geniş alan ağı arasından kaldırdı. Azure West US bölgesi, trafiği ne kabul edebilir ne de gönderebilir hale geldi. Microsoft'un açıklamasına göre sorun "large-scale route churn" olarak tanımlandı—yani binlerce ağ yolunun anlık olarak kaybolması.
Bu tür hatalar, otomasyonun başarısızlık modlarının ne kadar kritik olduğunu gösteriyor. Manuel kontroller çok yavaş kaldığı için Microsoft gibi hiper ölçekli bulut sağlayıcıları yoğun otomasyona güveniyor; ancak bu araçlar güvenlik kilitleri olmadan çalıştığında, tek bir yazılım hatası saatlerce süren kesintilere yol açabiliyor. Fiber bakımı gibi rutin bir işlemin tüm bölgesel ağı çökertebilmesi, sistemin savunma katmanlarının yetersiz olduğunu gösteriyor.
27 hizmet neden etkilendi ve tanılama neden 2 saat sürdü
Azure West US bölgesindeki kesintiden 27 farklı Azure hizmeti etkilendi. Bunlar arasında Azure Virtual Machines, Azure App Service, Azure Functions ve Azure SQL Database gibi temel altyapı servisleri vardı. Bölge çöktüğünde, bu hizmetlere bağlı olan tüm uygulamalar ve iş yükleri de erişilemez hale geldi.
Microsoft'un sorunu tespit etmesi 2 saat sürdü. Geniş kaplı ağ kesintileri tanılaması karmaşıktır çünkü tek bir başarısızlık noktası yerine binlerce yolun aynı anda kaybolması durumunda, hangi değişikliğin sorumlu olduğunu bulmak zordur. Microsoft mühendisleri, ağ rotalarındaki "churn" ile fiber bakım aktivitesi arasındaki korelasyonu ancak 2 saat sonra kurabildi.
Tam iyileşme 5 saat 57 dakika sürdü. Sorun bulunduktan sonra bile, binlerce IP yolunu geri yüklemek vakit aldı. Microsoft, tüm servislerin saat 19:41 UTC'de tamamen geri döndüğünü açıkladı.
Microsoft 365 ve Teams kesintisi: ayrı olay mı, aynı nedenden mi?
Aynı hafta içinde Microsoft 365, Teams ve Outlook'un da çöktüğü raporlandı. Perşembe sabahı 07:30 sonrası başlayan bu kesinti, saat 14:00'e kadar sürdü. Microsoft bu kesintinin kök sebebini açıklamadı.
İki olayın aynı yazılım hatası nedeniyle mi yoksa tamamen farklı nedenlerle mi gerçekleştiği bilinmiyor. Tarih ve saat bilgileri farklı, ve Azure West US kesintisi veri merkezi ağ yollarıyla ilgiliyken, Microsoft 365 kesintisi uygulama katmanında yaşanmış görünüyor. Ancak Microsoft'un her iki vakada da kök sebep analizi yayınlamaması, kamuyu tam bilgilendirmediği anlamına geliyor.
Azure kesintileri ve işletmeler için operasyonel riskler
Azure kesintisi, Microsoft'un bulut altyapısında bir veya daha fazla bölgenin, servisin ya da veri merkezinin belirli bir süre erişilemez hale gelmesi demektir. Kesintiler donanım arızalarından, yazılım hatalarından, ağ sorunlarından veya insan kaynaklı yapılandırma hatalarından kaynaklanabilir.
Bu tür kesintiler işletmeler için çok katmanlı operasyonel risk oluşturur:
- Gelir kaybı: E-ticaret veya SaaS şirketleri, her kesinti dakikası için doğrudan gelir kaybeder. Azure West US'taki 6 saatlik kesinti, bölgeye bağımlı şirketler için önemli operasyonel kayıp anlamına geldi. - Veri erişimi: Azure SQL Database veya Azure Cosmos DB gibi servisleri kullanan şirketler, kendi verilerine erişemez hale gelir. Bu, müşteri destek, sipariş işleme ve operasyonel raporlama gibi kritik süreçleri durdurur. - SLA ihlalleri: Azure'un Service Level Agreement politikası yüzde 99,95 uptime vaat eder; 6 saatlik kesinti bu taahhüdü ihlal eder. SLA kredileri kaybedilen geliri karşılamaz. - Reputasyon hasarı: Kendi müşterilerine hizmet veremeyen şirketler güven kaybeder. Sağlık, finans veya kamu hizmeti gibi kritik sektörlerde bu tür kesintiler düzenleyici soruşturmalara yol açabilir.
Azure gibi hiper ölçekli bulut platformlarının bile tek bir yazılım hatası nedeniyle saatlerce çökebilmesi, "bulut güvenilir" varsayımının yanlış olduğunu gösteriyor. Gerçek güvenilirlik çok bölgeli mimari ve failover planlarıyla sağlanabilir.
Multi-region failover stratejileri ve kontrol mekanizmaları
Azure West US olayı, işletmelerin bulut stratejilerinde temel soruları yeniden değerlendirmelerini gerektiriyor.
Bölgesel çeşitlendirme zorunludur. Tek bir Azure bölgesine bağımlı kalmak, o bölgedeki herhangi bir kesintiden doğrudan etkilenmeniz anlamına gelir. En azından iki farklı coğrafi bölgeye yayılmış multi-region mimarisi kurmak gerekir. Azure, West US yanında East US, North Europe, Southeast Asia gibi seçenekler sunar.
Aktif-aktif veya aktif-pasif failover: Aktif-aktif mimari, trafiği her zaman birden fazla bölgeye dağıtır ve bir bölge çöktüğünde otomatik olarak diğerine yönlendirir. Aktif-pasif ise bir bölge çökene kadar yedek bölgeyi boşta tutar. İkincisi daha ucuz ama failover süresi daha uzun olabilir.
Bağımsız monitoring: Azure'un kendi izleme araçlarına güvenmek yetersiz; çünkü bölge çöktüğünde bu araçlar da erişilemez hale gelebilir. Third-party monitoring servisleri (Datadog, New Relic gibi) farklı bölgelerden sistem sağlığını izleyebilir ve kesinti anında daha hızlı uyarı verir.
Failover testleri: Failover planınızı yılda en az bir kez gerçek bir simülasyonla test edin. Mühendislerin bir bölgeyi manuel olarak devre dışı bırakıp uygulamanın diğer bölgeye geçişini gözlemlemesi gerekir.
Türkiye'deki şirketler için ek husus: Azure'un Türkiye'de fiziksel bölgesi yok. Genellikle West Europe veya North Europe kullanılır. Bu bölgeler de benzer yazılım hatalarına maruz kalabilir; coğrafi çeşitlendirme yaparken sadece fiziksel uzaklığa değil, aynı zamanda farklı veri merkezi kümelerine dağılmaya dikkat etmek gerekir.
Otomasyonun savunma katmanları: Microsoft'un iyileştirmesi gereken noktalar
Azure West US kesintisinin asıl öğretici yanı, otomasyonun başarısızlık modlarının ne kadar felaket olabileceğidir. Microsoft'un request conversion sistemi, bakım taleplerini hızlı şekilde işlemek için tasarlandı; ancak aynı hız, tek bir hata durumunda binlerce ağ yolunu anında silme gücüne sahipti.
Bu tür sistemlerde olması gereken kontrol mekanizmaları:
Dry-run ve onay adımları: Kritik altyapı değişiklikleri uygulanmadan önce bir "dry-run" yapılmalı ve sonuçları insanlar gözden geçirmelidir. Bakım talebinin hangi cihazları etkileyeceğini bir mühendis görmeli ve onaylamalıdır.
Scope limitleri: Bir bakım talebi tüm bölgeyi etkileyecek kadar geniş kapsamlı olamaz hale getirilmelidir. Yazılım, bir işlemin belli bir sayıda cihazdan fazlasını etkilemeye çalışıyorsa uyarı vermeli veya işlemi durdurmalıdır.
Hızlı geri alma: Kritik ağ değişiklikleri hata durumunda anında geri alınabilir olmalıdır.
Bağımsız izleme: Bakım otomasyonu yapan sistem, aynı zamanda sonuçları izleyen sistem olmamalıdır. Bağımsız bir monitoring katmanı, ağ bağlantısında anormal düşüş gördüğünde uyarı verebilir.
Microsoft gibi şirketlerin otomasyon sistemlerini, en kötü senaryolara karşı dayanıklı hale getirmeleri artık operasyonel bir zorunluluktur. Hiper ölçekli bulut platformları ne kadar büyürse, tek bir yazılım hatasının etkisi o kadar büyük olur.
