Bir sabah fabrikanın elektriği gelmiyor, ya da muhasebe sunucusu fidye yazılımıyla şifrelenmiş, ya da tek internet hattınız bir kazı çalışmasında kesilmiş. O an ilk soru teknik değildir: Kim karar verecek, müşterilere ne söylenecek, siparişler nasıl alınacak, maaşlar zamanında ödenecek mi? İş sürekliliği planı (Business Continuity Plan, BCP), bu soruların cevabını kriz anında değil, önceden yazmaktır. Bu yazıda bir iş sürekliliği planının nelerden oluştuğunu ve orta ölçekli bir işletmenin bu planı adım adım nasıl hazırlayabileceğini anlatıyoruz. BT sistemlerinin geri dönüş tarafı için felaket kurtarma sayfamıza bakabilirsiniz.
İş sürekliliği planı nedir?
İş sürekliliği planı, bir kesinti sırasında kritik iş süreçlerinin kabul edilebilir bir seviyede devam etmesini ve normale dönüşü sağlayan yazılı bir plandır. Kapsamı yalnızca bilgi teknolojileri değildir: insanlar, binalar, tedarikçiler, iletişim ve alternatif çalışma yöntemleri de planın parçasıdır. Bu alandaki uluslararası çerçeve ISO 22301 iş sürekliliği yönetim sistemi standardıdır; ancak planın değeri bir belgeye değil, gerçekten uygulanabilir olmasına bağlıdır.
Felaket kurtarma ile farkı
İki kavram sık karıştırılır. Felaket kurtarma (Disaster Recovery, DR), BT sistemlerinin ve verinin geri getirilmesine odaklanır. İş sürekliliği ise işin devamına bakar. Sunucu dört saatte geri gelebilir; ama o dört saat boyunca siparişlerin telefonla alınıp kâğıda yazılması, sevkiyatın nasıl planlanacağı ve müşteriye ne söyleneceği iş sürekliliği planının konusudur. Felaket kurtarma, iş sürekliliği planının BT ayağıdır.
1. Adım: İş etki analizi
Plan, hangi süreçlerin gerçekten kritik olduğunu bilmekle başlar. İş etki analizinde (Business Impact Analysis, BIA) her iş süreci için şu sorular sorulur:
- Bu süreç durursa bir saat içinde ne olur? Bir gün içinde? Bir hafta içinde?
- Kayıp nasıl oluşur: gelir kaybı, sözleşme cezası, yasal süre, müşteri kaybı, itibar?
- Bu süreç hangi sistemlere, hangi kişilere ve hangi tedarikçilere bağlı?
- Sistem olmadan elle yürütülebilir mi, ne kadar süreyle?
Sonuçta süreçler kademelere ayrılır. Genellikle süreçlerin küçük bir kısmı gerçekten kritiktir: üretim planlama, sipariş alma, sevkiyat, finans. Kaynaklar önce bunlara ayrılır.
2. Adım: Hedefleri belirleyin
İş etki analizinin sonucu, her kritik süreç ve onu destekleyen sistemler için iki hedeftir: En fazla ne kadar süre durabilir (RTO)? En fazla ne kadar veri kaybı kabul edilebilir (RPO)? Bu hedefler yedekleme sıklığını, geri dönüş yöntemini ve maliyeti doğrudan belirler. İki kavramı ve hedeflerin nasıl belirleneceğini RTO ve RPO nedir yazımızda ayrıntılı anlattık.
| Süreç | Bağlı sistemler | Örnek hedef | Geçici çözüm |
|---|---|---|---|
| Sipariş alma | ERP, e-posta, telefon santrali | 4 saat | Telefon ve form ile manuel kayıt |
| Üretim planlama | ERP, dosya sunucusu | 8 saat | Son basılı plan ile devam |
| Maaş ödemesi | Bordro yazılımı, banka bağlantısı | 2 gün | Bir önceki ayın listesi üzerinden |
Tablodaki rakamlar yalnızca örnektir; sizin hedefleriniz iş süreçlerinize göre farklı olacaktır.
3. Adım: Riskleri ve senaryoları yazın
Her olası olay için ayrı plan yazmak gerekmez. Senaryoları etkilerine göre gruplamak daha işe yarar:
- Bina kullanılamıyor: Yangın, su baskını, deprem, uzun süreli elektrik kesintisi.
- BT sistemleri kullanılamıyor: Fidye yazılımı, sunucu arızası, veri merkezi kesintisi, yanlışlıkla silinen veri.
- Bağlantı yok: İnternet hattı ya da şubeler arası bağlantı kesildi.
- Kilit kişiler yok: Tek bilen kişinin izinde, hasta ya da işten ayrılmış olması.
- Tedarikçi yok: Kritik bir yazılım ya da hizmet sağlayıcısı hizmet veremiyor.
Kocaeli gibi deprem riski yüksek bir bölgede, verinin bir kopyasının farklı bir şehirde durup durmadığı bu aşamada mutlaka sorulmalıdır.
4. Adım: Planı yazın ve altyapıyı hazırlayın
Planda neler olmalı?
İyi bir iş sürekliliği planı kısa, net ve kriz anında okunabilir olmalıdır. Yüz sayfalık bir belge o gün kimse tarafından açılmaz. Planda şunlar yer almalıdır:
- Karar yetkisi: Planı kim devreye alır, kim onun yerine geçer?
- Kriz ekibi ve iletişim listesi: Çalışanların, yöneticilerin, tedarikçilerin ve BT desteğinin güncel telefon numaraları. Bu liste yalnızca e-postada ya da sunucuda durmamalı; e-posta da çökmüş olabilir.
- İletişim planı: Çalışanlara, müşterilere ve tedarikçilere kim, hangi kanaldan, ne söyleyecek?
- Süreç bazında geçici çalışma yöntemleri: Sistem yokken işin nasıl yürüyeceği.
- BT kurtarma adımları: Hangi sistem hangi sırayla, hangi yedekten, kim tarafından geri getirilecek?
- Normale dönüş: Geçici dönemde kâğıda yazılan kayıtların sisteme nasıl aktarılacağı.
BT altyapısı planı karşılıyor mu?
Plan, altyapı onu karşılayabildiği ölçüde gerçektir. Kritik sistemler için şu sorular sorulmalıdır:
- Yedekler düzenli alınıyor mu ve bir kopya farklı bir lokasyonda mı duruyor? Yapı için yedekleme sayfamıza bakabilirsiniz.
- Yedekler fidye yazılımına karşı korunuyor mu?
- RTO’su saatlerle ölçülen sistemler için replikasyon ya da yedek lokasyonda hazır bekleyen kopya var mı?
- Kullanıcılar ofis kullanılamadığında evden güvenli şekilde bağlanabiliyor mu?
- İkinci bir internet hattı ya da yedek bağlantı var mı?
5. Adım: Test edin ve güncel tutun
Test edilmemiş bir plan, bir varsayımdır. Testler farklı seviyelerde yapılabilir: Masa başı tatbikatta ekip bir senaryoyu adım adım konuşur ve eksikleri bulur. Teknik testte bir sunucu gerçekten yedekten geri yüklenir ve süre ölçülür. Kapsamlı tatbikatta ise bir süreç bütünüyle alternatif yöntemle yürütülür. Teknik testlerin nasıl planlanacağını felaket kurtarma testi yazımızda anlattık.
Plan yılda en az bir kez ve her büyük değişiklikte gözden geçirilmelidir: yeni bir sistem, yeni bir şube, değişen bir tedarikçi ya da işten ayrılan bir kriz ekibi üyesi. Güncel olmayan bir telefon listesi, özenle yazılmış bir planı bile işlemez hâle getirir.
Unna ile iş sürekliliği
İş sürekliliği planının iş tarafı sizin, BT tarafı çoğu zaman bizim uzmanlığımızdır. İkisini birlikte ele alırız.
- Önce dinleriz. Kritik süreçlerinizi ve bu süreçlerin bağlı olduğu sistemleri iş birimlerinizle birlikte çıkarırız.
- Birlikte planlarız. Her sistem için RTO ve RPO hedeflerini belirler, yedekleme ile mi yoksa felaket kurtarma çözümüyle mi korunacağını maliyetle dengeleyerek tasarlarız.
- Kurar ve test ederiz. Altyapıyı kurar, gerçek bir geri dönüş testiyle ölçülen süreleri hedeflerle karşılaştırırız.
- Yanınızda kalırız. Testleri düzenli olarak tekrarlar, sistemleriniz değiştikçe planın BT bölümünü birlikte güncelleriz.
Başlamak için bize yazın; önce dinleriz.
