Merhaba
12-13 Kasım 2026 tarihlerinde yaşanan Microsoft 365 kesintisi, Exchange Online, Outlook, Microsoft Teams, SharePoint Online ve Microsoft 365 Copilot gibi kritik servislerde erişim ve hizmet sorunlarına yol açtı. Service Health ekranında görünen olay kayıtlarından bazıları şunlardı: EX1550543 (Exchange Online), MO1550821 (Microsoft 365 Services) ve TM1550488 (Microsoft Teams).
Kesinti günleri geride kaldığında IT ekiplerinin gündemi genellikle sorunun kök nedenine ve kullanıcılara verilen yanıta kayıyor. Oysa bulut hizmetlerinde ikinci bir soru daha var: Bu kesinti, Microsoft’tan Hizmet Kredisi (Service Credit) talep etmemizi sağlayacak kadar büyük mü? Bu yazıda, Microsoft’un Kasım 2026 sürümü Çevrimiçi Hizmetler Hizmet Düzeyi Anlaşması (SLA, Service Level Agreement) belgesini esas alarak bu sorunun cevabını, hesaplama mantığını ve talep sürecini adım adım ele alıyorum.
SLA belgesi neyi taahhüt ediyor?
Microsoft, Çevrimiçi Hizmetler için SLA’yı toplu lisanslama anlaşmanızın bir parçası olarak sunuyor. Belgenin ana fikri şu: Bir hizmet için taahhüt edilen Hizmet Düzeyi karşılanmazsa, o hizmete ödediğiniz aylık ücretin belirli bir yüzdesi kadar krediye hak kazanabilirsiniz. Belgenin en güncel sürümüne aka.ms/CSLA adresinden ulaşabilirsiniz. Ben bu yazıda 1 Kasım 2026 tarihli sürümü kullandım.
Aboneliğinizin ilk sözleşme döneminde SLA hükümlerinin değiştirilmeyeceği, ancak aboneliği yenilerseniz yenileme sırasında geçerli olan sürümün uygulanacağı da belgede yer alıyor. Esasa ilişkin olumsuz değişiklikler için en az 90 gün önceden bildirim yapılacağı belirtiliyor.
Hangi hizmette hangi durum ‘kesinti’ sayılıyor?
SLA’da kesintinin karşılığı olan terim Çalışmama Süresi. Bu terim her hizmet için ayrı tanımlanıyor ve bu ayrım çok önemli, çünkü sizin yaşadığınız sorun ile SLA’nın saydığı sorun her zaman aynı şey değil.
Aşağıdaki tablo, bu yazıdaki hizmetler için belgedeki tanımları ve kredi eşiklerini özetliyor.
| Hizmet | SLA’ya göre Çalışmama Süresi (kesinti) tanımı | Kredi eşikleri |
|---|---|---|
| Exchange Online | Kullanıcıların Outlook Web Access (OWA, yani Outlook on the web) ile e-posta gönderemediği veya alamadığı süre. Bu hizmet için planlı kesinti yoktur. | < %99,9: %25 | < %99: %50 | < %95: %100 |
| Microsoft Teams | Son kullanıcıların anlık mesajlaşma görüşmeleri yapamadığı veya çevrimiçi toplantı başlatamadığı süre. | < %99,9: %25 | < %99: %50 | < %95: %100 |
| SharePoint Online | Kullanıcıların, izinli oldukları bir site topluluğunun herhangi bir bölümünü okuyamadığı veya yazamadığı süre. | < %99,9: %25 | < %99: %50 | < %95: %100 |
| Microsoft 365 Copilot | Lisanslı kullanıcının Copilot Sohbeti’nde geçerli bir istem girmesine rağmen, LLM (Large Language Model, büyük dil modeli) kaynaklı sunucu tarafı hatası nedeniyle başarısız yanıt alması. Ölçüm, başarısız yanıt yüzdesi üzerinden yapılır. | < %99,5: %25 | < %99: %50 | < %95: %100 |
Exchange Online için belgede ayrıca e-posta teslimat süresi, taahhüt edilen e-posta gönderimi ve e-posta giriş/çıkış kullanılabilirliği gibi ek hizmet düzeyleri de var. Örneğin e-postaların en hızlı %95’lik diliminin ortalama teslimat süresi 1 dakikayı aşarsa %25, 4 dakikayı aşarsa %50, 10 dakikayı aşarsa %100 kredi söz konusu. Yani yaşadığınız sorun tam bir erişim kaybı değil de ciddi bir e-posta gecikmesi ise, bu ayrı bir hizmet düzeyi üzerinden değerlendirilebilir.
Microsoft 365 Copilot’ta ölçüm farklı çalışıyor: Süre yerine başarısız yanıt oranına bakılıyor ve ilk kredi eşiği %99,5 olarak belirlenmiş. Ayrıca bu SLA, Copilot’taki tüketim tabanlı özellikler için geçerli değil.
Aylık çalışma süresi nasıl hesaplanıyor?
Exchange Online, Microsoft Teams ve SharePoint Online gibi hizmetlerde hesaplama kullanıcı dakikası üzerinden yapılıyor:
Çalışma Süresi Yüzdesi = (Kullanıcı Dakikaları - Çalışmama Süresi) / Kullanıcı Dakikaları x 100
Burada Kullanıcı Dakikaları, ilgili dönemdeki toplam dakikanın (planlı kesinti hariç) kullanıcı sayısıyla çarpımıdır. Çalışmama Süresi ise her olayın süresinin (dakika) o olaydan etkilenen kullanıcı sayısıyla çarpımının toplamıdır. İlgili dönem, Microsoft 365 gibi abonelik hizmetlerinde takvim ayıdır. Kasım ayı 30 gün olduğu için bu ayda toplam 43.200 dakika var.
Bu hesaptan iki sonuç çıkıyor. Birincisi, SLA ay boyunca biriken toplam kesintiye bakıyor, tek bir olaya değil. İkincisi, hesap kullanıcı ağırlıklı olduğu için kesintiden kullanıcılarınızın yalnızca küçük bir kısmı etkilendiyse eşiği aşmak zorlaşıyor.
Eşikler tüm kullanıcılar etkilendiğinde şöyle:
| Aylık çalışma süresi yüzdesi | Hizmet Kredisi | 30 günlük ayda, tüm kullanıcılar etkilenirse kesinti eşiği |
|---|---|---|
| %99,9’un altında | %25 | 43 dakika 12 saniyeyi aşan kesinti |
| %99’un altında | %50 | 7 saat 12 dakikayı aşan kesinti |
| %95’in altında | %100 | 36 saati aşan kesinti |
Sık yapılan bir yanlış anlama, 43 dakika 12 saniyenin ‘tek bir kesintinin’ toleransı olduğunu düşünmek. Değil: Bu süre, ay içindeki tüm kesintilerin toplamı için geçerli olan toleranstır.
Aşağıdaki örnek senaryolar bu mantığı somutlaştırıyor.
| Senaryo (30 günlük ay, 1.000 lisanslı kullanıcı) | Kayıp kullanıcı dakikası | Aylık çalışma süresi | Hizmet Kredisi |
|---|---|---|---|
| 1.000 kullanıcının tamamı, 40 dakika | 40.000 | %99,907 | Yok |
| 1.000 kullanıcının tamamı, 3 saat (180 dk) | 180.000 | %99,583 | %25 |
| 1.000 kullanıcının tamamı, 9 saat (540 dk) | 540.000 | %98,750 | %50 |
| 1.000 kullanıcıdan 200’ü, 9 saat (540 dk) | 108.000 | %99,750 | %25 |
| 1.000 kullanıcıdan 50’si, 9 saat (540 dk) | 27.000 | %99,938 | Yok |
Tabloda görüldüğü gibi, yalnızca kullanıcılarınızın %5’ini etkileyen 9 saatlik bir kesinti bile kullanıcı dakikası bazında eşiğin altında kalabiliyor. Bu nedenle kendi ortamınızda etkilenen kullanıcı sayısını ve sürelerini kayıt altına almanız, talebin en değerli kanıtı olacak.
Her kesinti kredi hakkı doğurmaz
SLA belgesinin ‘Sınırlamalar’ bölümü, hangi sorunların kapsam dışında kaldığını listeliyor.
IT yöneticisi olarak en çok dikkat edilmesi gerekenleri şöyle özetleyebilirim:
- Makul kontrol dışındaki faktörler (doğal afet, savaş, terör, hükümet müdahalesi) ve sizin tesisinizdeki veya tesisiniz ile Microsoft veri merkezi arasındaki ağ ya da cihaz arızaları kapsam dışı.
- Üçüncü taraf yazılım ve hizmetlerden, yetersiz bant genişliğinden ve desteklenmeyen yapılandırmalardan kaynaklanan sorunlar kapsam dışı.
- Exchange Online’daki OWA kullanılabilirliği hizmet düzeyi; DoS (Denial of Service) saldırıları, Microsoft 365 kiracı yanlış yapılandırması, Microsoft 365 sınırları dışındaki ağ sorunları, eklentilerden ve üçüncü taraf kaynaklı olaylardan doğan sorunlar için geçerli değil.
- Gerçek bir kullanılamazlık olmadan yaşanan performans düşüşü veya gecikme sorunları, açıkça performansa dayalı bir hizmet düzeyi bulunmadıkça kapsam dışı.
- Ön sürüm, beta veya deneme sürümleri ile ücretsiz sağlanan hizmetler SLA taleplerine dahil edilmiyor.
- Open, Open Value ve Open Value Aboneliği gibi toplu lisanslama anlaşmaları üzerinden alınan hizmetlerde kredi, hizmet ücreti yerine hizmet süresi (örneğin gün) olarak ödenebiliyor.
Hizmet Kredisi nasıl talep edilir?
Kredi otomatik tanımlanmıyor. SLA’ya göre talebi, doğrulama için gerekli tüm bilgilerle birlikte Microsoft müşteri desteğine siz göndermelisiniz. Gerekli bilgiler eksikse talep reddediliyor. Aşağıdaki tablo bu bilgileri ve pratikte nereden toplayabileceğinizi gösteriyor.
| Talebe eklenmesi gereken bilgi | Pratikte nereden toplanır? |
|---|---|
| Olayın ayrıntılı açıklaması | Service Health olay kaydı (başlık, etki özeti, Incident ID, güncellemeler) |
| Çalışmama süresi ve zamanı | Olay kaydındaki başlangıç ve bitiş saatleri, kendi izleme sisteminizin kayıtları (saat dilimini belirtin) |
| Etkilenen kaynak adları | Etkilenen hizmet ve kiracı (tenant) adı, varsa etkilenen posta kutuları, Teams ekipleri veya SharePoint siteleri |
| Etkilenen kullanıcı sayısı ve konumları | Lisanslı kullanıcı sayınız, ofis ve ülke dağılımı, kullanıcıların açtığı destek kayıtları |
| Olay sırasında alınan hataların açıklaması | Hata mesajı ekran görüntüleri, istemci hata kodları, kullanıcı bildirimleri |
Süreç genel hatlarıyla şöyle ilerliyor:
Microsoft 365 Admin Center > Health > Service healthekranından ilgili olay kayıtlarını ve güncelleme geçmişini inceleyin, ekran görüntülerini alın.- Kendi ortamınızdaki etkiyi belgeleyin: etkilenen kullanıcı sayısı, saat aralıkları, hata mesajları ve kullanıcıların açtığı destek kayıtları.
- Yukarıdaki tabloya göre bilgileri derleyin ve Microsoft müşteri desteğine bir hizmet talebi açın. Lisansınızı bir CSP (Cloud Solution Provider) iş ortağından aldıysanız talebi genellikle iş ortağınız üzerinden iletmeniz gerekir.
- Talebinizi hizmet bazında ayırın: Birden fazla hizmeti ayrı ayrı (paket şeklinde olmayan) satın aldıysanız, her hizmet için ayrı talep gönderirsiniz. Aynı hizmet için ilgili dönemde yalnızca bir Hizmet Kredisi verilir.
- Yanıtı bekleyin: Microsoft, talebin alınmasından sonra 45 gün içinde talepleri işlemek için ticari açıdan makul çabayı göstereceğini belirtiyor.
Talep için son tarih
Azure dışındaki hizmetlerde talebin, olayın yaşandığı ayı takip eden ilgili dönemin sonuna kadar Microsoft’a ulaşmış olması gerekiyor. Belgedeki örnek şöyle: Olay 15 Şubat’ta olduysa talep ve gerekli tüm bilgiler 31 Mart’a kadar alınmalı. Bu kurala göre, 12-13 Kasım 2026 olayları için son tarih 31 Aralık 2026 oluyor. Bu tarihi ekibinizin takvimine şimdiden ekleyin.
Kredi neyi karşılar, neyi karşılamaz?
- Hizmet Kredisi, yalnızca ilgili hizmet için ödediğiniz ücrete uygulanıyor ve aylık hizmet ücretinizi aşamıyor.
- Kredi, gelir kaybı, operasyonel maliyetler veya dolaylı kayıpları karşılamak için tasarlanmış değil.
- SLA kapsamındaki performans ve kullanılabilirlik sorunlarında Hizmet Kredileri tek ve münhasır talep hakkınız. Yani ücretlerinizi tek taraflı olarak mahsup edemezsiniz.
Pratik öneriler
- Kanıtı olay anında toplayın. Service Health kayıtları zamanla değişebilir. Olay devam ederken ekran görüntüsü alın ve saat bilgilerini not edin.
- Kendi izlemenizi kurun. Basit bir sentetik izleme (periyodik giriş, e-posta gönderimi, toplantı başlatma testi) hem kök neden analizinde hem de SLA talebinde elinizi güçlendirir.
- Hizmet bazında düşünün. Exchange Online, Teams ve SharePoint Online için ayrı hesap ve ayrı talep gerekebilir.
- Kapsam dışı kalma risklerini baştan değerlendirin. Üçüncü taraf eklenti, kiracı yapılandırması veya kendi ağınızdaki sorunlar talebi zayıflatır.
- Finansal etkiyi ayrıca raporlayın. Hizmet Kredisi yaşanan zararı karşılamayacağı için, operasyonel etkiyi yönetime ayrı bir raporla iletmek gerekir.
Sonuç
Bulut hizmetlerinde SLA, sadece teknik bir erişilebilirlik taahhüdü değil, aynı zamanda sözleşmesel bir haktır. Ancak bu hak otomatik işlemez: Kesintinin SLA tanımına uyması, aylık eşiğin aşılması, kapsam dışı istisnalara takılınmaması ve talebin süresi içinde, eksiksiz bilgilerle gönderilmesi gerekir. 12-13 Kasım 2026 olayları için Aralık ayı sonuna kadar vaktiniz var. Kendi ortamınızdaki etkiyi şimdi belgeleyin ve talebin gerekçesini netleştirin.
Siz kurumunuzda yaşanan Microsoft 365 kesintileri sonrasında hiç Hizmet Kredisi talebinde bulundunuz mu? Deneyimlerinizi yorumlarda paylaşırsanız memnun olurum.
Kaynaklar
- Microsoft Çevrimiçi Hizmetler Hizmet Düzeyi Anlaşması (Türkçe sürüm, 1 Kasım 2026): aka.ms/CSLA
- Microsoft Licensing: Service Level Agreements (SLA) for Online Services sayfası: https://www.microsoft.com/licensing/docs/view/service-level-agreements-sla-for-online-services
Başka bir yazımızda görüşmek dileğiyle…