12 Kasım'da Microsoft 365 kesintisi Exchange, Teams, Copilot ve Defender'ı olumsuz etkiledi

Ne oldu

12 Kasım 2026 Perşembe günü Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot ve Defender XDR dünya genelindeki kuruluşlarda arıza verdi ya da sorunlu çalıştı. Şimdiye kadarki bilgi, dev.to üzerinde yayınlanan bir olay sonrası değerlendirmesinden geliyor; o yazı da BleepingComputer'ın özetlediği Microsoft durum güncellemelerine ve Control Plane'in teknik analizine dayanıyor. Microsoft henüz nihai bir olay sonrası inceleme yayınlamadığı için anlatının bir kısmı teyitten çok yorum olarak değerlendirilmeli.

Admin center'da MO1550821 olarak izlenen ana olay, 18:26 UTC'de Amerika kıtasındaki Exchange Online sorunlarıyla başladı ve ardından diğer bölgelere ile buna bağımlı servislere yayıldı. Aynı gün daha erken saatlerde, 14:45 ile 15:53 UTC arasında süren daha kısa bir Teams olayı yaşandı (TM1550488); iki olayın bağlantılı olup olmadığı konusunda Microsoft'un bir açıklama yapmadığı bildiriliyor.

Microsoft ne dedi

BleepingComputer'ın aktardığı durum güncellemelerine göre Microsoft'un neden açıklaması aşama aşama değişti: önce yüksek yük, ardından bir grup sunucunun beklenmedik şekilde erişilemez hale gelmesi ve kalanlar üzerinde baskı oluşturması, daha sonra da etkilenen sunuculardaki temel bir sürecin bunaltılması. Dikkat çekici olan, toplam trafiğin artmamış olması ve şirketin ilk arızaları neyin tetiklediğini açıklamamış olması. Microsoft, kötü niyetli bir faaliyetin izine rastlamadığını bildirdi.

Çözüm sürecinde dağıtımlar duraklatıldı, trafik yeniden dağıtıldı, sunucular yeniden başlatıldı, sağlık kontrolü yöntemi değiştirildi, son yapılandırma değişiklikleri geri alma adayı olarak incelendi ve posta teslim zaman aşımı süresi 48 saate uzatıldı. Microsoft, 13 Kasım'da Kuzey Amerika ve Avrupa'nın büyük bölümünde iyileşme bildirdi; öğleden sonraya kadar posta kuyruklarının belirgin şekilde kısaldığını duyurdu. 14 Kasım tarihli raporlar servislerin geri geldiğini gösterse de resmi olay kapanışı ve kök neden raporu hâlâ gelmemişti.

Muhtemelen zincirleme bir arıza

Dev.to yazısında aktarılan Control Plane analizi, belirtilerin iyi bilinen bir arıza moduna uyduğunu öne sürüyor: sağlık kontrolleri zorlanan sunucuları rotasyondan çıkarıyor, yükleri kalan sunuculara kayıyor ve onlar da sırayla kontrollerinde başarısız oluyor. Toplam trafik sabit kalmasına rağmen sunucu başına yük sürekli artıyor ve hizmete geri alınan sunucuların yük altında yeniden arızalandığı belirtiliyor. Bu, toparlanmanın dakikalar yerine saatler sürmesini açıklar; ancak ilk arızayı neyin başlattığını açıklamaz — nihai raporun cevaplamak zorunda olduğu soru da tam olarak bu.

Etkilenen kuruluşlar için öneriler

Yazı, burada özetlenen on pratik adım sıralıyor:

• Kayıp postaları mutabık kılın: 12 ve 13 Kasım için posta kuyruğunu ve ağ geçidinizin bounce mesajlarını inceleyin, önemli göndericilerle iletişime geçin.
• Microsoft'a dayanmayan bir iletişim yolu oluşturun: telefon ağacı, ayrı bir mesajlaşma uygulaması veya acil sayfası gibi — ve bunu kimin tetikleyeceğini belgelendirin.
• İki acil erişim hesabı oluşturun: günlük yönetici kimlik bilgilerinden ayrı, güçlü şekilde korunan ve izlenen cloud hesapları.
• Uyarıları ikinci bir kanaldan gönderin; yalnızca etkilenen satıcı üzerinden e-posta ile bildiren izleme, bir kesinti sırasında sizi uyaramaz.
• Dışarıdan izleyin: örneğin bir posta kutusuna e-posta gönderip varlığını doğrulayan küçük bir synthetic test ile; ayrıca servis sağlık akışına abone olun.
• DNS durumunuzu bilin: MX kayıtları, TTL'ler, bölgeyi kimin yönettiği ve sağlayıcı 48 saat sessiz kalırsa gelen postaya ne olacağı. Kesinti sırasında MX kaydı değiştirmek önerilmez; yedek planı önceden yapın.
• Postaya bağımlı her şeyi haritalayın: parola sıfırlama, iki adımlı doğrulama kodları, faturalama ve destek talepleri dahil — ve hangilerinin ikinci bir yola ihtiyacı olduğuna karar verin. Senaryoyu kısaca prova edin: posta ve Teams kaybolursa çalışanlarınıza ve müşterilerinize nasıl ulaşacaksınız?
• Zararı belgelendirin: süre, etkilenen süreçler ve maliyetler dahil; servis seviyesi kredilerinin geçerli olup olmadığını ve taleplerin hangi tarihe kadar yapılabileceğini kontrol edin.
• Hangi birkaç kritik fonksiyonun (acil iletişim, uyarı ve kimlik bilgisi kurtarma gibi) ikinci bir sağlayıcıda veya self-hosted bir serviste çalıştırılması gerektiğine bilinçli olarak karar verin.

Kaçınılması gereken hatalar

Yazı ayrıca normale dönüşü hızlandırmak için güvenlik ayarlarını gevşetmek, kesinti sırasında DNS'de veya hesaplarda toplu değişiklik yapmak ve nedenle ilgili doğrulanmamış tahminleri müşterilere iletmek konusunda uyarıyor.

Neden önemli

Kesinti, tek bir satıcının etki alanının ne kadar geniş olabileceğini gösteriyor: posta, sohbet, dosyalar, takvimler ve güvenlik tespiti aynı anda olumsuz etkilendi; olayları Defender'da tespit eden ve Teams'te koordine eden kuruluşlar her iki yeteneğini birden kaybetti. Ayrıca etkilenen satıcı üzerinden teslim edilen uyarıların uyarı sayılmadığını, satıcının ilk açıklamalarının soruşturma ilerledikçe sık sık değiştiğini ve toparlanmanın kuyruk boşaltma ile geciken postalardan oluşan uzun bir kuyruğu olduğunu gösteriyor. Microsoft kök neden raporunu yayınlayana kadar zinciri başlatan olay bilinmiyor kalacak.