SaaS Kesintileri Çağında İş Sürekliliği ve Üçüncü Taraf Riski

Kısa cevap: İş sürekliliği planınız hala yalnızca kendi sunucularınızı, kendi veri merkezinizi ve kendi yedeklerinizi kapsıyorsa, kesintilerin bugün geldiği yere bakmıyor demektir. Uptime Institute'un dokuz yıllık verisine göre kamuya yansıyan kesintilerin yaklaşık üçte ikisi bulut, telekom ve kolokasyon gibi üçüncü taraf sağlayıcılardan kaynaklanıyor. Çözüm SaaS'tan kaçmak değil; bağımlılıklarınızı haritalamak, her kritik hizmet için kademeli çalışma modu tanımlamak ve bu senaryoları da tıpkı felaket kurtarma tatbikatı gibi test etmek.

Tek ayda üç kesinti, üç farklı katman

16 Eylül 2026 sabahı Salesforce, üç operasyon bölgesinin tamamında erişim sorunları yaşadı. Kesinti 07:50 UTC'de başladı, sorunun kaynağı ancak yaklaşık üç saat sonra teşhis edilebildi. İlk bulgular, isteklerin dahili bir login servisinden yanıt beklerken askıda kaldığını gösteriyordu. Dünyanın en büyük SaaS şirketlerinden biri, üstelik kendi Dreamforce konferansının ikinci gününde, müşterilerinin CRM ekranlarını açamamasını izledi.

Bundan iki hafta önce, 3 Eylül sabahı, ChatGPT, Claude ve Grok aynı saat diliminde kesinti yaşadı. Grok'un kesintisi Memphis'teki bir hesaplama merkezindeki arızaya bağlandı ve açıklamada "compute partner" etkisinden söz edildi. Yapay zekayı iş akışlarına bağlayan şirketler o sabah yeni bir bağımlılık katmanı keşfetti: model sağlayıcısının arkasındaki GPU altyapısı.

Türkiye'de ise 31 Temmuz 2026'da TürkNet aboneleri ülke genelinde saatler süren bir erişim sorunu yaşadı. Şirket sorunu trafik yönlendirme sistemlerindeki beklenmedik bir duruma bağladı; erişim ancak 16:16'da kademeli olarak geri geldi. Dikkat çekici ayrıntı şu: kesinti sırasında müşteri destek kanallarına da ulaşılamadı. Sağlayıcınız düştüğünde, ona ulaşacağınız kanal da onunla birlikte düşebiliyor.

Üç olay, üç farklı katman: uygulama (SaaS), yapay zeka altyapısı ve erişim şebekesi. Ortak nokta, hiçbirinde arızanın sizin makine dairenizde olmaması. Yine de o gün işi duran, sizin işiniz.

Kesintiler dışarı taşındı, faturası içeride kaldı

Bu bir izlenim değil, ölçülen bir eğilim. Uptime Institute'un 2026 Yıllık Kesinti Analizi, veri merkezi başına kesinti oranlarının beş yıldır düştüğünü, buna karşılık kamuya yansıyan kesintilerde üçüncü taraf BT ve veri merkezi sağlayıcılarının payının dokuz yıllık izleme döneminde yaklaşık üçte iki olduğunu ortaya koyuyor. Yani tek tek tesisler daha iyi işletiliyor; ama bağımlılık zincirleri uzadıkça, bir sağlayıcı arızası çok daha geniş bir alana yayılıyor.

Faturanın boyutu da büyüyor. Aynı analize göre katılımcıların yüzde 57'si son büyük kesintisinin 100.000 doların üzerine mal olduğunu, beşte biri ise maliyetin 1 milyon doları aştığını bildiriyor. Oxford Economics ile Splunk'ın 2026 tarihli Hidden Costs of Downtime araştırması ise tabloyu üst ölçekte gösteriyor: plansız kesintiler Global 2000 şirketlerine yılda toplam 600 milyar dolara, şirket başına ortalama 300 milyon dolara mal oluyor ve bu maliyet iki yılda yüzde 50 artmış durumda. Tek bir olay sonrası hisse fiyatlarında ortalama yüzde 3,4'lük düşüş ölçülmüş.

Bu rakamların çoğu küresel ölçekten geliyor; Türkiye'ye özgü toplam kesinti maliyeti verisi yayınlanmıyor. Ama mekanizma aynı: e-ticaret sitesi kampanya sabahı satamıyor, çağrı merkezi CRM göremiyor, saha ekibi iş emri alamıyor. Kesintinin sahibi sağlayıcı, zararın sahibi sizsiniz. Sözleşmenizdeki SLA kredisi ise çoğu zaman aylık ücretin bir bölümünü iade eder; kaybedilen cironun değil.

DR planınız neden SaaS'ı kapsamıyor

Klasik felaket kurtarma kurgusu, kontrol ettiğiniz altyapı üzerine kuruludur: birincil site düşer, ikincil site devralır. RPO ve RTO hedefleri, replikasyon ve failover mekanizmalarıyla sizin elinizdedir. SaaS'ta bu araçların hiçbiri sizde değildir. Salesforce düştüğünde "yedek Salesforce'a" geçemezsiniz; sağlayıcının durum sayfasını yenileyerek beklersiniz.

20 Ekim 2025'teki AWS us-east-1 kesintisi bu asimetrinin ders kitabı örneğiydi. AWS'nin kendi olay özeti, DynamoDB'nin otomatik DNS yönetimindeki bir yarış koşulunun bölgesel uç noktanın tüm IP kayıtlarını sildiğini anlatıyor. ThousandEyes'ın analizine göre etki, ilk paket kaybından tam toparlanmaya kadar 15 saati aştı ve Slack, Atlassian, Snapchat gibi devlerin de aralarında olduğu çok sayıda hizmete yayıldı. O gün kesinti yaşayan şirketlerin önemli bölümünün AWS ile doğrudan sözleşmesi bile yoktu; AWS kullanan bir SaaS'ın müşterisiydiler. Buna yoğunlaşma riski deniyor: farklı tedarikçileriniz aynı alt katmana bağlıysa, çeşitlilik görüntüsünün altında tek bir arıza noktası yatar.

Bu, tedarik zinciri güvenliğinde gördüğümüz sorumluluk modelinin dayanıklılık versiyonu. Veri ihlalinde sorumluluğun tedarikçiye devredilemediğini KVKK ve tedarik zinciri güvenliği yazımızda ele almıştık; kesinti için de aynı ilke geçerli. Regülatörler de aynı yöne bakıyor. Avrupa Birliği'nde finans sektörünü bağlayan DORA, Ocak 2025'ten bu yana BT üçüncü taraf riskinin yönetimini zorunlu tutuyor ve 28. maddesiyle kritik BT tedarikçileri için çıkış stratejisi tanımlamayı şart koşuyor. Türkiye'de BDDK'nın Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmeliği benzer şekilde dış hizmet alımlarında iş sürekliliği ve denetim yükümlülükleri getiriyor. Bugün bankalara sorulan soruların yarın diğer sektörlere de sorulması sürpriz olmaz.

Bağımlılık haritası: ilk ve en ucuz adım

Üçüncü taraf dayanıklılığının ilk adımı teknoloji değil, envanter. Çoğu kurumda hangi iş sürecinin hangi SaaS'a, o SaaS'ın hangi buluta ve hangi kimlik sağlayıcısına bağlı olduğunu tek bir yerde gösteren bir harita yok. Oysa bu harita olmadan ne yoğunlaşma riskinizi görebilirsiniz ne de hangi kesintinin gerçekten kritik olduğunu.

Pratikte şu üç soruyla başlıyoruz:

Bu hizmet düştüğünde hangi iş süreci, kaç dakika içinde durur? Gelir mi durur, verimlilik mi düşer, yoksa kimse fark etmez mi?
Bu hizmetin arkasında hangi alt bağımlılıklar var? Hangi bulut bölgesi, hangi kimlik sağlayıcı, hangi ödeme altyapısı?
Kesinti anında bu hizmetteki verinin bizde güncel bir kopyası var mı? Varsa en son ne zaman dışa aktarıldı?

Bu üç sorunun cevabı, kritiklik kademelendirmesini kendiliğinden üretir. Sonrasında her kademe için hedef belirlersiniz: birinci kademe hizmetlerde saatler değil dakikalar mertebesinde bir çalışma sürekliliği beklentisi varsa, tek sağlayıcıya bağlı kalmanın maliyetiyle alternatif kanalın maliyetini açıkça karşılaştırırsınız. Bu hesabın yöntemi, RPO ve RTO hesaplama rehberimizdeki iş maliyeti yaklaşımının aynısı; sadece bu kez hedefleri kendi altyapınıza değil, tedarikçilerinize uyguluyorsunuz.

Kademeli çalışma modu: kesintide iş nasıl devam eder

İkinci adım, kritik her hizmet için "hizmet yokken iş nasıl yürür" sorusuna yazılı cevap vermek. Buna kademeli çalışma modu diyoruz ve üç bileşeni var:

Veri tarafında bağımsız kopya. SaaS verinizin düzenli dışa aktarımı sizin kontrolünüzdeki bir ortamda durmalı. CRM'e erişilemediğinde günün müşteri randevularını gösterebilen bir dışa aktarım, çoğu satış ekibi için kesintiyi kriz olmaktan çıkarır.
Süreç tarafında geçici prosedür. Sipariş SaaS'a girilemiyorsa nereye kaydedilir, kesinti bitince kim, hangi sırayla geri işler? Bu prosedür yazılı değilse kesinti anında icat edilir ve genellikle veri kaybıyla biter.
İletişim tarafında bağımsız kanal. TürkNet vakasının hatırlattığı gibi, sağlayıcıya ve etkilenen altyapıya bağlı olmayan bir iletişim yolu gerekir. Kriz anında ekibinizle konuşacağınız kanal, kesintiye giren hizmetin üzerinde koşuyorsa planınız kağıt üzerinde kalır.

Ve hepsinin üstünde: bu senaryolar test edilmedikçe plan sayılmaz. Masaüstü tatbikatına "en kritik SaaS tedarikçimiz 8 saat erişilemez" senaryosunu ekleyin. Yedeklerini hiç geri dönmeyen kurumların durumunu tatbikat ile kağıt plan farkını incelediğimiz yazıda anlatmıştık; üçüncü taraf senaryoları için de aynı kural geçerli. Test edilmemiş kademeli çalışma modu, çalışma modu değildir.

Bu hafta atılacak üç adım

Bu işin bütçe onayı gerektirmeyen kısmı bir haftada biter:

En kritik on dış bağımlılığınızı listeleyin. SaaS, bulut, bağlantı ve kimlik sağlayıcı dahil. Her biri için "düşerse ne olur" cevabını tek cümleyle yazın.
Bu listedeki her hizmet için SLA'daki taahhüdü ve gerçek beklentinizi yan yana koyun. Aradaki fark, kabul ettiğiniz risktir; bilerek kabul edilmesi gerekir.
Bir sonraki iş sürekliliği tatbikatınıza en az bir üçüncü taraf kesinti senaryosu ekleyin ve sonucu yönetimle paylaşın.

Yönetilen hizmet sağlayıcı olarak günümüzün önemli bir bölümü, müşterilerimizin kendi altyapısı kadar bu bağımlılık zincirlerini izlemekle geçiyor. Deneyimimiz şu: tedarikçi kesintisini önleyemezsiniz, ama kesintinin sizi hazırlıksız yakalamasını önleyebilirsiniz. Aradaki fark, o sabah ekranın karşısında beklemekle işi yürütmeye devam etmek arasındaki farktır.