Exchange Online sağlık kontrolü hataları Outlook, Teams ve Copilot'i bir günden uzun süre çökertti

Ne oldu

Microsoft 365, 12 Kasım 2026'da saat 18:26 UTC'de başlayan uzun soluklu, dünya çapında bir kesinti yaşadı. Control Plane tarafından dev.to'da yayımlanan Microsoft durum güncellemelerinin özetine göre, MO1550821 olarak izlenen olay, Exchange Online ve Outlook arızalarıyla Amerika kıtasında başladı, sonra diğer bölgelere ve Exchange üzerinde çalışan Teams, Microsoft 365 Copilot, SharePoint Online, Intune ve Defender for Office 365 gibi hizmetlere yayıldı.

The Register'ın bildirdiğine göre kullanıcılar, e-postanın ötesinde Teams, Cloud PC ve Copilot ile birlikte yaklaşık 15 diğer barındırılan hizmete tamamen erişimi kaybetti; Microsoft olayı tam bir kesinti değil, hizmet bozulması olarak sınıflandırdı. Etkilenen hizmetler arasında Microsoft 365 Education da vardı.

Kurtarma yavaş ilerledi. dev.to'daki zaman çizelgesine göre aynı öğleden sonra ayrı ve daha erken bir Teams olayı zaten açılmış ve çözülmüştü. MO1550821 başladıktan 20 saatten fazla sonra Microsoft hâlâ aralıklı sorunlar bildiriyordu: Kuzey Amerika ve Avrupa'nın büyük bölümünde iyileşme 13 Kasım günü geldi, ardından Asya Pasifik'te erken toparlanma yaşandı ve daha sonraki bir güncelleme e-posta kuyruklarının önemli ölçüde azaldığını belirtti.

Microsoft'un kendi ifadeleriyle zincirleme bir arıza

BleepingComputer ve The Register'ın aktardığı Microsoft güncellemeleri, talep artışından çok bir kapasite çökmesine işaret ediyor. Exchange Online'daki sunucular otomatik sağlık kontrollerini geçemez hale gelip servis dışı kaldı; yükleri kalan sunuculara bindi ve sonunda onlar da bunaltıldı. Microsoft, artan yükün trafiğin artmasından kaynaklanmadığını ve kötü niyetli bir faaliyet belirtisi bulunmadığını belirtti.

Sonraki güncellemeler, arızaların sunucu sağlığını işleyen bir bileşenden kaynaklanıyor olabileceğini ve etkilenen sunuculardaki temel bir sürecin, sunucular yanıt veremez hale gelene kadar bunaltıldığını ekledi.

Bu, dağıtık sistemlerde iyi anlaşılan bir arıza biçimiyle örtüşüyor: zincirleme arıza. Sağlık kontrolleri, bozuk sunucuları devreden çıkarmak için vardır; ancak çok sayıda sunucu aynı anda başarısız olursa, ayakta kalanlar ek yükü üstlenir, sonra kendi kontrollerini geçemez ve döngü tekrarlar. Microsoft'un kurtarma zorlukları tam olarak bu dinamiği yansıttı. Doğrulanmış alternatif bir sağlık kontrol yöntemini geçen sunucular, gerçek trafik geri döndüğünde yeniden yanıt vermez hale geldi ve sanal makineleri ölçeklendirme girişimleri, değişikliklerin eşitlenmesini engelleyen kötü durumda takılı kalan makinelerce sekteye uğradı. Microsoft bir noktada, yaptığı işlemlerin beklediği rahatlamayı sağlamadığını kabul etti.

Azaltıcı adımlar arasında dağıtımları duraklatmak, trafiği yeniden dağıtmak, sunucuları yeniden başlatmak, sağlık kontrol yöntemini değiştirmek ve kuyruktaki e-postaların geri dönmemesi için e-posta teslim zaman aşımını 48 saate uzatmak yer aldı. Microsoft ayrıca az sayıda yakın yapılandırma güncellemesinin geri alınmasının kurtarmayı hızlandırıp hızlandırmayacağını değerlendiriyordu. Yönetici Charles Lamanna, ekiplerin olanları ve benzer sorunların nasıl önleneceğini incelediğini söyledi.

Hâlâ bilinmeyenler

Tetikleyici hâlâ bir muamma. Microsoft, sunucuların sağlık kontrollerini geçemeye başlamasına neyin yol açtığını, bir dağıtım veya yapılandırma değişikliğinin rol oynayıp oynamadığını ve tekrarın nasıl önleneceğini açıklamadı; henüz bir olay sonrası inceleme yayımlanmadı.

Azure zarar görmemiş görünüyor. Durum sayfasında aktif olay gösterilmiyordu ve Microsoft, dev.to'nun belirttiği gibi, müşterilerin barındırdığı Azure iş yüklerinde herhangi bir etkiyi doğrulamadı. Güncellemelerde değinilen sanal makineler Microsoft'un kendi Exchange Online altyapısına ait gibi görünüyor, ancak şirket bunu açıkça söylemedi. Bu, olayı 29 Ekim 2025 tarihli Azure Front Door olayından ayırıyor; Microsoft onu uyumsuz yapılandırma meta verisine atfetmişti ve App Service ile SQL Database gibi Azure hizmetlerinin yanı sıra Microsoft 365'i de etkilemişti.

Tepkiler ve yoğunlaşma sorusu

The Register, kesintiyi tek tedarikçiye bağımlılık konusunda bir ders olarak çerçeveledi. Nextcloud kurucu ortağı Jos Poortvliet her şirkette hata yapıldığını ama olayın kuruluşların tek bir ekosisteme ne kadar bağımlı hale geldiğini gösterdiğini savundu; tek tedarikçiye bağlı firmaların hızla sağlayıcı değiştiremeyeceğini ya da yedek olarak ikinci bir kurulum tutamayacağını belirtti. Civo CEO'su Mark Boost, asıl endişenin Microsoft'un kesinti yaşaması değil, kritik altyapının bu kadar az şirket arasında yoğunlaşarak devasa tek hata noktaları yaratması olduğunu söyledi. İngiltere Avameler Bilim ve Teknoloji Komitesi başkanı Chi Onwurah, olayın İngiltere'nin dijital altyapısındaki dayanıklılık eksikliğini gözler önüne serdiğini dile getirdi.

jsweeting.me'deki bir yazı, işletmelerin müşterileri sosyal medyaya yönlendirdiğini, okullarda, üniversitelerde ve mahkemelerde aksamalar yaşandığını ve ofis çalışanlarının günü planlanmamış bir tatil olarak gördüğünü anlattı. Bu anlatılar anonim ama kapsamları, Microsoft'un kendisinin açıkladığı hizmet listesiyle tutarlı.

Neden önemli

Müşteriler, olay ortasında Exchange Online'ı başka bir sağlayıcıya devredemez. Kontrol edebildikleri şey, e-posta ve işbirliği araçları bozulduğunda işin ne kadarının durduğu — The Register'ın belirttiği gibi, bu soru sözleşme yenileme zamanında yeniden gündeme gelmesi muhtemel bir soru.

Platform mühendisleri için olay, sağlık kontrol sisteminin kendisinin de tek hata noktası olabileceğinin bir hatırlatması: tüm bir sunucu filosunu tek seferde devre dışı bırakabiliyorsa, ondaki bir arıza izlediği her şeyi çökertir. Standart savunmalar arasında sağlık kontrollerinin tek seferde kaldırabileceği kapasiteye sınır getirilmesi, her hata alanında yedek kapasite bulundurulması, yük atma ve otomatik duraklatmalı kademeli dağıtımlar sayılabilir.

Microsoft olay sonrası incelemesini yayımlayana kadar, temel tetikleyici — ve zinciri bir yapılandırma değişikliğinin başlatıp başlatmadığı — açık kalıyor.