İş sürekliliği planı: kesinti, veri kaybı ve kilit kişi riski

Salı sabahı, otuz kişilik bir yapı malzemeleri toptancısında ön muhasebe sorumlusu işe gelemiyor; gece acil bir ameliyata alınmış. İlk gün kimse telaşlanmıyor, işler birikir diye düşünülüyor. İkinci gün e-fatura portalının şifresi başka kimsede olmadığı için yedi sevkiyatın faturası kesilemiyor. Üçüncü gün bankada ödemeyi onaylayabilen tek kişi o olduğundan tedarikçiye para gitmiyor ve gelmesi beklenen tır rampada bekliyor. Dördüncü gün hangi müşteriye hangi vade sözünün verildiğini kimse bilmediği için iki tahsilat sarkıyor. Şirket kapanmadı; sadece dört gün boyunca kendi işini okuyamadı ve bunun bedelini bir sonraki ay ödedi.

İş sürekliliği planı, tam olarak bu günlerde ne yapılacağını önceden yazıya dökmektir; kriz anında kahramanlık beklemek yerine. Aşağıda sırayla şunları ele alıyoruz: planın kriz yönetiminden ve felaket kurtarmadan farkı, riskleri değil sonuçları saymanın neden daha hızlı sonuç verdiği, hangi süreçlerin gerçekten kritik olduğunu bulmanın yöntemi, kurtarma hedeflerinin nasıl belirleneceği, kesinti ile veri kaybı ile kilit kişi risklerinin her birinin somut karşılığı, planın hangi formatta yazılacağı, tatbikatın neden zorunlu olduğu, bu yaklaşımın nerede işe yaramadığı ve ilk otuz günde atılacak adımlar.

İş sürekliliği planı kriz yönetiminden nasıl ayrılır?

Üç kavram sürekli birbirine karışır ve karıştıkları için hiçbiri kurulmaz. Kriz yönetimi olay olduktan sonra kimin ne söyleyeceğiyle ilgilenir: müşteriye, ekibe, gerekiyorsa kamuya. Felaket kurtarma teknik bir başlıktır; sistemlerin, verinin ve erişimlerin geri getirilmesini kapsar. İş sürekliliği planı ikisinin üstünde durur ve tek bir soruyu yanıtlar: sistemler yokken, bina kapalıyken veya kilit kişiye ulaşılamazken iş nasıl yürümeye devam edecek?

Fark pratikte şurada görünür. Felaket kurtarma tarafı veritabanını altı saatte ayağa kaldırırız der. Süreklilik planı ise o altı saat boyunca siparişin nasıl alınacağını, müşteriye ne söyleneceğini, sevkiyatın durdurulup durdurulmayacağını yanıtlar. Küçük şirketlerin çoğunda ikinci soru hiç sorulmadığı için, teknik taraf sistemi zamanında geri getirse bile operasyon yarım gün kaybeder ve o yarım gün müşteriye yansır.

Riskleri saymak yerine sonuçları sayın

Yaygın tavsiye uzun bir risk envanteri çıkarmaktır: yangın, su baskını, elektrik kesintisi, fidye yazılımı, tedarikçi iflası, salgın, ekipten ayrılma. Otuz kişilik bir şirkette bu liste kırk satıra ulaşır, kimse bitiremez ve dosya klasörde kalır. Daha hızlı yol tersinden gitmektir: sebepleri değil, sebeplerin ürettiği sonuçları listeleyin.

Sonuç listesi kısadır ve genellikle beşi geçmez. Binaya giremiyoruz. Sistemlere erişemiyoruz. Veriyi kaybettik. Kilit kişi yok. Tedarikçi teslim edemiyor. Yangın da su baskını da kira anlaşmazlığı da aynı sonucu üretir; üçüne ayrı plan yazmak boşa emektir. Bir plan yazacaksanız yangına özel plan yazmayın, binaya giremediğimiz ilk dört saatin planını yazın. Aynı tek sayfa, birbiriyle hiç ilgisi olmayan onlarca sebebin hepsinde çalışır ve bu yüzden gerçekten güncel kalır.

Hangi süreçler gerçekten kritik?

Bir sonraki adım, şirketin yaptığı işleri durursa ne olur sorusuyla elemektir. Kritik süreç, durduğunda para, müşteri veya yasal yükümlülük kaybettiren süreçtir; geri kalanı bir hafta bekleyebilir. Ekiplerin çoğu bu ayrımı yapmakta zorlanır, çünkü herkes kendi işini kritik görür. İşe yarayan hakem sorusu şudur: bu iş üç gün hiç yapılmazsa, şirket dışından biri fark eder mi?

Cevabı evet olan süreçler genellikle azdır: sipariş alma, sevkiyat, faturalama, tahsilat, kritik müşteri desteği ve bordro. Cevabı hayır olanlar, yani raporlama, içerik üretimi ve iç planlama toplantıları, kesinti sırasında bilinçli biçimde askıya alınır. Bu ayrımı önceden yapmazsanız kriz günü herkes kendi masasını kurtarmaya çalışır ve asıl kritik süreç en az ilgiyi gören iş olur.

Kritik süreçleri sayarken gelirin nereye yaslandığını da hesaba katın. Cirosunun büyük bölümü tek bir müşteriden gelen bir şirkette süreklilik sorusu teknik değil ticari bir sorudur; o müşterinin satın alma sürecindeki bir aksama, sizin sunucunuzdaki bir arızadan çok daha yıkıcıdır. Bu bağımlılığın nasıl ölçüleceğini ve nasıl azaltılacağını müşteri konsantrasyon riski yazısında ayrıntılı ele alıyoruz.

Ne kadar durabiliriz, ne kadar veri kaybedebiliriz?

İki sayı planın omurgasıdır. Birincisi bir sürecin ne kadar süre durabileceği, ikincisi geri dönüldüğünde ne kadarlık verinin kaybedilmiş olmasının kabul edilebileceğidir. İkisi de teknik ekibin değil, işi yönetenin kararıdır. Hiç veri kaybetmeyelim demek kolaydır; o cümlenin altyapı karşılığı masaya konduğunda çoğu şirket yarım günlük kayıp bizi batırmaz der ve bu tamamen meşru bir karardır. Kötü olan, bu kararın hiç verilmemesi ve yedekleme düzenini kuran kişinin tercihine bırakılmasıdır. Aşağıdaki tablo örnek bir yaklaşımı gösterir; süreler illüstratiftir, sizin işinizde başka çıkacaktır.

Bu hedefler yazıldığı anda altyapı kararları kendiliğinden netleşir. Günde bir kez alınan bir yedek, iki saatlik veri kaybı hedefiyle uyuşmaz; ya hedefi ya yedekleme sıklığını değiştirmeniz gerekir. Yedeğin sıklığı, saklama süresi, nereye alındığı ve geri dönüş testinin nasıl kurgulanacağı ayrı bir disiplindir ve bunları yedekleme ve felaket kurtarma yazısında adım adım anlatıyoruz.

Kesinti riski: bina, bağlantı ve tedarikçi

Kesintinin en sık görülen üç biçimi bina, bağlantı ve tedarikçidir; üçünün ortak özelliği sizin kontrolünüzde olmamasıdır. Bina tarafında sorulacak soru yangın çıkarsa değil, yarın sabah kapıya gelemezsek ilk dört saatte kim nereden çalışır sorusudur. Bağlantı tarafında en ucuz çözüm genellikle ikinci bir hat değil, ekibin telefon hattı üzerinden çalışmaya geçebilmesidir; yeter ki kritik sistemler tarayıcıdan ve telefondan erişilebilir olsun ve kimse yalnızca ofisteki bir bilgisayarda duran bir dosyaya bağımlı kalmasın.

Tedarikçi kesintisi en az hazırlık yapılan başlıktır. Tek bir kargo firması, tek bir üretici veya tek bir yazılım sağlayıcısı üzerinden yürüyen operasyonlarda alternatifin krizden önce belirlenmiş olması gerekir. Kriz günü alternatif aramak, alternatifi pahalıya ve kötü koşullarla bulmak demektir; oysa sakin bir haftada yapılan bir görüşme, ikinci bir tedarikçiyle en azından tanışıklık kurar.

Kesinti anında en çok ihmal edilen iş, müşteriye haber vermektir. Sessiz kalan şirket, ne kadar süreceğini bilmeyen müşterinin zihninde en kötü senaryoyu üretir; üstelik bu boşluğu genellikle rakip doldurur. Bir durum sayfasının ve toplu bilgilendirme akışının nasıl kurulacağını hizmet kesintisi duyurusu ve durum sayfası yazısında, gecikmeyi ve aksaklığı savunmaya geçmeden anlatmanın dilini ise müşteriye kötü haber verme yazısında bulabilirsiniz.

Veri kaybı riski: yedek almak yeterli değildir

Şirketlerin büyük bölümünde yedekleme vardır. Geri dönüş testi ise neredeyse hiç yoktur. Aradaki fark önemsiz değil: yedeğin varlığı bir dosyanın varlığını kanıtlar, geri dönüş testi ise o dosyadan çalışır bir şirket çıktığını kanıtlar. Bozuk veya eksik bir yedek, hiç yedek olmamasından daha tehlikelidir; çünkü ona güvenerek başka hiçbir önlem almazsınız.

Yedeği olan şirket değil, geri dönmeyi bir kez denemiş şirket hazırlıklıdır.

Testi yaparken kronometreyi de çalıştırın. Yedekten dönebiliyoruz cümlesi, dönüşün altı saat sürdüğü ortaya çıktığında bambaşka bir cümleye dönüşür ve kurtarma hedefinizi gözden geçirmeniz gerekir. Testin ikinci sorusu şudur: yedek nereye dönüyor? Aynı sisteme dönebiliyor olmak iyidir, ama sağlayıcı tarafında uzun bir kesinti yaşanırsa elinizde okunabilir bir kopya bulunması gerekir. Verinizi kendi kontrolünüzdeki bir formatta düzenli olarak dışarı alabiliyor olmak buradaki tek gerçek sigortadır; dışa aktarmanın pratiğini veri içe ve dışa aktarma yazısında topladık.

Bu sorunun bir adım ilerisi taşınabilirliktir: sistemi değiştirmek zorunda kalırsanız veriniz sizinle geliyor mu, yoksa yalnızca ekranda mı görünüyor? Sağlayıcıya bağımlılığın nasıl ölçüleceğini ve sözleşme aşamasında nelerin sorulacağını tedarikçiye bağımlılık ve veri taşınabilirliği yazısında ele aldık.

Kilit kişi riski: bilgiyi kafadan çıkarmak

Küçük şirketlerde en büyük süreklilik riski sunucu değil insandır. Tek bir kişinin bildiği bir şifre, tek bir kişinin tanıdığı bir tedarikçi, tek bir kişinin kafasındaki fiyat istisnaları, tek bir kişinin hatırladığı sözlü anlaşmalar. Bu bilgi yazılı değildir çünkü yazmaya kimsenin vakti olmaz ve o kişi zaten hep oradadır. Bir gün olmayana kadar.

Bu noktada standart tavsiye her şeyi dokümante edin der ve pratikte çoğu zaman çalışmaz. Doküman yazıldığı gün doğrudur, üç ay sonra kısmen yanlıştır, altı ay sonra kimse açmaz. Daha güvenilir yöntem rotasyondur: kritik işi üç ayda bir hafta boyunca yedek kişiye yaptırın. Dokümandaki eksik o hafta ortaya çıkar, üstelik yedek kişi işi bir kere gerçekten yapmış olur. Rotasyon, dokümantasyonun denetim mekanizmasıdır; ikisinden biri seçilecekse rotasyon daha değerlidir. Yine de yazılı bir temel gerekir ve kritik akışların hangi ayrıntı düzeyinde kayda geçirileceğini süreç dokümantasyonu ve SOP yazısında anlatıyoruz.

Erişim ve yetki devri

Kilit kişi riskinin en sert biçimi bilgi değil yetkidir. Ödemeyi onaylayabilen tek kişi, portala girebilen tek hesap, alan adının kayıtlı olduğu ve artık kimsenin şifresini bilmediği tek e-posta adresi. Yetki devri kriz anında kurulamaz; önceden ikinci bir onaycı tanımlanmış, şirket hesapları şahsi adresler yerine kurumsal adreslerde toplanmış ve kritik erişimler en az iki kişiye açılmış olmalıdır. Kimin neyi görebileceğini ve onaylayabileceğini sistem üzerinde kurgulamanın yolunu rol ve yetki yönetimi yazısında bulabilirsiniz.

Plan hangi formatta yazılmalı?

Kırk sayfalık bir süreklilik dokümanı kriz günü açılmaz. İşe yarayan format tek sayfadır ve telefon ekranında okunabilir olmalıdır. İçinde şunlar bulunur:

• Tetikleyici sonuç: Plan hangi durumda devreye girer; binaya giremiyoruz, sistem yok, veri kaybı, kilit kişi yok gibi tek cümlelik bir başlangıç koşulu.
• Çağrı sırası: Kimin kimi hangi sırayla arayacağı, ilk kararı kimin vereceği ve ilk iki kişiye ulaşılamazsa yetkinin kime geçtiği.
• Erişim kasası: Kritik hesapların nerede saklandığı ve acil durumda kimin açabileceği; şifrelerin kendisi değil, kasaya ulaşma yolu.
• Manuel yedek yöntem: Sistem yokken siparişin nasıl alınacağı, sevkiyatın hangi belgeyle çıkacağı ve dönüşte bu kayıtların sisteme nasıl işleneceği.
• Müşteri ve tedarikçi bildirimi: Kimin hangi kanaldan haber vereceği; hazır bir taslak metin planın içinde dursun, kriz günü metin yazılmaz.
• Dönüş kriteri: Normale dönüldüğünü kimin, neye bakarak ilan edeceği; bu satır olmadan şirket haftalarca yarı kriz modunda kalır.

Bu sayfanın bir kopyası dijital ortamın dışında da bulunmalıdır. Yalnızca kurum içi sistemde duran bir süreklilik planı, tam da ihtiyaç duyulduğu anda erişilemez olur; basılı bir nüsha ve birkaç kişinin telefonunda duran bir kopya bu ihtimali ortadan kaldırır.

Tatbikat yapmadan plan yoktur

Yazılmış ama hiç denenmemiş plan, iyi niyet beyanıdır. Tatbikat pahalı ve karmaşık olmak zorunda değil; bir saatlik masa başı senaryo çoğu şirket için fazlasıyla yeterlidir. Ekibi toplayın, bu sabah hiçbir sisteme giriş yapılamıyor deyin ve kimse bilgisayarına dokunmadan, yalnızca konuşarak ilk dört saati adım adım kurun. Ortaya çıkan boşluklar genellikle şaşırtıcıdır: kimse ana tedarikçinin telefonunu bilmez, bildirim metnini yazacak kişi izindedir, erişim kasasının anahtarı yine kilit kişinin üzerindedir.

Tatbikatı yılda iki kez yapmak ve her seferinde farklı bir sonuç senaryosunu denemek yeterlidir. Senaryolardan en az birinin fidye yazılımı veya hesap ele geçirilmesi gibi bir güvenlik olayı olmasında fayda var; bu tür olaylarda yedeklerin de şifrelenmiş olabileceği ihtimali planı baştan değiştirir ve çevrimdışı bir kopyanın neden gerektiğini kimseye anlatmanıza gerek kalmaz. Temel korunma adımlarını KOBİ için siber güvenlik yazısında derledik.

Bu yaklaşım nerede işe yaramaz?

Süreklilik planlaması her şeyi ikiye katlamak değildir. Altı kişilik bir ekipte ikinci ofis, ikinci internet hattı ve ikinci sunucu kurmak, korunmaya çalışılan riskten daha büyük bir yük üretir. Küçük ekiplerde doğru cevap çoğu zaman yedeklemek değil sadeleştirmektir: daha az sistem, daha az elle yapılan adım, daha az kişiye bağlı bilgi. Beş ayrı yerde tutulan müşteri listesini tek yerde toplamak, ikinci bir sunucu kiralamaktan daha çok süreklilik satın alır.

İkinci sınır şudur: plan kararsızlığı çözmez. Kriz anında asıl gecikme teknik değildir, bunu kim söyleyecek tereddüdüdür. Planın en değerli satırı bu yüzden kurtarma hedefi değil, karar yetkisidir. Üçüncü sınır ise şu: çok nadir ama çok yıkıcı olaylara ayrılan hazırlık zamanı, sık yaşanan küçük aksaklıklardan çalınır. Yılda üç kez yaşadığınız yarım günlük kesintiye hiç plan yapmayıp deprem senaryosuna bir hafta ayırmak, hazırlık gibi görünen bir erteleme biçimidir.

İlk otuz günde ne yapılmalı?

Başlamanın en hızlı yolu küçük tutmaktır. İlk hafta beş sonuç senaryosunu ve altı kritik süreci yazın; bu bir toplantıda biter. İkinci hafta her kritik süreç için durabileceği süreyi ve kabul edilebilir veri kaybını belirleyin, ardından mevcut yedekleme düzeninin bu hedeflerle uyuşup uyuşmadığına bakın. Üçüncü hafta erişim kasasını kurun ve her kritik hesabın en az iki kişiye açık olduğundan emin olun. Dördüncü hafta bir saatlik masa başı tatbikat yapın ve çıkan boşlukları o tek sayfaya işleyin.

Planı canlı tutmanın en kolay yolu onu takvimde zaten var olan bir ritüele bağlamaktır: yıllık planlama toplantısında, ekipte kişi değiştiğinde ve yeni bir sisteme geçildiğinde plan gözden geçirilir. Aynı mantığın hafiflemiş hâli öngörülebilir kesintiler için de geçerlidir; ekibin bir bölümünün aynı anda olmadığı dönemlerde işin nasıl yürüyeceğini izin ve tatil dönemlerinde satış sürekliliği yazısında ele alıyoruz.

Süreklilik planının işe yaraması için kritik bilginin tek bir kişinin kafasında değil, ekibin ortak eriştiği bir kayıtta durması gerekir. Rocketly'de müşteri geçmişi, teklifler, görevler, ön muhasebe kayıtları ve kullanıcı yetkileri aynı yerde tutulduğu için birinin yokluğu işin durması anlamına gelmez; ücretsiz hesap açarak kendi süreklilik düzeninizi kurabilirsiniz.