Microsoft 365 kesintisi, 12–13 Kasım’da birden fazla bölgede e-posta ve yapay zeka bağlantılarını etkileyerek şirketlerin bulut bağımlılığını gündeme taşıdı.
Hızlı bakış
- Kesinti, Outlook erişimini ve e-posta teslimini etkilerken Teams’in bazı Exchange Online bağlantılı işlevlerinde aksamalara yol açtı.
- Anthropic ve OpenAI, Microsoft 365 bağlantılarında sorun bildirdi.
- Exchange Online ileti izleme aracı, yetkili yöneticilerin e-postaların teslim durumunu kontrol etmesini sağlıyor.
- Yönetim merkezinde listelenmeyen hizmet sorunları Report an issue seçeneğiyle bildirilebiliyor.
- Microsoft’un iş sürekliliği rehberi, alternatif iletişim kanallarının önceden belirlenmesini ve kritik belgelerin çevrimdışı kopyalarının tutulmasını öneriyor.
Microsoft’un Pennsylvania Üniversitesi tarafından yayımlanan hizmet durumu kayıtlarına göre, 12 Kasım 2026’da başlayan sorunlar Exchange Online için EX1550543, daha geniş hizmet etkisi için MO1550821 kodlarıyla izleniyor. 13 Kasım Türkiye saatiyle 17.01’de e-posta kuyruklarının azaldığı, 17.57’de toparlanmanın sürdüğü bildirildi; aralıklı erişim sorunları ve teslim gecikmeleri devam edebiliyor. Gelişme, şirketlerin iletişim araçlarıyla yapay zeka uygulamalarının ortak altyapıya bağımlılığını görünür kılıyor.
Microsoft 365 kesintisinde hangi hizmetler etkilendi?
Outlook’un web, masaüstü ve mobil bağlantılarında posta kutusuna erişim ile e-posta teslimi etkilenebiliyor. Teams’te takvim, davet ve toplantı düzenleme gibi Exchange Online’a bağlı işlemler aksarken temel arama, toplantıya katılma ve mesajlaşma işlevlerinin çoğu çalışmayı sürdürdü. SharePoint’te doğrudan dosya erişimi ile e-postaya bağlı işlevlerin durumu da farklılaştı.Bu ayrım, kesinti haberlerini işletmeler açısından değerlendirirken önem taşıyor. Bir uygulamanın açılması, o uygulama üzerinden yürütülen bütün işlerin tamamlanabildiğini göstermiyor. Toplantıya katılabilmek ile yeni davet gönderebilmek; bir belgeyi görüntülemek ile onu başka bir iş akışına aktarabilmek farklı hizmetlere bağlı olabiliyor.Microsoft ilk kayıtlarda bağlantı hataları ve birden fazla bölgede yüksek yük bildirdi; bunlar kesin kök neden açıklaması değil, inceleme sırasındaki gözlemlerdi. Şirket, 13 Kasım güncellemesinde kötü niyetli faaliyet bulgusu bulunmadığını ve ayrıntılı kök neden ile düzeltici adımları olay sonrası raporda paylaşacağını belirtti.
E-postanın gönderilmiş görünmesi, alıcıya ulaştığını tek başına doğrulamıyor. Yapay zeka ile üretilmiş temsili illüstrasyon.
Copilot, Claude ve ChatGPT neden aynı dosyanın parçası?
Microsoft’un etki listesinde Copilot Chat’e erişim ve yanıt alma sorunları ile e-posta, takvim ve dosyalar gibi kurumsal verilere ulaşamama ihtimali de yer alıyor. Böylece posta altyapısındaki aksama, bu verilerle çalışan yapay zeka özelliklerine uzanıyor.
Anthropic’in Microsoft 365 bağlantısına ilişkin olay kaydı, 12 Kasım saat 18.34 UTC’de sorunu bir üst sağlayıcıya bağladı. Aynı gün 22.23 UTC’deki güncelleme ise Microsoft 365 hizmet olayını açıkça adlandırdı; bağlantı üzerinden kullanılan e-posta, takvim ve arama araçlarının çoğu istekte başarısız olduğunu ve Claude for Outlook’un etkilendiğini bildirdi. Kayıtta claude.ai ve Claude Cowork etkilenen bileşenler olarak yer alıyor. Önceki güncellemelerde posta, SharePoint, Teams sohbeti ve takvim istekleriyle yeni bağlantı kurma işlemlerinin başarısız olabileceği de belirtiliyor.
OpenAI’nin 12 Kasım tarihli Microsoft bağlantıları olay kaydı ise yeni bağlantıların kurulamaması ve araçların beklendiği gibi çalışmaması ihtimalini bildiriyor. Etkilenen bileşen ChatGPT’nin bağlantılar ve uygulamalar bölümü olarak gösteriliyor. Bu kayıt sorunun kaynağını ayrıca Microsoft olarak tanımlamıyor.
Modelin çalışması, işin tamamlandığı anlamına gelmiyor
Bu kayıtların birlikte gösterdiği nokta, yapay zeka hizmetlerinde kullanılabilirliğin yalnızca modelden yanıt almakla ölçülemeyeceği. Bir asistan metin üretebilirken gerekli e-postaya ulaşamayabilir, takvimi okuyamayabilir veya kullanıcı adına istenen işlemi tamamlayamayabilir. Kurumsal kullanımda değer, bu adımların birlikte çalışmasına bağlı.
Yeşil Haber’in yapay zekanın üretim altyapısına dönüşmesini ele aldığı dosyada tartışılan iş akışı yaklaşımı burada da önem kazanıyor. İşletmenin satın aldığı farklı uygulamalar aynı posta kutusuna veya aynı erişim hizmetine dayanıyorsa, uygulama sayısının artması tek başına bağımsızlık sağlamıyor. Bu, olay kayıtlarından hareketle yapılan bir editoryal çıkarım; bütün yapay zeka hizmetlerinin aynı altyapıda çalıştığı iddiası değil.
“Gönderildi” görünen e-postanın teslimi nasıl kontrol edilir?
İşletmeler açısından en zor durumlardan biri, e-postanın gönderilmiş görünmesine rağmen karşı taraftan yanıt alınamaması. Böyle bir durumda yalnızca gönderilen öğeler klasörüne bakarak teslim sonucuna karar vermek yerine, sunucu tarafındaki ileti kaydı incelenmeli.
Microsoft’un Exchange Online ileti izleme belgesine göre, yetkili yöneticiler Exchange yönetim merkezindeki Posta akışı ve İleti izleme bölümlerinden mesajın hizmet tarafından alınıp alınmadığını, ertelenip ertelenmediğini, reddedilip reddedilmediğini veya teslim edilip edilmediğini kontrol edebiliyor. Arama, gönderici ve alıcı adresleriyle zaman aralığı üzerinden yapılabiliyor.
Bu işlem için gerekli yönetim yetkileri gerekiyor. Exchange yöneticisi veya uygun Exchange Online yönetim rolüne sahip bir kişi kontrolü yapabiliyor. KOBİ’lerde bu kişi kurumun bilgi işlem sorumlusu ya da yetkilendirilmiş dış hizmet sağlayıcısı olabilir; normal kullanıcı hesabıyla yönetici ekranlarına erişim beklenmemeli.
Kayıtlardaki Pending, teslimin denendiğini veya yeniden denendiğini; Failed, iletinin teslim edilemediğini; Delivered ise hedefe teslim edildiğini ifade ediyor. Pending filtresi, on günden kısa aramalarda kullanılabiliyor. Microsoft ayrıca izleme ekranındaki durumun gerçek teslim durumunu yansıtmasında beş ila on dakikalık gecikme olabileceğini belirtiyor.
Dış alıcılarda hedef posta sistemine teslim, iletinin gelen kutusunda görünmesiyle aynı şey değil. Teslim ayrıntılarında hedef sunucuya aktarım kontrol edilmeli; alıcının spam, karantina veya yönlendirme kuralları ayrıca incelenebilir. Microsoft’un ileti izleme hakkında sık sorulan sorular belgesi de filtreleme, yönlendirme ve hedefte uygulanan kuralların araştırılması gerektiğini açıklıyor. Delivered kaydı, mesajın okunduğunun kanıtı değil.
Yeşil Haber’in işletmeler için önerisi, kritik yazışmalarda gönderim zamanı, alıcı ve varsa hata bildirimini bir arada tutmak. Teslim durumu belirsiz mesajların topluca yeniden gönderilmesi yerine, öncelikli iletiler ayrı ayrı kontrol edilmeli. Süreye bağlı bir teklif, sevkiyat teyidi veya toplantı değişikliği söz konusuysa, kurumun onayladığı alternatif iletişim kanalından alıcıya ulaşmak işin beklemesini önleyebilir.
Microsoft’a ayrıca sorun bildirimi yapmak gerekiyor mu?
Microsoft’un hizmet sağlığı rehberi, destek başvurusu veya yerel sorun giderme işleminden önce yönetim merkezindeki Sağlık ve Hizmet durumu bölümünün kontrol edilmesini öneriyor. Burada kurumla ilgili olayların kapsamı, etkilenen hizmetler, güncellemeler ve yapılması gereken işlemler görülebiliyor.
Yönetim merkezine erişilemiyorsa Microsoft’un kamuya açık hizmet durumu sayfası kullanılabiliyor. Rehber, X üzerindeki Microsoft 365 Status hesabını da bazı olayların duyurulduğu ek kanal olarak gösteriyor. Kamuya açık açıklamalarla kurumun kendi hizmet durumu kayıtları birlikte değerlendirilmeli.
Yaşanan sorun hizmet durumu ekranında listelenmiyorsa, yönetici Report an issue seçeneğiyle bildirim yapabiliyor. Microsoft bu bildirimleri diğer kuruluşların raporları ve hizmet verileriyle birlikte inceleyerek sorunun yaygınlığını değerlendiriyor. Dolayısıyla genel kesintiyi takip etmek ile kuruma özgü, açıklanmamış bir sorunu bildirmek birbirini tamamlayan işlemler.
İşletmeler için pratik yaklaşım, çalışanlardan gelen örnekleri tek bir sorumlu üzerinden toplamak. Genel toparlanma açıklamasına rağmen belirli hesaplarda erişim veya teslim sorunu sürüyorsa, ilgili olay kodu, zaman bilgileri ve hata kayıtlarıyla destek süreci yürütülebilir. Böylece genel hizmet sorunu ile ayrıca incelenmesi gereken yerel bir aksaklık birbirinden ayrılabilir.
Bulut bağımlılığı sürdürülebilirlik açısından neyi gündeme getiriyor?
Bu olayın sürdürülebilirlik boyutu, kurumların dijitalleşirken kritik faaliyetlerini ne kadar dayanıklı hale getirdiğiyle ilgili. Yeşil Haber’in değerlendirmesine göre verimlilik hesabına, olağan koşullardaki hız ve maliyetin yanında kesinti sırasında sürdürülebilen işler ve normal düzene dönüş kapasitesi de dahil edilmeli. Buradaki çerçeve, ölçülmüş bir çevresel etki değil, kurumsal faaliyetlerin devamlılığı ve risk yönetimi.
Microsoft’un iş sürekliliğinde sorumluluk paylaşımını açıklayan belgesi, hizmet sağlayıcının görevleri ile müşterinin görevlerini birlikte ele alıyor. Microsoft hizmetleri sağlarken, müşteri kuruluş kullanıcı cihazlarının bağlantısını, kimlik ve erişim yönetimini ve hizmetlerin nasıl kullanılacağını yönetiyor. Kimlik ve dizin altyapısı gibi alanlarda ortak sorumluluklar da bulunuyor.
Bu çerçeve, müşterinin sağlayıcı tarafındaki arızayı giderebileceği anlamına gelmiyor. Kurumun sorumluluğu, o arıza sürerken hangi faaliyetleri hangi yöntemle devam ettireceğini önceden belirlemek. E-posta, dosya erişimi, müşteri iletişimi ve yapay zeka araçlarının aynı hizmete hangi noktalarda bağımlı olduğunun bilinmesi, bu planın başlangıcı.
Elektrik kapasitesi ile hizmet sürekliliği nasıl ayrılıyor?
Yeşil Haber’in Microsoft ve Nscale’in Loughton veri merkezi anlaşmasına ilişkin haberinde elektrik şebekesine bağlantı takviminin yatırım üzerindeki etkisi ele alınmıştı. Bu dosya ise kullanılan dijital hizmetlerin erişilebilirliğine odaklanıyor. Veri merkezi yatırımlarının fiziksel altyapısı ile o altyapı üzerinde çalışan hizmetlerin sürekliliği, farklı riskler taşıyor.
İki dosyayı birlikte okumak, dijital dönüşümün hem enerji altyapısını hem hizmet tasarımını kapsadığını gösteriyor. Ancak mevcut Microsoft 365 olay kayıtları bu kesintiyi elektrik yetersizliğine bağlamıyor. Kesintinin enerji tüketimi veya emisyon üzerindeki etkisine ilişkin doğrulanmış bir ölçüm de bu yazının kaynaklarında bulunmuyor.
Şirketler kesinti sonrasında hangi hazırlıkları yapmalı?
Microsoft’un iş sürekliliği planlama rehberi, önce kritik işlerin ve bu işlerin bağlı olduğu hizmetlerin belirlenmesini öneriyor. Ardından süreçler arasındaki bağımlılıkların incelenmesi, alternatiflerin planlanması, planın denenmesi ve çalışanların hazırlanması gerekiyor. Rehber, kesinti anında kullanılacak iletişim kanallarının önceden seçilmesini ve kritik belgelerin çevrimdışı kopyalarının bulundurulmasını da kapsıyor.
Aynı rehber, e-posta aksadığında alternatifler arasında Teams ve Viva Engage’i de sayıyor. Bu olayda Teams’in takvim ve davet işlevlerinin etkilenmesi, yedek kanalın hangi işlevlerinin ana kanalla ortak altyapıya dayandığının ayrıca sınanması gerektiğini gösteriyor. Bu gözlem Teams’in bütün iletişim işlevlerinin durduğu anlamına gelmiyor.
Öncelik, kritik işi devam ettirebilmek
Bir işletme için bütün uygulamaların aynı anda geri gelmesini beklemek yerine, öncelikli işleri belirlemek daha uygulanabilir bir hazırlık sağlayabilir. Müşteri talebinin alınması, sevkiyatın onaylanması veya gün içindeki görevlerin dağıtılması için gereken asgari iletişim kapasitesi tanımlanmalı. Bu süreçlerin sorumlusu ve alternatif yöntemi çalışanlar tarafından bilinmeli.
Yeşil Haber’in önerisi, alternatifleri uygulama adlarına göre değil, yerine getirdikleri işe göre sınamak. Örneğin bir yedek iletişim kanalının açılabilmesi yeterli olmayabilir; ilgili kişinin o kanala erişebilmesi, gerekli iletişim bilgilerine ulaşması ve kararın kayda alınması da gerekir. Yapay zeka destekli bir işte ise otomatik işlem tamamlanamadığında kimin devralacağı belirlenmeli.
Toparlanma sonrasında bekleyen işler de kontrol edilmeli
Hizmet erişiminin geri gelmesi, kesinti sırasında bekleyen bütün işlerin tamamlandığını tek başına göstermez. Kurumlar kendi süreçlerine göre teslimi belirsiz iletileri, ertelenen onayları ve tamamlanmamış otomatik işlemleri gözden geçirebilir. Olay sonrası incelemenin amacı, yalnızca arızanın süresini kaydetmek değil, bir sonraki kesintide hangi işin daha az aksayacağını belirlemek olmalı.
Bu kesinti neyi göstermiyor?
Hizmetlere erişilememesi tek başına veri kaybını veya veri sızıntısını kanıtlamaz. Microsoft 365 bağlantısındaki arıza da bütün ChatGPT ya da Claude hizmetlerinin aynı nedenle durduğu anlamına gelmez. Bir kuruluşun etkilenme düzeyi, kendi hizmet durumu ve işlem kayıtlarıyla değerlendirilmelidir. Bu yazıda esas alınan en yeni Microsoft olay güncellemesi, 13 Kasım 2026 Türkiye saatiyle 17.57 tarihli Exchange Online kaydıdır; bu kayıtta tam düzelme ilan edilmiyor.
Siz ne düşünüyorsunuz?
Kurumunuzda e-posta ve ona bağlı yapay zeka araçları erişilemez hale geldiğinde kritik işleri sürdürecek alternatif süreçler önceden belirlenmiş mi?
Kaynaklar
Microsoft, EX1550543 ve MO1550821 hizmet durumu duyuruları, Pennsylvania Üniversitesi PennO365 kayıt aktarımı, 12–13 Kasım 2026.
Anthropic, Elevated errors affecting the Microsoft 365 connector, 12 Kasım 2026; son görülen güncelleme: 22.23 UTC.
OpenAI, Elevated errors affecting the Microsoft 365 connector, 12 Kasım 2026.
Microsoft Learn, Message Trace FAQ in Exchange Online, erişim: 13 Kasım 2026.
Microsoft Learn, How to check Microsoft 365 service health, güncelleme: 9 Şubat 2026.
Microsoft Learn, Developing your business continuity plan, 29 Eylül 2025.
Yeşil Haber, Trilyon dolarlık AI yarışı enerjiyi yeni ekonomik güç haline getiriyor, 6 Mayıs 2026.
İlgili haberler
- Yapay zeka sürdürülebilirliği: Mythos ve Hugging Face eşiği
- PHP2Shell alarmı: Enerji altyapısının görünmeyen katmanı ve yapay zekâ çağında güvenlik
- Fransa’da soğutma sistemlerine siber saldırı: Akıllı cihazlarda kontrol kimde?
- Microsoft, şebeke gecikmesi yaşanan Loughton veri merkezi anlaşmasından çekildi
- Karanlıkta kalan kavşak: San Francisco kesintisi, Waymo robotaksileri ve Türkiye’nin otonom trafik sınavı
