Günlerce süren Exchange Online kesintisi Outlook, Copilot ve Purview'u etkiledi, kök neden hâlâ belirsiz

12 Kasım 2026'da başlayan bir Microsoft 365 olayı, 14 Kasım itibarıyla hâlâ çözülmemiş durumdaydı; teamvoy'un dev.to'daki yazısına göre EX1550543 ve MO1550821 olayları hâlâ açıktı ve yayımlanmış bir kök neden yoktu. Arıza Exchange Online'da başladı, ancak etkileri e-postanın çok ötesine uzandı: Copilot, Defender for Office 365, Purview DLP ve eDiscovery, Planner, To Do, yönetim merkezinin bazı bölümleri ve Teams takvim işlevleri de posta hizmetiyle birlikte bozulma yaşadı.

Tek bağımlılık, birçok belirti

dev.to zaman çizelgesinin açıkladığı gibi bağlayıcı ipucu şudur: Bu hizmetlerin her biri Exchange Online'dan veri okur. Bu yüzden aynı saat içinde posta teslimatı tıkanırken Teams grup sohbetleri çalışmaya devam edebildi; ancak Exchange'e dokunan takvim davetleri ve kişi aramaları başarısız oldu. Web, masaüstü ve mobil Outlook bağlantılarının (MAPI, ActiveSync, REST) tümü erişimini kaybetti ve posta, takvim ya da kişilerle ilgili Microsoft Graph istekleri etkilendi. Teams aramaları, toplantıları ve kanal mesajları ile doğrudan SharePoint Online'da depolanan dosyalar büyük ölçüde çalışmaya devam etti, çünkü bunlar Exchange'e bağlı değildir.

İki günde dört açıklama

Microsoft'un kamuya açık anlatımı olay sırasında dört kez değişti ve sıralama tek tek yapılan açıklamalardan daha önemli:

• Önce birden fazla bölgede artan yükten söz etti, ardından baskının sunucuların kullanılamaz hale gelmesinden kaynaklandığını açıkladı — trafik artışından değil, olağan talep altında kapasitenin yok olmasından.
• Ardından sunucuların otomatik sağlık denetimlerinde başarısız olduğunu, bunun nedeninin belki de bu denetimleri işleyen bir bileşen olabileceğini söyledi ve soruşturma sürerken dağıtımları ve yapılandırma değişikliklerini dondurdu.
• Sonrasında, kalan sunucularda güvenli bağlantı kuran bir sürecin bunaldığı ve bu sunucuları da istek yolundan çıkardığı bildirildi.
• Son olarak, etkilerin başlangıcıyla örtüşen güncel bir ağ yapılandırma değişikliği tespit etti ve gece boyunca bu değişikliği geri almaya başladı.

Bu son açıklama, daha önceki bir açıklamayı tersine çeviriyor: Microsoft, 12 Kasım saat 19:57 UTC'de, etkilerin başlangıcıyla ilişkili güncel bir değişiklik olmadığını söylemişti. Olay kaydındaki kök neden alanı hâlâ boş ve bir korelasyon, kanıtlanmış bir neden değildir. Microsoft ayrıca kötü niyetli bir faaliyetten haberdar olmadığını defalarca belirtti — bu, kapatan bir bulgu değil, mevcut bilgisiyle ilgili bir beyan.

Olay nasıl gelişti

Gün aslında ayrı bir Teams olayıyla başladı: TM1550488, 14:45 ile 15:53 UTC arasında Amerika kıtasındaki kullanıcıları gecikmeli sohbetler ve durum sorunlarıyla etkiledi ve ön değerlendirmeyle kaynak çekişmesine bağlandı. Exchange sorunu başlamadan kapatıldı ve Microsoft ikisini ilişkilendirmemiş olsa da, dev.to'ya göre birçok haber kapsamı ikisini birleştirdi.

Saat 16:17 UTC'de EX1550543, kullanıcılar Exchange Online posta kutularına erişimi kaybettikçe açıldı. Microsoft bağlantı trafiğini yeniden dağıttı, dağıtımları durdurdu ve saat 19:00 civarında sunucuları yeniden başlattı; alternatif bir sağlık denetimi, sunucuların bir alt kümesini saat 21:00 civarında geri getirdi. Şirket saat 22:11'de yaptığı işlemlerin beklenen rahatlamayı sağlamadığını kabul etti ve kurtarılan sunucular o akşam yük altında yeniden yanıt vermemeye başladı. Kurtarma çalışması 13 Kasım'a kadar sürdü: ön uç sunucuları saat 06:12 UTC'de hâlâ geri yükleniyordu ve Microsoft saat 12:30 itibarıyla ilerleme kaydedildiğini bildirirken aralıklı sorunların sürebileceği konusunda uyardı.

Hasarı dikkatlice saymak

Yazıdaki iki uyarıyı tekrarlamaya değer. Haberlerde dolaşan "450 milyon kullanıcı" rakamı Microsoft'un toplam kullanıcı tabanıdır, etkilenen müşteri sayısı değildir; Downdetector'daki yaklaşık 130.000 Outlook bildirimi de kullanıcı bildirimleridir, doğrulanmış kesintiler değil. Geciken postalar 48 saatlik yeniden deneme penceresiyle korundu, bu nedenle yöneticilerin mesajların kaybolduğunu varsaymak yerine geç gelenleri kontrol etmeleri öneriliyor. Sonuçlar, e-postanın bir kolaylık değil bir kontrol mekanizması olduğu yerlerde en keskin biçimde hissedildi: halka açık bir şirket kazanç bildirisini erteledi ve bir ilçe şerif bürosu kefalet ödemelerini şahsen almaya geri döndü.

Neler izlenecek

Microsoft'un hizmet açıklaması, çok sayıda kuruluşu etkileyen olaylar için çözümden sonra 48 saat içinde ön rapor ve beş iş günü içinde nihai rapor taahhüt ediyor — bu, bu olay için bir öngörü değil, beyan edilmiş bir politika. dev.to yazısı üç açık soruya işaret ediyor: geri alınan ağ değişikliği başlatan kusur muydu yoksa bir tesadüf mü; otomatik sağlık denetimleri kapasiteyi kurtarmanın geri kazandıramayacağı hızda neden düşürdü; ve bunun sonucunda dağıtım durdurma ile trafik yönlendirmede neler değişecek.

Neden önemli

Olay, amiral gemisi bir SaaS paketinin içindeki gizli bağlılığın canlı bir göstergesi: güvenlik araçları, uyum hatları ve toplantı planlamasının tümü tek bir posta platformunun aşağı akışında yer alıyordu ve birçok kuruluşun bundan görünüşe göre haberi yoktu. Yazının pratik dersleri şunlar: yedeklilik satın almadan önce bağımlılıkları haritalamak; durum bildirimleri, çağrılama ve yasal düzenleme bildirimlerine Exchange'e bağlı olmayan bir yol vermek; ve iş akışlarını, e-posta bildirimleri zarif biçimde bozulurken e-posta kapılı süreçlerin sesli biçimde başarısız olup bir insana yönlendirilmesini sağlayacak şekilde tasarlamak. Yazı ayrıca Microsoft'un kendi kurtarma sürecinin de istikrarsız olduğuna — geri dönen sunucuların yeniden düştüğüne — dikkat çekiyor; bu da uzun bir Exchange bozulmasını, sonrasındaki uzlaştırma çalışması dahil prova etmeyi her kiracı için mantıklı bir alıştırma haline getiriyor.