İş Sürekliliği ve Felaket Kurtarma Planı: KOBİ'ler İçin Pratik Rehber

Basit bir soru: sunucunuz bu gece çökse, yarın sabah dükkân açılır mı?

Çoğu işletmede bu sorunun cevabı "herhalde açılır" oluyor. "Herhalde" kelimesi, bir iş sürekliliği planının olmadığının en net göstergesi.

Bu yazıda büyük bütçe gerektirmeyen, birkaç sayfaya sığan ve gerçekten işe yarayan bir plan nasıl kurulur onu anlatıyoruz.

Neye karşı hazırlanıyoruz?

"Felaket" kelimesi kulağa deprem ya da yangın gibi geliyor; oysa işi durduran olayların büyük kısmı çok daha sıradan:

• Sunucu ya da disk arızası
• Uzun süren elektrik veya internet kesintisi
• Fidye yazılımı ve diğer siber olaylar
• Yanlışlıkla silinen tablo, üzerine yazılan dosya
• Bulut sağlayıcısında ya da tedarikçide yaşanan kesinti
• Anahtar kişinin aniden ulaşılamaz olması

Sonuncusu genellikle plan yapılırken atlanır ama en sık yaşananlardan biridir. Sisteme yalnız bir kişinin erişimi varsa, o kişinin telefonu kapalıyken sistem de kapalıdır.

Kritik süreçlerinizi listeleyin

Plan, teknolojiden değil işten başlar. Şu soruyu sorun: hangi işler durduğunda para akışı durur?

Tipik olarak bunlar: sipariş alma, faturalama, üretim planı, sevkiyat, tahsilat, müşteriye cevap verme. Bunların yanında "durursa can sıkıcı ama iş yürür" işler vardır: raporlama, arşiv erişimi, iç panolar.

Bu ayrımı yapmadan başlanan her plan gereğinden pahalı olur. Her sistemi aynı hızda ayağa kaldırmak zorunda değilsiniz.

Nakit tarafındaki etkiyi görmek isterseniz nakit akışı yönetimi ve tahsilat takibi yazısı iyi bir eşlikçidir: birkaç günlük bir kesintinin faturası çoğu zaman teknik değil, tahsilat gecikmesi olarak gelir.

İki sayı: RTO ve RPO

Planın tamamı aslında iki sayıya dayanır. Bunları belirlemeden hiçbir teknik karar verilemez.

RTO (kurtarma süresi hedefi): Bu sistem en geç ne kadar sürede yeniden çalışır olmalı? Dört saat mi, bir gün mü, üç gün mü?

RPO (kurtarma noktası hedefi): En fazla ne kadarlık veri kaybını kabul edebilirsiniz? Günde bir kez yedek alıyorsanız RPO'nuz fiilen 24 saattir; yani en kötü senaryoda bir günlük siparişi yeniden girmek zorunda kalırsınız.

Bu iki soruyu her kritik süreç için ayrı ayrı cevaplayın. Cevaplar farklı çıkacaktır: sipariş sistemi için RTO birkaç saatken, arşiv raporları için bir hafta olabilir.

Bu tabloyu çıkarmanın en faydalı yan etkisi şu: yatırım tartışması "ne kadar harcayalım" olmaktan çıkıp "bu süreyi kabul ediyor muyuz" hâline gelir. Bu, karar verilebilir bir sorudur.

Yedekleme: 3-2-1 kuralı

Yedeklemede uzun yıllardır geçerliliğini koruyan sade bir şema var:

• 3 kopya veri
• 2 farklı ortamda
• 1 tanesi ofis dışında

Bu düzenin gücü, birbirine hiç benzemeyen riskleri aynı anda karşılamasında: disk arızası, insan hatası, hırsızlık, yangın ve fidye yazılımı.

Fidye yazılımı için bir not: ağa bağlı ve sürekli erişilebilir olan bir yedek, saldırı anında şifrelenebilir. Bu yüzden en az bir kopyanın erişimi kısıtlı ya da değiştirilemez olması gerekir.

Ve en önemlisi: geri yükleme denenmemişse yedek yok demektir. Yıllardır düzenli yedek aldığını sanan ama ilk denemede yedeğin bozuk olduğunu keşfeden işletme sayısı, tahmin ettiğinizden fazla. Temel alışkanlıkları veri güvenliği ve yedekleme yazısında toplamıştık.

Bulut mu, kendi sunucunuz mu?

Süreklilik açısından ikisinin de kendi tuzağı var.

Kendi sunucunuz varsa risk tek bir fiziksel noktada toplanır: aynı odadaki elektrik, iklimlendirme, donanım. Bulutta ise altyapıyı başkası yönetir ama bu "bize bir şey olmaz" anlamına gelmez; sağlayıcı kesintileri de yaşanır ve o an yapabileceğiniz tek şey beklemektir.

Pratik cevap genelde ortada: kritik verinin bir kopyası, ana sisteminizin bulunduğu yerden farklı bir yerde dursun. Karar kriterlerini bulut mu, kendi sunucunuz mu yazısında ayrıntılandırmıştık.

Planı yazın: bir sayfa yeter

Bir iş sürekliliği planının kırk sayfa olması gerekmiyor. Şunları içeren tek bir belge çoğu KOBİ için fazlasıyla yeterli:

Kim kimi arar. Sorumlu kişiler, yedekleri ve telefon numaraları. Bu liste sistemin içinde değil, dışında da erişilebilir olmalı — sistem çöktüğünde sistemdeki listeye bakamazsınız.

Kritik sistemler ve hedefleri. Sistem adı, RTO, RPO, yedek nerede, nasıl geri yüklenir.

Erişim bilgileri nerede. Parolalar ve anahtarlar tek bir kişinin kafasında olmamalı; bir parola yöneticisinde ve kurtarma erişimi tanımlı biçimde durmalı.

Sistem yokken nasıl çalışılır. Sipariş kâğıda mı yazılacak, müşteriye ne söylenecek, hangi işler bekletilecek? Bu bölüm en çok atlanan ve en çok işe yarayan bölümdür.

Tedarikçi ve iletişim listesi. Hosting, internet sağlayıcısı, yazılım firması, muhasebe. Kimi arayacağınızı bilmek ilk yarım saati kurtarır.

Kişisel veri içeren bir olay yaşanırsa bildirim yükümlülükleri de gündeme gelir; çerçeveyi KOBİ'ler için KVKK uyum rehberi yazısında ele almıştık, ayrıntı için kvkk.gov.tr'yi ve hukuk danışmanınızı esas alın.

Tatbikat yapmadan plan tamamlanmaz

Bir planın gerçek olup olmadığını anlamanın tek yolu denemektir. Yılda bir kez, yarım günlük basit bir tatbikat yeterli:

• Rastgele bir yedekten tek bir dosyayı ya da tabloyu geri yükleyin ve süreyi ölçün.
• "Ana sunucu yok" varsayımıyla ekibe sorun: ilk bir saatte ne yapardınız?
• İletişim listesindeki numaraların güncelliğini kontrol edin.
• Geçen yıla göre neyin değiştiğini not edin; yeni bir sistem eklendiyse plana da eklenmiştir, değil mi?

Tatbikatın amacı planı doğrulamak değil, eksiğini bulmaktır. İlk denemede bir şeylerin tutmaması normaldir; asıl sorun, bunu gerçek bir kesinti gününde öğrenmektir.

Sistem değişikliği yapıyorsanız bu iyi bir fırsattır: eski yazılımdan yeni sisteme geçiş sırasında zaten yedek alıp geri yükleme denemesi yapılır; aynı adımı süreklilik planınızın tatbikatı olarak da sayabilirsiniz.

Nereden başlamalı

Üç adım öneriyoruz. Birincisi, işi durduran beş süreci ve bunların RTO/RPO hedeflerini tek sayfaya yazın. İkincisi, kritik verinin ofis dışında ve erişimi kısıtlı bir kopyasının bulunduğundan emin olun. Üçüncüsü, bu hafta içinde tek bir dosyayı yedekten geri yükleyip süreyi ölçün — bu küçük deneme, planınızın gerçek olup olmadığını hemen söyler.

Süreklilik planınızı çıkarmamızı, yedekleme düzeninizi gözden geçirmemizi ya da kritik sistemleriniz için kurtarma senaryosu tasarlamamızı isterseniz bizimle iletişime geçin; nasıl çalıştığımızı görmek için hizmetlerimize göz atabilirsiniz.