Üçüncü Taraf Kesintilerinde İş Sürekliliği ve Bağımlılık Haritası

Kısa cevap: İş sürekliliği planınız hâlâ "kendi veri merkezimiz çökerse" senaryosuna göre yazılmışsa, riskin büyük kısmını görmüyorsunuz. Uptime Institute'un 2026 Yıllık Kesinti Analizi'ne göre kamuya yansıyan kesintilerin yaklaşık üçte ikisinde bulut, telekom ve kolokasyon gibi üçüncü taraf sağlayıcılar rol oynuyor. Yapılacak ilk iş yeni bir araç satın almak değil: kritik iş süreçlerinin hangi dış servislere bağımlı olduğunu katman katman haritalamak, her bağımlılık için tedarikçinin gerçekçi kurtarma süresini plana yazmak ve en kritik akışlar için "sağlayıcı yokken de ayakta kalma" modunu önceden tasarlamaktır.

Kesinti artık dışarıdan geliyor

Kurumsal iş sürekliliği disiplini, jeneratörün devreye girmediği ya da depolama ünitesinin arızalandığı senaryolar üzerine kuruldu. Bu senaryolar geçerliliğini koruyor, ancak istatistik başka bir yöne işaret ediyor. Uptime Institute, tesis başına kesinti oranlarının beş yıldır düştüğünü, buna karşılık kamuya yansıyan kesintilerin yaklaşık üçte ikisinin bulut, telekom ve kolokasyon sağlayıcılarını içerdiğini raporluyor. Yani BT ekipleri kendi altyapılarını daha iyi işletiyor; kesinti ise tedarik zincirine taşınıyor.

Maliyet tarafı da küçülmüyor. Aynı araştırmaya göre katılımcıların yüzde 57'si son büyük kesintinin 100.000 doları aştığını, beşte biri ise 1 milyon doların üzerinde zarar yazdığını söylüyor. Tempoya dair güncel bir veri: ThousandEyes'ın ağ sağlığı takibi, sadece 24-30 Ağustos 2026 haftasında dünya genelinde 649 ağ kesintisi olayı kaydetti; bu, bir önceki haftaya göre yüzde 22 artış demek.

Son on iki ayın üç dersi

Tek tek bakıldığında her büyük kesintinin nedeni farklı görünür. Yan yana koyunca ortak bir desen çıkar: küçük bir iç değişiklik, sağlayıcının ölçeği nedeniyle küresel bir iş sürekliliği olayına dönüşüyor.

AWS, 20 Ekim 2025. us-east-1 bölgesinde DynamoDB'nin otomatik DNS yönetimindeki bir yarış koşulu, bölgesel uç noktayı erişilmez bıraktı. ThousandEyes'ın analizine göre tam toparlanma ertesi güne sarktı ve 15 saati aştı; Slack ve Atlassian gibi küresel servisler etkilendi. AWS'nin resmi olay özeti hatanın yıllardır kodda uyuyan bir gecikmeli koşul olduğunu doğruluyor.
Microsoft Azure, 29 Ekim 2025. Azure Front Door'da istenmeyen bir yapılandırma değişikliği, Microsoft 365 dahil çok sayıda servisi etkileyen küresel bir kesinti tetikledi. Microsoft olay sonrasında dağıtım korumalarını sıkılaştırdığını açıkça yayımladı.
Cloudflare, 18 Kasım 2025. Bir veritabanı yetki değişikliği, Bot Management yapılandırma dosyasını limitin üzerine şişirdi ve proxy yazılımını çökertti. Cloudflare'ın kendi raporuna göre ilk hatalar 11:28 UTC'de görüldü, tüm servisler ancak 17:06 UTC'de normale döndü.

Bu üç olayın hiçbirinde saldırgan yok, donanım arızası yok. Üçü de rutin bir değişikliğin küresel yarıçapa yayılmasıyla ilgili. Müşteri tarafında oturan bir BT ekibinin bu olayları engelleme şansı sıfırdır; etkisini sınırlama şansı ise tamamen kendi elindedir.

Faturayı kim ödüyor: CrowdStrike dersi

Üçüncü taraf kesintisinin mali tarafını en net gösteren olay hâlâ Temmuz 2024'teki CrowdStrike güncelleme hatası. Sigorta modelleme şirketi Parametrix'in hesabına göre olay yalnızca Fortune 500 şirketlerine 5,4 milyar dolar doğrudan zarar yazdırdı; bunun sigortayla karşılanan kısmı 540 milyon ile 1,08 milyar dolar aralığında kaldı. Zararın büyük bölümü şirketlerin kendi üzerinde kaldı.

Buradaki ders sözleşme diline dair: SLA kredisi bir tazminat mekanizması değil, sembolik bir iade aracıdır. Aylık faturanın bir kısmının iadesi, durmuş bir üretim hattının ya da işlem yapamayan bir ödeme sisteminin kaybını karşılamaz. İş sürekliliği bütçesini SLA yüzdeleri üzerine değil, kesinti saatinin gerçek iş maliyeti üzerine kurmak gerekir.

Regülasyon da aynı noktayı gösteriyor: DORA ve 7545

Düzenleyiciler bu tabloyu bizden önce gördü. Avrupa Birliği'nde 17 Ocak 2025'ten beri uygulanan DORA, finansal kuruluşlara BİT üçüncü taraf riskini yönetme, sözleşme envanteri tutma ve kritik sağlayıcılar için çıkış stratejisi hazırlama yükümlülüğü getiriyor. AB'deki müşterilere hizmet veren Türk finans ve teknoloji şirketleri bu zincirin halkası durumunda.

Türkiye'de ise Mart 2025'te yürürlüğe giren 7545 sayılı Siber Güvenlik Kanunu sonrası önemli bir adım atıldı: 5 Mayıs 2026 tarihli Siber Güvenlik Kurulu kararıyla enerji, finans, sağlık, ulaştırma ve dijital altyapılar dahil 15 kritik altyapı sektörü belirlendi. Bu sektörlerdeki kuruluşlar için siber güvenlik ürün ve hizmetlerini yetkilendirilmiş sağlayıcılardan temin etme zorunluluğu ve 1 milyon ile 10 milyon TL arasında idari para cezası riski gündemde. Tedarik zincirinin güvenlik ve sorumluluk boyutunu daha önce KVKK perspektifinden incelemiştik; bu yazının konusu olan süreklilik boyutu, aynı haritanın ikinci katmanı.

Bağımlılık haritası nasıl çıkarılır

Üçüncü taraf dayanıklılığının ilk adımı envanterdir ve çoğu kurumda bu envanter yoktur. Yöntem şu sırayla işler:

İş sürecinden başlayın, teknolojiden değil. "Sipariş alma", "ödeme tahsilatı", "üretim planlama" gibi 10-15 kritik iş akışı listeleyin.
Her akışın altındaki uygulamaları yazın. ERP, CRM, e-posta, çağrı merkezi yazılımı gibi görünür katman burasıdır.
Her uygulamanın altındaki dış servisleri yazın. Bulut bölgesi, CDN, DNS sağlayıcısı, kimlik servisi (SSO/MFA), ödeme geçidi, SMS/e-posta gönderim servisi, lisans sunucusu. Kesintide asıl sürprizi yaratan bu görünmez katmandır.
Ortak nokta analizini yapın. Kaç kritik akış aynı bulut bölgesinden, aynı DNS sağlayıcısından, aynı kimlik servisinden geçiyor? Tek bir sağlayıcının arızasında aynı anda kaç sürecin duracağını bu analiz gösterir.
Her bağımlılığa bir tedarikçi RTO'su atayın. Sağlayıcının pazarlama sayfasındaki uptime yüzdesini değil, yaşanmış olaylardaki gerçek toparlanma sürelerini esas alın. AWS örneğindeki 15 saat, "yüzde 99,99" ibaresinden daha öğreticidir.

Bu harita çıktığında hedef RPO ve RTO değerlerinizi de yeniden gözden geçirmeniz gerekir; hesap yöntemi için RPO ve RTO hesaplama rehberimize bakabilirsiniz.

Fail small: kesintiyi küçük tutma mimarisi

Cloudflare, yaşadığı olayların ardından "Fail Small" adını verdiği bir dayanıklılık programı başlattı: yapılandırma değişikliklerinin kademeli dağıtımı, servisler arası arayüzlerin "karşı taraf çökecek" varsayımıyla tasarlanması ve döngüsel bağımlılıklardan arındırılmış acil erişim prosedürleri. Sağlayıcının kendisi için koyduğu bu ilkeler, hizmeti tüketen kurumlar için de birebir geçerli:

Zarif bozulma modları tanımlayın. Bot koruması çöktüğünde site tamamen mi kapanmalı, yoksa koruma devre dışı kalıp trafik akmaya devam mı etmeli? Bu kararın kesinti anında değil, tasarım aşamasında verilmiş olması gerekir.
Statik yedek tutun. Kritik müşteri sayfalarının statik bir kopyasını farklı bir sağlayıcıda bulundurmak, tam kesinti ile "yavaş ama ayakta" arasındaki farkı yaratır.
DNS ve CDN'de tek sağlayıcıya kilitlenmeyin. İkincil DNS düşük maliyetli bir sigortadır; kritik trafik için çoklu CDN mimarisi değerlendirilmelidir.
Kimlik servisinin çevrim dışı senaryosunu test edin. SSO sağlayıcısı eriştiğiniz her sistemin önünde duruyorsa, acil durumda kullanılacak kırılabilir cam (break glass) hesaplarının varlığı ve test edilmişliği hayati önemdedir.
Tedarikçi kesintisini tatbikatlara ekleyin. Felaket kurtarma tatbikatları çoğunlukla kendi altyapınızın kaybını simüle eder; senaryolara "bulut bölgesi erişilmez", "SaaS CRM 8 saat kapalı" gibi maddeler eklenmeli. Genel strateji için kurumsal felaket kurtarma stratejisi yazımız yol gösterir.

Sonuç: Bu hafta başlatın

Üçüncü taraf dayanıklılığı bir satın alma kararı değil, bir görünürlük ve tasarım disiplinidir. Bu hafta atılabilecek somut adımlar: en kritik beş iş akışı için bağımlılık haritasını çıkarın, her dış sağlayıcı için son iki yılın gerçek kesinti geçmişini derleyin, SLA metinlerindeki tazminat maddelerini iş maliyetiyle karşılaştırın ve bir sonraki iş sürekliliği tatbikatına en az bir tedarikçi kesintisi senaryosu ekleyin. Bu dört adım, bütçe gerektirmeden riskin fotoğrafını çeker; sonrasında yapılacak mimari yatırımların önceliğini de bu fotoğraf belirler. eclit olarak yönetilen hizmet müşterilerimizde iş sürekliliği planlamasını tam da bu sırayla ele alıyoruz: önce görünürlük, sonra tasarım, en sonda araç.