Kesinti Maliyeti Hesaplayıcı: BT Kesintisinin Saatlik Maliyeti Ne Kadar?

Bir sunucu, uygulama ya da veri merkezi kesintisinde ilk sorulan soru “sistem ne zaman açılır?” olur; yönetimin sorduğu ikinci soru ise “bu kesinti bize kaça mal oldu?” sorusudur. Kesinti maliyeti hesaplama aracı, BT kesintisinin maliyetini ciro kaybı ve çalışan verimliliği üzerinden saatlik olarak hesaplar, ardından mevcut ve hedeflenen kurtarma süresine göre tek bir olayın toplam maliyetini karşılaştırır. Kullanılan formül sayfanın devamında açıkça anlatılıyor; sonuç kara kutu değil, finans ekibiyle birlikte kontrol edilebilir bir tahmindir.

Hesaplama tamamen tarayıcıda yapılır, girilen ciro ve maliyet bilgileri hiçbir sunucuya gönderilmez.

Kesinti maliyeti nedir, nasıl hesaplanır?

Kesinti maliyeti, BT sistemlerinin çalışmadığı her saat için kaybedilen gelir ile durmuş ya da yavaşlamış çalışanların maliyetinin toplamıdır. Hesaplayıcı buna olay başına bir defalık kurtarma giderini ekler ve sonucu kurtarma süresiyle çarpar.

• Saatlik gelir kaybı: yıllık ciro × cironun BT’ye bağlı payı ÷ yıllık çalışma saati.
• Saatlik verimlilik kaybı: etkilenen çalışan × çalışan başına saatlik maliyet × verimlilik kaybı oranı.
• Saatlik kesinti maliyeti: iki kalemin toplamı.
• Olay başına maliyet: saatlik kesinti maliyeti × kurtarma süresi (saat) + ek kurtarma maliyeti.

Bu yaklaşım, NIST’in acil durum planlama rehberinde tarif edilen iş etki analizinin (BIA) temel mantığına dayanır: önce her sistemin kesintisinin iş süreçlerine etkisi belirlenir, ardından bu etkiye göre kabul edilebilir kesinti süresi tanımlanır (NIST SP 800-34 Rev.1, Contingency Planning Guide). Hesaplayıcı bu analizin parasal tarafını hızlıca görmeyi sağlar; analizin yerini tutmaz.

Örnek hesaplama: 24 saat ile 2 saat arasındaki fark

Aracın varsayılan değerleriyle yapılan hesapta saatlik kesinti maliyeti yaklaşık 24.533 TL çıkar; 24 saatlik bir kurtarma tek olayda yaklaşık 613.800 TL’ye, 2 saatlik kurtarma yaklaşık 74.067 TL’ye mal olur. Aşağıdaki değerler yalnız örnek amaçlı girdilerdir, herhangi bir müşteriye ait veri değildir.

Kalem	Girdi / hesap	Sonuç
Saatlik gelir kaybı	50.000.000 TL × %60 ÷ 2.250 saat	≈ 13.333 TL
Saatlik verimlilik kaybı	40 çalışan × 400 TL × %70	≈ 11.200 TL
Saatlik kesinti maliyeti	13.333 + 11.200	≈ 24.533 TL
Mevcut kurtarma (24 saat)	24.533 × 24 + 25.000 TL	≈ 613.800 TL
Hedef kurtarma (2 saat)	24.533 × 2 + 25.000 TL	≈ 74.067 TL
Olay başına fark	613.800 − 74.067	≈ 539.733 TL

Tablodaki fark, kurtarma süresi kısaltıldığında tek bir kesinti olayında önlenebilecek doğrudan maliyeti gösterir. Yılda birden fazla olay bekleniyorsa bu fark beklenen olay sayısıyla birlikte değerlendirilmelidir.

Girdiler hangi kaynaktan alınmalı?

Kesinti maliyeti hesaplama için gereken girdilerin büyük kısmı finans ve insan kaynakları kayıtlarından, BT bağımlılığı ve kurtarma süresi ise iş birimleri ile BT ekibinin ortak değerlendirmesinden gelir. Tahmini değerlerle başlamak mümkündür, fakat sonuç yönetime sunulmadan önce her girdinin kaynağı not edilmelidir.

Yıllık ciro son kapanmış mali yılın gelir tablosundan alınır. Yıllık çalışma saati, işin fiilen yürüdüğü saatlerdir: 250 iş günü ve günde 9 saat çalışan bir kurum için 2.250 saattir; 7/24 satış yapan bir e-ticaret sitesinde bu değer çok daha yüksek tutulmalıdır. Çalışan başına saatlik maliyet yalnız brüt maaş değil, işveren payları ve yan haklarla birlikte hesaplanan toplam işveren maliyetidir.

Verimlilik kaybı oranı, kesinti süresince çalışanların işini ne ölçüde sürdürebildiğini gösterir. ERP ya da çağrı merkezi yazılımı gibi işin tamamen sisteme bağlı olduğu rollerde bu oran yüksek, kâğıt üzerinde ya da çevrimdışı devam edebilen işlerde daha düşüktür. Ek kurtarma maliyeti ise fazla mesai, dış destek, acil donanım ve veri girişinin yeniden yapılması gibi olay başına bir defalık giderleri kapsar.

Cironun BT’ye bağlı payı işletme türüne göre nasıl değişir?

Gelirin doğrudan sistem üzerinden üretildiği işletmelerde bu pay yüksek, sistem kesintisinde işin bir süre manuel yürüyebildiği işletmelerde daha düşüktür. Doğru oran sektör ortalamasından değil, kurumun kendi gelir akışından çıkarılmalıdır.

E-ticaret, online rezervasyon, ödeme hizmetleri ve SaaS ürünlerinde siparişin ya da işlemin tamamı sistem üzerinden geçer; kesinti doğrudan satış kaybıdır. Üretim tesislerinde hat çoğu zaman kısa bir süre çalışmaya devam eder, fakat sevkiyat, planlama ve fatura süreçleri ERP’ye bağlıysa sistem kesintisi zararı birkaç saat içinde büyür. Profesyonel hizmet şirketlerinde gelir kaybı genellikle ertelenmiş iş biçiminde görülür; bu durumda oran düşük, verimlilik kaybı kalemi ise ağırlıklı olur.

RTO ve RPO kesinti maliyetini nasıl belirler?

RTO (Recovery Time Objective), bir sistemin kesintiden sonra yeniden çalışır hale gelmesi için kabul edilen en uzun süredir; hesaplayıcıdaki “kurtarma süresi” alanı doğrudan bu değere karşılık gelir. RPO (Recovery Point Objective) ise kabul edilebilir en büyük veri kaybını, yani son kurtarma noktasından bu yana geçen süreyi ifade eder.

RTO maliyet ilişkisi doğrusaldır: saatlik kesinti maliyeti sabit kabul edildiğinde kurtarma süresindeki her saat aynı tutarı ekler. RPO tarafı hesaplayıcıda yer almaz, fakat maliyeti başka bir yoldan artırır. Kaybolan siparişlerin, muhasebe kayıtlarının ya da müşteri işlemlerinin yeniden girilmesi zaman ve iş gücü ister; bazı veriler ise hiç geri getirilemez. RPO hedefi belirlenirken son kurtarma noktasından sonra oluşan verinin yeniden üretilip üretilemeyeceği ayrıca değerlendirilmelidir.

Sonuç hangi kurtarma yöntemini işaret eder?

Saatlik kesinti maliyeti yüksek olan sistemler kısa kurtarma süresi sağlayan yöntemlere, düşük olanlar ise daha ekonomik yöntemlere yönelir. Yedekten geri dönüş, replikasyon ve hizmet olarak felaket kurtarma (DRaaS) bu yelpazenin üç temel noktasıdır.

Yedekten geri dönüş en düşük işletme maliyetine sahip seçenektir; fakat geri yükleme süresi veri hacmine ve altyapının yeniden kurulmasına bağlı olduğu için kurtarma süresi uzayabilir. Destek niteliğindeki ve saatlik kesinti maliyeti düşük sistemler için çoğu zaman yeterlidir. Periyodik ya da sürekli veri replikasyonu veriyi ikinci bir lokasyonda güncel tutarak hem veri kaybını hem de geri dönüş süresini azaltır.

DRaaS modelinde replikasyon, yedek altyapı ve geçiş (failover) süreci hizmet sağlayıcı tarafından birlikte yönetilir. Hesaplayıcıdaki fark büyük çıkan sistemler, bu yapının değerlendirilmesi gereken ilk adaylardır. Hangi yöntemin hangi kurtarma süresini sağlayacağı ise altyapı, veri hacmi ve test sonuçlarıyla proje bazında belirlenir.

Yatırım gerekçesi nasıl kurulur?

Kesinti maliyeti hesaplama sonucunun en sık kullanıldığı yer yatırım gerekçesidir. Gerekçe, felaket kurtarma çözümünün yıllık maliyeti ile beklenen kesinti olaylarında önlenecek maliyetin karşılaştırılmasıyla kurulur. Hesaplayıcının verdiği olay başına fark bu karşılaştırmanın temel girdisidir.

Karşılaştırmada üç soru öne çıkar: bir yılda kaç kesinti olayı beklenir, bu olayların ne kadarı kritik sistemleri etkiler ve çözüm her olayda kurtarma süresini ne ölçüde kısaltır? Olay sayısı için kurumun kendi geçmiş arıza kayıtları en güvenilir kaynaktır. Tek bir büyük olayın, örneğin fidye yazılımı saldırısı ya da veri merkezi arızasının, yıllar boyunca ödenecek çözüm maliyetinden yüksek olabileceği de ayrı bir senaryo olarak gösterilmelidir.

İş etki analizi neden hesaplayıcıdan fazlasıdır?

İş etki analizi, yalnız kesintinin maliyetini değil, her iş sürecinin hangi sistemlere bağlı olduğunu ve en fazla ne kadar süre durabileceğini ortaya koyar. Hesaplayıcı bu analizin parasal özetidir; süreç haritası, bağımlılıklar ve öncelik sırası ayrıca çıkarılmalıdır.

NIST yaklaşımında analiz, süreçlerin ve sistemlerin belirlenmesi, kesinti etkisinin ve kabul edilebilir kesinti süresinin tanımlanması, ardından kurtarma önceliklerinin sıralanmasıyla ilerler. Aynı mantık iş sürekliliği yönetim sistemi standardı ISO 22301 içinde de yer alır. Analizin çıktıları felaket kurtarma planının hazırlanmasında doğrudan kullanılır.

Hesaplamada sık yapılan hatalar

1. Tüm sistemleri tek kalemde toplamak: e-posta ile ERP’nin kesinti maliyeti aynı değildir; hesap kritik sistemler için ayrı ayrı yapılmalıdır.
2. Kurtarma süresini iyimser tahmin etmek: sistemin açılması ile işin normale dönmesi aynı an değildir; kontrol, veri doğrulama ve birikmiş iş de süreye dahildir.
3. Yalnız brüt maaşı kullanmak: işveren maliyeti dikkate alınmadığında verimlilik kaybı olduğundan düşük görünür.
4. Hesaba girmeyen kalemleri unutmak: itibar kaybı, kurumun kendi müşterilerine ödeyeceği sözleşme cezaları ve SLA iadeleri, veri kaybının KVKK kapsamındaki sonuçları ve kaybedilen gelecekteki müşteriler bu hesapta yer almaz; gerçek maliyet çoğu zaman daha yüksektir.

MAV Cloud’da felaket kurtarma: kurtarma hedefleri ve destek

MAV Cloud’un felaket kurtarma hizmetinde RPO ve RTO hedefleri her proje için sistemlerin kritiklik sınıfına göre tanımlanır. Kritik sistemlerde sürekli replikasyon ve öncelikli failover, önemli sistemlerde periyodik replikasyon uygulanır; destek sistemlerinde yedekten geri dönüş yeterli olabilir. Hesaplayıcının sonucu bu sınıflandırma için somut bir başlangıç noktası sağlar.

Felaket kurtarma hizmetleri MAV Cloud’un hizmet seviyesi sözleşmesi kapsamındadır. İlk müdahale hedefleri kritik öncelikte 15 dakika, yüksek öncelikte 1 saat, orta öncelikte 4 saat, düşük öncelikte 1 iş günüdür.

MAV Cloud, iş sürekliliği yönetim sistemi için ISO 22301 ve bilgi güvenliği yönetim sistemi için ISO/IEC 27001 belgelidir (sertifikalarımız).

Sıkça Sorulan Sorular

Kesinti maliyeti hesaplama için hangi veriler gerekir?

Yıllık ciro, cironun BT sistemlerine bağlı payı, yıllık çalışma saati, kesintiden etkilenen çalışan sayısı, çalışan başına saatlik maliyet, verimlilik kaybı oranı, olay başına ek kurtarma maliyeti ve kurtarma süresi gerekir. Ciro ve personel maliyeti finans ile insan kaynakları kayıtlarından alınır.

Hesaplayıcının sonucu ne kadar güvenilir?

Sonuç, girilen değerler kadar güvenilirdir ve doğrudan kalemlerle sınırlıdır. İtibar kaybı, sözleşme cezaları ve veri kaybının hukuki sonuçları dahil olmadığı için gerçek maliyet genellikle hesaplanan değerin üzerindedir.

RTO ile RPO arasındaki fark nedir?

RTO, sistemin yeniden çalışır hale gelmesi için kabul edilen en uzun süredir. RPO ise kabul edilebilir en büyük veri kaybını, yani son kurtarma noktasından bu yana geçen süreyi gösterir.

Girilen bilgiler bir yere kaydediliyor mu?

Hayır. Hesaplama tarayıcıda yapılır, ciro ve maliyet bilgileri sunucuya gönderilmez.

Değerler henüz netleşmediyse hesaplayıcı farklı senaryoları karşılaştırmak için kullanılabilir. Kritik sistemler belliyse, sonuç ekranındaki teklif bağlantısı en hızlı yoldur.