Microsoft 365 Kesintisi: Şirket İçi Sunucu Neden Hala Önemli?

12 Kasım Perşembe akşamı Exchange Online posta kutularına erişim kesildi. Önce Outlook gitti, ardından Teams, SharePoint, OneDrive, Copilot ve Defender XDR. Kesinti 13 Kasım Cuma akşamına kadar tam olarak kapanmadı; Microsoft’un bugüne kadar yaşadığı en uzun kesintilerden biri olarak kayda geçti. Bu yazıda önce ne olduğunu, Microsoft’un açıkladığı haliyle ve kaynaklı olarak aktarıyoruz. Ardından asıl soruya geçiyoruz: her şeyi buluta taşıyan bir işletme, sağlayıcı çöktüğünde elinde ne tutuyor?

Ne oldu: kesintinin zaman çizelgesi

Saatler Türkiye saatine (TSİ) çevrildi; kaynaklarda ABD Doğu saati (ET) kullanılıyor.

Microsoft 365 yönetim merkezindeki olay numaraları MO1550821 (ana duyuru, etkilenen servislerin güncel listesi) ve EX1550543 (Exchange Online posta kutusu bağlantısı). Kiracınızdaki etkiyi bu iki kayıttan takip edin.

Etkinin boyutu

Bloomberg’e göre 70’ten fazla ülkeden yüz binlerce şikayet kaydedildi. Sorun yalnızca e-posta değildi. Toplantı davetleri ulaşmadı, Copilot sayfaları yanıt vermedi; güvenlik yazılımları, dosya paylaşımı ve yönetici araçları da etkilendi.

Microsoft neden olarak ne söyledi

Kesin kök neden henüz açıklanmadı. Microsoft’un kesinti boyunca yaptığı açıklamalar şu tabloyu çiziyor:

• Kapasite kaybı: Çok sayıda sunucu beklenmedik şekilde servis dışı kaldı. Yük kalan sunuculara bindi ve onlar da yanıt veremez hale geldi. Microsoft sonradan trafikte bir artış olmadığını, sorunun kapasite kaybından kaynaklandığını belirtti.
• Sağlık denetimleri: Sunucunun istek kabul edip edemeyeceğine karar veren otomatik sağlık denetimleri başarısız oldu. Sağlam sunucular da havuzdan düştü.
• Çekirdek süreç: Etkilenen sunuculardaki bir çekirdek süreç aşırı yüklenip yanıt vermeyi bıraktı. Geri getirilen sunucular trafik alınca yeniden kilitlendi.
• Kötü niyet yok: Microsoft, kötü niyetli bir faaliyete dair kanıt olmadığını açıkladı.

Bazı yayınlar sorunu daha önceki bir ağ kapasitesi yükseltmesine bağladı; bazıları Microsoft’un kesintinin başlangıcıyla örtüşen bir değişiklik bulamadığını yazdı. Bu noktada kesin konuşmak için olay sonrası raporu beklemek gerekiyor.

Uygulanan önlemler sahadaki mühendis için tanıdık: dağıtımlar durduruldu, trafik alternatif yollara aktarıldı, belirli trafik kısıtlandı, son yapılandırma güncellemelerinin geri alınması değerlendirildi. Hiper ölçekli bir platformda bile kurtarma, elle yönetilen bir veri merkezindeki adımlarla aynıdır. Fark ölçekte. Ölçek büyüdükçe toparlanma da uzar.

SLA ne verir, ne vermez

Microsoft, Exchange Online ve diğer çevrim içi servisler için aylık yüzde 99,9 çalışırlık taahhüt eder. Otuz günlük bir ayda bu, yaklaşık 43 dakikalık kesinti payı demektir. Bu kesinti o payı katlarca aştı.

Taahhüt aşıldığında karşılığı hizmet kredisidir, yani sonraki faturadan düşülen bir indirim. Bu kredi, kesinti süresince duran işin maliyetini karşılamaz. Bu yüzden süreklilik planı SLA oranına göre değil, işletmenin kaç saatlik kesintiye dayanabildiğine göre yapılmalı.

Her şey buluttaysa, kesintide elinizde ne kalır?

Asıl soru bu. Kesinti saatlerinde bir işletmenin ayakta kalıp kalmadığını, hangi servisin nerede çalıştığı belirledi. Aşağıdaki tablo, sahada sık gördüğümüz iki yapıyı bu kesinti senaryosuna göre karşılaştırıyor.

Tablonun son iki satırı önemli. Şirket içi sunucu e-postayı kurtarmadı. Posta kutusu Exchange Online’daysa, sunucu odanızda ne olduğunun bir önemi yoktu. Ama işletmenin geri kalanı çalıştı. Fatura kesildi, üretim emri girildi, dosyaya erişildi. Kesinti bir iletişim sorunu olarak kaldı; operasyon durmadı.

Şirket içi sunucu neden hala önemli

Buradaki argüman “buluttan çıkın” değil. Microsoft 365, çoğu işletme için doğru e-posta ve iş birliği platformudur. Argüman, bağımlılığı tek noktada toplamamak. Bulut ile şirket içi arasındaki karar servis servis verilmeli, tek kalemde değil.

1. Kimlik yerelde kalmalı

Hibrit kimlik yapısında kullanıcılar şirket içi Active Directory’de tutulur ve Entra ID ile eşitlenir. Bulut tarafında sorun olsa bile bilgisayara oturum açmak, yerel dosya sunucusuna ve uygulamalara erişmek yerel DC üzerinden sürer. En az iki DC, sağlıklı bir DNS ve yedeklenmiş bir eşitleme sunucusu bu yapının temelidir. Eşitleme seçenekleri için Entra Connect Sync mi Cloud Sync mi yazımıza bakın.

2. İşi döndüren uygulamalar yerel ağda çalışmalı

ERP, muhasebe, MES, depo yönetimi, lisans sunucuları. Bunlar dakikalık kesintiye bile tahammül etmez. Yerel bir sanallaştırma kümesinde çalıştıklarında internet çıkışı ya da bir SaaS sağlayıcısı düştüğünde etkilenmezler. Tek sunucu yerine iki düğümlü bir küme, donanım arızasında da çalışmayı sürdürür; planlama adımları Hyper-V Failover Cluster yazımızda. Bu yapıya geçişin sahadaki bir örneği için JMW Jant VxRail’den Hyper-V’ye dönüşüm hikayesine bakabilirsiniz.

3. Dosya sunucusu ölmedi, rolü değişti

Dosyaları tamamen SharePoint’e taşımak her işletmeye uymaz. Büyük CAD dosyaları, üretim çizimleri, sık değişen ortak klasörler yerel ağda çok daha hızlı açılır. Azure File Sync ile sık kullanılan veri yerel sunucuda önbellekte kalır, kopyası bulutta durur. Bulut erişilemezse önbellekteki dosyalarla çalışmaya devam edilir. Ayrıntılar hibrit dosya sunucusu yazımızda.

4. Verinin bağımsız bir kopyası olmalı

Bu kesintide veri kaybı bildirilmedi. Ama tek kopyanın sağlayıcının platformunda durduğu bir yapıda, sağlayıcı erişilemez olduğunda veriniz de erişilemez olur. Microsoft 365 verisini ayrı bir hedefe yedeklemek, kesinti sırasında kritik bir posta ya da belgeye yedekten ulaşmanın tek yoludur. Yöntemler Microsoft 365 yedekleme yazımızda; kopya sayısı ve konumu için 3-2-1-1-0 kuralı geçerli.

5. Kontrol sizde olur

Şirket içi altyapıda bakım penceresini siz seçersiniz. Güncellemeyi önce test sunucusunda dener, sonra yayarsınız. Bir sorun çıktığında konsola bağlanır, günlüğü okur, müdahale edersiniz. Bulutta ise beklersiniz. Bu kesintide çoğu BT yöneticisinin yapabildiği, servis durumu sayfasını takip edip kullanıcıları bilgilendirmekti.

Şirket içinin de bedeli var

Dürüst olmak gerekirse şirket içi altyapı kendi başına süreklilik garantisi değildir. Bakımsız bir sunucu odası, bulut sağlayıcısından çok daha sık çöker. Tek disk, tek güç kaynağı, test edilmemiş yedek, yaması geciken işletim sistemi. Sahada en sık gördüğümüz kesintiler bunlardır.

• Donanım ve yedeklilik: RAID, çift güç kaynağı, UPS, tercihen iki düğümlü küme.
• İzleme ve yama: Disk, servis ve sertifika uyarıları izlenmeli, aylık yama döngüsü uygulanmalı.
• Yerinde kopya yetmez: Yangın, hırsızlık ve fidye yazılımına karşı tesis dışında ve değiştirilemez bir kopya şart.
• Şirket içi Exchange bu kesintinin çaresi değil: Exchange Server’ın Subscription Edition dışındaki sürümleri desteğin dışında. Şirket içi posta sunucusu yama yükü getirir ve saldırganların öncelikli hedeflerinden biridir. Postayı bulutta bırakıp iletişim için yedek plan hazırlamak çoğu işletme için daha doğru.

Kararı hedefe göre verin. Hangi servis kaç dakika durabilir, hangi veri kaç saatlik kayba katlanabilir? Bu iki soruya verdiğiniz cevap, servisin nerede çalışacağını belirler. Yöntem için RPO/RTO hedefine göre teknoloji seçimi yazımıza bakın.

Bir sonraki kesintiye hazırlık listesi

1. Bağımlılık haritası çıkarın. Her iş süreci hangi servise, o servis hangi sağlayıcıya bağlı? Tek tabloda görün.
2. Kesintide iletişim kanalı belirleyin. E-posta ve Teams aynı platformda. Telefon listesi, SMS grubu veya farklı bir sağlayıcıdaki mesajlaşma kanalı önceden tanımlı olsun. Liste buluttaki bir dosyada değil, basılı ve yerelde dursun.
3. Kritik uygulamaları yerelde tutun veya yedekli kurun. Durması iş kaybı olan sistem tek bir dış servise bağlı kalmamalı.
4. Microsoft 365 verisini ayrı bir hedefe yedekleyin ve geri yüklemeyi test edin.
5. Servis durumu takibini otomatikleştirin. Yönetim merkezindeki Service Health bildirimlerini açın; yönetim merkezine erişilemediğinde Microsoft 365 durum sayfası kullanılabilir.
6. Kesinti prosedürünü runbook’a yazın. Kim karar verir, kullanıcıya ne söylenir, ne zaman tırmandırılır? Şablon için felaket kurtarma runbook’u yazımıza bakın.

Kesinti sırasında BT ekibi ne yapmalı

• Önce sorunun sizde mi sağlayıcıda mı olduğunu ayırın: Service Health ve olay numaraları.
• Sağlayıcı kaynaklıysa yapılandırmayı kurcalamayın. DNS, bağlayıcı, lisans değiştirmek toparlanma sonrası yeni sorun üretir.
• Kullanıcılara gecikmiş postaların geleceğini, yeniden gönderim yapmamalarını söyleyin; bu kesintide Microsoft zaman aşımını 48 saate uzattı.
• Kimlik avına karşı uyarın. Kesinti dönemlerinde “parolanızı sıfırlayın” temalı sahte e-posta ve SMS artar.
• Kesinti sonrası olay sonrası raporunu okuyun ve kendi bağımlılık haritanızı ona göre güncelleyin.

Bulut kesintisi bir ihtimal değil, takvimi belli olmayan bir olaydır. Hazırlığı olan işletme için bir iletişim sorunu olarak kalır. Hazırlığı olmayan için iş durur.

Altyapınızda hangi servisin buluta, hangisinin şirket içine ait olduğunu birlikte değerlendirmek için sunucu ve bulut yönetimi, Microsoft 365 ve bulut hizmetleri ve yedekleme ve felaket kurtarma sayfalarımıza bakabilirsiniz. Hibrit altyapı tasarımı ve bakımı Eretek Sistem Destek ekibinin günlük işidir. Microsoft 365 tarafındaki diğer süreklilik konuları için Microsoft 365 ve bulut altyapısında süreklilik yazımız bu yazının devamı niteliğinde.

Sık sorulan sorular

12–13 Kasım Microsoft 365 kesintisi siber saldırı mıydı?

Microsoft, kötü niyetli bir faaliyete dair kanıt olmadığını açıkladı. Yaptığı açıklamalar sunucu kapasitesinin kaybı, başarısız sağlık denetimleri ve aşırı yüklenen bir çekirdek süreç üzerinde duruyor. Kesin kök neden olay sonrası raporunda yayımlanacak.

Kesinti sırasında gönderilen e-postalar kayboldu mu?

Microsoft, gecikmiş postaları korumak için Exchange Online’ın zaman aşımı süresini 48 saate uzattı ve kuyrukların eritildiğini açıkladı. Gecikmiş postalar kademeli olarak teslim ediliyor. Belirli bir mesajın durumu yönetim merkezindeki mesaj izleme (message trace) ile kontrol edilebilir.

Microsoft bu kesinti için tazminat öder mi?

Aylık çalışırlık taahhüdü aşıldığında Microsoft’un sözleşmesel karşılığı hizmet kredisidir; talep yönetim merkezinden ve sözleşmedeki süre içinde yapılır. Kesintinin işletmeye maliyetini karşılamaz.

Şirket içi sunucuya dönmek bu tür kesintileri önler mi?

Tek başına önlemez. Posta Exchange Online’da kaldıkça e-posta kesintiden etkilenir. Şirket içi sunucunun faydası, kimlik, dosya ve iş uygulamalarının buluttan bağımsız çalışmaya devam etmesidir. Doğru yaklaşım, her servisin nerede çalışacağını kesinti toleransına göre belirlemektir.