# Microsoft'un Outlook kurtarma işlemleri trafik altında sürekli başarısız oldu

Published: 2026-11-13

Microsoft'un 12-13 Kasım tarihlerindeki e-posta kesintisi, bir kurtarma döngüsünü ortaya çıkardı: geri dönen sunucular trafik altında tekrar yanıt veremez hale gelebiliyordu. Onaylanan 13 Kasım 11:04:50 UTC kesinti anında, kurtarma Asya Pasifik'in bazı bölgelerinde ilerlemişken, başka yerlerde aralıklı sorunlar ve çalışmalar devam ediyordu. Bu takip, bağımlılıkları ve geciken posta önlemlerini açıklıyor.

Canonical: https://thedailydiff.dev/tr/video/2026-11-13-microsoft-recovery-loop/

## Bu video neleri kapsar

- Her işlemin arka uç bağımlılığını kontrol edin: temel Teams işlevlerinin çoğu ve doğrudan SharePoint dosya erişimi çalışmaya devam ederken, Exchange'e bağımlı özellikler bozuldu.
- Microsoft, geri dönen sunucuların trafik onlara ulaştığında tekrar yanıt veremez hale gelebileceğini bildirdi; sağlık işleme bileşeni açıklaması bir hipotez olarak kaldı.
- Uzatılmış kırk sekiz saatlik e-posta zaman aşımı, kuyruk ve birikim işleme sırasında geciken postayı korumak içindi. Bu bir onarım son teslim tarihi veya evrensel bir teslimat garantisi değildi.
- Sıradan Graph kısıtlama kılavuzu, Retry-After ve bu başlık yoksa üstel geri çekilmeyi onurlandırmayı önerir; bu olayı teşhis etmez veya onarmaz.

## Sorular ve cevaplar

### Microsoft'un geri dönen posta sunucuları trafik altında neden tekrar başarısız olabildi?

Microsoft, geri dönen sunucuların trafik aldıklarında tekrar yanıt veremez hale gelebileceğini bildirdi. Soruşturması, aşırı yüklenmiş süreçleri ve sunucu sağlığını işleyen bir bileşende olası bir sorunu tanımladı, ancak ilk tetikleyici hala nihai bir olay raporunu bekliyordu. Bu bölüm, bildirilen geri dönüş, çalışma ve nüks dizisini kavramsal olarak açıklıyor; kanıtlanmış bir iç mimari veya nihai kök neden iddiasında bulunmuyor.

### Takvim özellikleri başarısız olurken Teams aramaları neden çalışabildi?

Microsoft'un genişletilmiş hizmet sağlık bildirimine göre, temel Teams aramaları, toplantıları ve sohbetleri çalışmaya devam etti. Takvim ve zamanlama senaryoları Exchange Online'a bağımlıydı ve kesinti sırasında başarısız olabiliyordu. Doğrudan SharePoint dosya erişimi de çalışmaya devam etti. Kullanışlı uygulama düzeyindeki ayrım, bir ürün logosu altındaki her özelliğin aynı arıza durumunu paylaştığını varsaymaktan ziyade, bir işlemin arkasındaki bağımlılıktır.

### Kırk sekiz saatlik e-posta zaman aşımı bir onarım son teslim tarihi belirledi mi?

Microsoft, kuyruk ve birikim işlemeye öncelik verirken geciken mesajları korumak için e-posta zaman aşımı penceresini uzattı. Bu, kurtarma sırasında geciken postalara daha fazla zaman verdi. Kamuoyu bildirimi kırk sekiz saatlik bir onarım son teslim tarihi veya her mesajın alıcısına ulaşacağına dair bir garanti sunmadı. Bu nedenle, bekleyen veya kuyruğa alınmış bir bildirim, zaman açısından hassas bir iş akışının ona güvenmeden önce gerçek bir teslimat veya sonuç kontrolü gerektiriyordu.

### Exchange kesintisi Microsoft Graph uygulamalarını nasıl etkiledi?

Microsoft'a göre, Exchange Online posta, takvim ve kişiler için istekler zaman aşımına uğrayabilirdi. Bir uygulama, farklı temel bağımlılıklara sahip işlemler arasında farklı sonuçlarla karşılaşabilirdi. Bu bölüm, işlemin gerçek hizmet bağımlılığını kontrol etmeyi önerir. Microsoft'un ayrı sıradan kısıtlama belgeleri, Retry-After ve bu başlık yoksa üstel geri çekilmeyi onurlandırmayı tartışır; bu politikalar bu olayın nedenini belirlemez veya geri yüklenen hizmeti vaat etmez.

### The Daily Diff'in Microsoft'un kurtarma süreci hakkındaki kararı neydi?

The Daily Diff'in kararı İNCELENMELİDİR idi. Niko, Microsoft'un güncellemelerinin geri dönen sunucuların trafik altında başarısız olduğunu gösterdiğinden kurtarma sürecini incelemeye devam etti. Gerçek işin gelmeye devam ettiği sürekli hizmet, kullanışlı kurtarma testiydi. İlk neden, bölümün raporlama kesintisinde açık kaldı, Microsoft hafifletmeden sonra tam bir olay raporu ve derinlemesine savunma eylemleri vaat etti.

## Bölümler

- 0:00 Geri dönen sunucular neden tekrar başarısız oldu?
- 0:19 Hangi özellikler Exchange'e bağlıydı?
- 1:03 Kapasite eksikliği bir hizmeti nasıl aşırı yükler?
- 1:34 Microsoft ilk neyi denedi?
- 2:48 Raporlama kesintisinde ne biliniyordu?
- 3:17 Bir Graph isteği neden başarısız olabilirdi?
- 4:05 48 saatlik posta penceresi ne kazandırır?
- 4:48 Sürekli kurtarma neyi kanıtlamalıydı?

## Çevrilmiş deşifre

Orijinal İngilizce anlatımdan çevrilmiştir. Mevcut ses ve altyazılar YouTube tarafından kontrol edilir.

### Geri dönen sunucular neden tekrar başarısız oldu?

0:00 Microsoft posta sunucularını tekrar hizmete soktu. Trafik geri döndüğünde tekrar yanıt vermeyi durdurabilirlerdi. İşte geliştirici takibi. Bu videoda, kurtarma neden sürekli başarısız oldu? Ve uygulamanızın hangi kısımları hala çalışıyordu? Microsoft ayrıca geciken e-postaya kırk sekiz saat verdi. Bu aslında size ne kazandırır? Bugün 13 Kasım Cuma ve bu The Daily Diff.

0:18 Exchange Online, Microsoft'un barındırılan e-posta hizmetidir ve diğer Microsoft üç

### Hangi özellikler Exchange'e bağlıydı?

0:22 yüz altmış beş özelliği buna bağlıdır. İşte Microsoft'un durum sayfasından kullanışlı ayrım. Teams aramaları ve grup sohbetleri çoğunlukla çalıştı. Takvim özellikleri ve posta kutusu verileri istekleri başarısız olabiliyordu. Uygulamanızın gerçekten kullandığı bağımlılığı kontrol edin. Bu, takvim işbirliği yapmayı reddederken bir toplantının hala gerçekleşebileceği anlamına gelir. SharePoint'teki dosyalara doğrudan erişim de çalışmaya devam etti, bazı paylaşım özellikleri etkilenirken.

0:42 Penceredeki logo, bir sonraki tıklamanızın hangi arka uca ihtiyacı olduğu hakkında çok az şey söyler. Kesinti Perşembe günü başladı ve Microsoft başlangıçta Amerika'daki posta kutusu erişimini araştırıyordu. Daha sonra herhangi bir bölgedeki kullanıcıların etkilenebileceğini doğruladı. CNN, bankalar, hükümetler ve mahkemeler arasında sorunlar bildirdi. Eksik bir e-posta, birinin gerçek işi onun gelmesine bağlı olana kadar sakıncalıdır. Microsoft'un erken açıklaması, mevcut sunucuların kaybıydı.

### Kapasite eksikliği bir hizmeti nasıl aşırı yükler?

1:06 Bu makinelerin halletmesi gereken iş, kalan altyapıyı zorladı. Kapasitesi ortadan kalktığında, bir hizmeti sıradan taleple aşırı yükleyebilirsiniz. Kimse aniden e-posta gönderme tutkusunu keşfetmese bile kuyruk uzar. Şirket daha sonra otomatik sağlık kontrollerini araştırdı. Bu kontroller, bir sunucunun iş alıp alamayacağına karar vermeye yardımcı olur. Microsoft, sunucu sağlığını işleyen bir bileşenin dahil olabileceğini söyledi. Bu, hala devam eden bir soruşturmadan bir hipotezdir. Bu sunucuların ilk başta tam olarak neden kullanılamaz hale geldiğini açıklayan nihai bir olay raporumuz yok.

1:29 Güncellemeler, kademeli olarak kahvaltıya daha az ilgi duyan bir görevli vardiyası gibi okunuyor. Dağıtımları duraklatın.

### Microsoft ilk neyi denedi?

1:37 Trafiği hareket ettirin. Sunucuları yeniden başlatın. Microsoft, bir alt kümeyi geri getiren alternatif bir sağlık kontrolünü doğruladı ve yanıt vermeyen makineleri tespit etmek ve yeniden başlatmak için otomatik sistemler hazırladı. Her güncelleme, kapasiteyi kurtarma girişimini anlatıyordu. Sonra kurtarma döngüsünü açıklayan satır geldi. Microsoft, hizmete geri dönen sunucuların trafik aldıklarında tekrar yanıt veremez hale gelebileceğini söyledi. Bir makine geri gelebilir, gerçek iş alabilir ve yanıt vermeyi durdurabilir. Bu gözlem, yanıtlardaki herhangi birinin kendinden emin teorisinden daha güçlü bir kanıttır. Aynı sunucuyu bu durumlar arasında resmedin.

1:59 Kullanılamaz. Hizmete geri döndü. Trafik alıyor. Tekrar yanıt vermiyor. Bu, Microsoft'un açıklamasını gösterir. Bu son geçişi neyin tetiklediği hala yanıtsız. Bir yeniden başlatma geçici bir iyileşme sağlayabilir, sunucuyu yenen koşul çözülmeden kalırken.

2:18 Kapatıp tekrar açma tavsiyesi fazla mesai ücretlendirmeye başlar. Mühendisler, iş geri döndükten sonra ne olduğunu kontrol etmek zorundadır. Müşterilerin, hizmetin bir sonraki isteği ve ondan sonrakini çalışmaya devam etmesi gerekir. Microsoft, bazı konumlarda etkilenen altyapıya ulaşan belirli trafiği sınırladı. Ayrıca, yanıt vermeye devam edip etmeyeceklerini test etmek için sunucuların bir alt kümesini önceki bir yapılandırmayı kullanarak yeniden oluşturdu. Bunlar bildirilen hafifletme deneyleriydi. Kurtarma sırasında dağıtımları duraklatmak, bir Cuma dağıtımının orijinal kesintiye neden olduğuna dair bize hiçbir kanıt vermez. Microsoft'un Cuma günkü on bir sıfır dört UTC güncellemesine göre,

2:39 kurtarma eylemleri Asya Pasifik'in bazı bölgelerinde tamamlanmıştı. Trafik kademeli olarak geri dönüyordu, posta kutusu erişimi ve geciken e-posta işleme iyileşiyordu. Bazı kullanıcılar hala aralıklı sorunlarla karşılaşabilir ve başka yerlerde kurtarma devam ediyordu.

### Raporlama kesintisinde ne biliniyordu?

2:48 Bu bizim raporlama kesintimiz. Microsoft, kötü niyetli etkinliğe dair hiçbir kanıtı olmadığını söyledi ve hafifletmeden sonra tam bir olay raporu sözü verdi. Bir kötü adam atamadan önce o raporu beklerdim. İnternet dedektifliği, sayfayı yenilemeyi bile bitirmeden size bir suçlu verebilir. Geliştiriciler için, Microsoft Graph bağımlılığı özellikle gözden kaçırmayı kolaylaştırır. Exchange posta, takvim ve kişiler için istekleri zaman aşımına uğrayabilirdi. Uygulamanız bir işlem için Graph'ı başarılı bir şekilde çağırabilir ve başka bir işlemde başarısız olabilir.

3:10 Başarılı bir ilişkisiz istek, kullanıcınızın ihtiyaç duyduğu posta kutusu işleminin tamamlanıp tamamlanmayacağı hakkında size çok az şey söyler. Durum sayfası bile kendi kaçış yoluna ihtiyaç duydu. Microsoft, olay bilgilerini herkese açık olarak yayınladı çünkü yöneticiler hizmet sağlığını okumak için yönetim merkezini yükleyemeyebilirlerdi. Ne bozuk olduğunu öğrenmek için kontrol paneli, ne bozuk olduğuna bağlı olduğunda,

### Bir Graph isteği neden başarısız olabilirdi?

3:20 kontrol paneli olaya katılmıştır. Bant dışı bir durum bağlantısını hazır bulundurun. Sıradan Graph kısıtlaması için, Microsoft'un kılavuzu, bir istek çok fazla istek yanıtı aldığında yeniden deneme gecikmesini onurlandırmayı ve bu başlık yoksa üstel geri çekilmeyi kullanmayı söyler. Bu kılavuz kısıtlamayı yönetir. Bu kesintiyi teşhis etmez veya yeniden denemelerin hizmeti geri getireceğini vaat etmez. Şimdi kırk sekiz saat. Microsoft'un genişletilmiş durum sayfası, kuyruk ve birikim işlemeye öncelik verdiğini ve geciken mesajları korumak için e-posta zaman aşımı penceresini uzattığını söylüyor.

3:46 Bu, kurtarma sırasında geciken postalara daha fazla zaman kazandırır. Bir posta zaman aşımı penceresi ayarlar. Microsoft, hizmeti düzeltmek için kırk sekiz saatlik bir son teslim tarihi vermedi ve her mesajın ulaşacağına dair bir garanti vermedi. Bu yüzden teslimat iddialarını dürüst tutun. Gecikmiş bir bildirim mutlaka kaybolmuş değildir ve kuyruğa alınmış bir mesaj mutlaka alıcısına ulaşmamıştır. Zaman açısından hassas işler için, sonucu onaylanmış bağımsız bir kanal aracılığıyla doğrulayın.

### 48 saatlik posta penceresi ne kazandırır?

4:05 Arka uç hala iyileşirken bir istemci penceresi iyimser bir teslimat makbuzudur. Bu da nihai olay raporunda okunacak çok şey bırakıyor. Bunu benim söylememden ziyade okumayı tercih ederseniz, diff her sabah gelen kutunuza ücretsiz olarak daily diff dot dev adresinden düşer, link aşağıda. Bugünün kararı, İNCELENMELİDİR. Kurtarma sürecini incelemeye devam ederdim çünkü Microsoft'un kendi güncellemeleri, geri dönen sunucuların trafik altında başarısız olduğunu gösterdi. Kullanışlı test, gerçek işin gelmeye devam ettiği sürekli hizmettir. Nihai rapor gelene kadar, ilk neden açık kalır. Ve bugünün diff'i bu.

4:28 Ben Axrisi'den Niko. Sorumlu bir şekilde birleştirin. Microsoft'un geri dönen posta sunucuları trafik altında neden tekrar başarısız olabildi? Microsoft, geri dönen sunucuların trafik aldıklarında tekrar yanıt veremez hale gelebileceğini bildirdi. Soruşturması, aşırı yüklenmiş süreçleri ve sunucu sağlığını işleyen bir bileşende olası bir sorunu tanımladı, ancak ilk tetikleyici hala nihai bir olay raporunu bekliyordu. Bu bölüm, bildirilen geri dönüş, çalışma ve nüks dizisini kavramsal olarak açıklıyor; kanıtlanmış bir iç mimari veya nihai kök neden iddiasında bulunmuyor. Takvim özellikleri başarısız olurken Teams aramaları neden çalışabildi? Microsoft'un genişletilmiş hizmet sağlık bildirimine göre, temel Teams aramaları, toplantıları ve sohbetleri çalışmaya devam etti. Takvim ve zamanlama senaryoları Exchange Online'a bağımlıydı ve kesinti sırasında başarısız olabiliyordu. Doğrudan SharePoint dosya erişimi de çalışmaya devam etti. Kullanışlı uygulama düzeyindeki ayrım, bir ürün logosu altındaki her özelliğin aynı arıza durumunu paylaştığını varsaymaktan ziyade, bir işlemin arkasındaki bağımlılıktır. Kırk sekiz saatlik e-posta zaman aşımı bir onarım son teslim tarihi belirledi mi?

### Sürekli kurtarma neyi kanıtlamalıydı?

4:49 Microsoft, kuyruk ve birikim işlemeye öncelik verirken geciken mesajları korumak için e-posta zaman aşımı penceresini uzattı. Bu, kurtarma sırasında geciken postalara daha fazla zaman verdi. Kamuoyu bildirimi kırk sekiz saatlik bir onarım son teslim tarihi veya her mesajın alıcısına ulaşacağına dair bir garanti sunmadı. Bu nedenle, bekleyen veya kuyruğa alınmış bir bildirim, zaman açısından hassas bir iş akışının ona güvenmeden önce gerçek bir teslimat veya sonuç kontrolü gerektiriyordu. Exchange kesintisi Microsoft Graph uygulamalarını nasıl etkiledi? Microsoft'a göre, Exchange Online posta, takvim ve kişiler için istekler zaman aşımına uğrayabilirdi. Bir uygulama, farklı temel bağımlılıklara sahip işlemler arasında farklı sonuçlarla karşılaşabilirdi. Bu bölüm, işlemin gerçek hizmet bağımlılığını kontrol etmeyi önerir. Microsoft'un ayrı sıradan kısıtlama belgeleri, Retry-After ve bu başlık yoksa üstel geri çekilmeyi onurlandırmayı tartışır; bu politikalar bu olayın nedenini belirlemez veya geri yüklenen hizmeti vaat etmez. The Daily Diff'in Microsoft'un kurtarma süreci hakkındaki kararı neydi? The Daily Diff'in kararı İNCELENMELİDİR idi. Niko, Microsoft'un güncellemelerinin geri dönen sunucuların trafik altında başarısız olduğunu gösterdiğinden kurtarma sürecini incelemeye devam etti. Gerçek işin gelmeye devam ettiği sürekli hizmet, kullanışlı kurtarma testiydi. İlk neden, bölümün raporlama kesintisinde açık kaldı, Microsoft hafifletmeden sonra tam bir olay raporu ve derinlemesine savunma eylemleri vaat etti. Ben Axrisi'den Niko. Sorumlu bir şekilde birleştirin.

## Kaynaklar

- [ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistorical](https://status.cloud.microsoft/) — Microsoft
- [Returned servers can become unresponsive again once they receive traffic](https://x.com/MSFT365Status/status/2121031935010951521) — Microsoft 365 Status
- [Health-processing component investigation hypothesis](https://x.com/MSFT365Status/status/2120974801388904932) — Microsoft 365 Status
- [Alternative health check returned a subset of servers](https://x.com/MSFT365Status/status/2120985048337830246) — Microsoft 365 Status
- [Isolate, restart and reintroduce traffic to test stability](https://x.com/MSFT365Status/status/2121002505911857577) — Microsoft 365 Status
- [Unavailable servers strain remaining infrastructure](https://x.com/MSFT365Status/status/2120962673911181437) — Microsoft 365 Status
- [Initial Exchange mailbox-access investigation in the Americas](https://x.com/MSFT365Status/status/2120938282204688468) — Microsoft 365 Status
- [Users in any region may be affected](https://x.com/MSFT365Status/status/2120941584220827979) — Microsoft 365 Status
- [Email timeout extended to preserve delayed messages](https://x.com/MSFT365Status/status/2121172248241348867) — Microsoft 365 Status
- [Paused deployments, traffic redistribution and server restarts](https://x.com/MSFT365Status/status/2120957934607700161) — Microsoft 365 Status
- [Independent live reporting on the Microsoft email disruption](https://www.cnn.com/2026/11/12/business/live-news/microsoft-global-outage-intl-hnk) — CNN
- [Microsoft Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) — Microsoft Learn
- [Exchange Online service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description) — Microsoft Learn
- [Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.](https://commons.wikimedia.org/wiki/File:Satya_Nadella.jpg) — OFFICIAL LEWEB PHOTOS
- [Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rights](https://creativecommons.org/licenses/by/2.0/) — Creative Commons
- [WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://imgflip.com/memetemplate/234202281/AJ-Styles--Undertaker) — WWE / Imgflip source hosting
- [The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://giphy.com/gifs/the-simpsons-sideshow-bob-RSOUOj8H9A3Xq) — The Simpsons / 20th Television / Disney; GIPHY source hosting