İş Sürekliliği Tatbikat Türleri: Masa Başı, Fonksiyonel, Tam Ölçekli

Kriz anında ilk kez açılan bir iş sürekliliği planı çoğu zaman çalışmaz. Telefon numaraları eskimiştir, görev sahipleri değişmiştir, “yedek sistem” diye yazılan sunucu hiç ayağa kaldırılmamıştır. Bu açıkları gerçek bir kesinti yaşamadan görmenin kontrollü tek yolu tatbikattır. Aşağıda masa başı, fonksiyonel ve tam ölçekli tatbikatları neyi ölçtükleri, ne kadar riskli ve pahalı oldukları üzerinden karşılaştırıyor; yıllık programı ve tatbikat raporunu sahadaki haliyle anlatıyoruz.

Tatbikatla neyi test ediyorsunuz: plan, ekip, teknoloji?

Tür seçmeden önce tek bir soruyu cevaplayın: bu tatbikatla neyi kanıtlamak istiyoruz? Üç ayrı hedef var ve her biri farklı bir format ister.

• Planın doğruluğu ve eksiksizliği: Görev listeleri, aktivasyon kriterleri, iletişim bilgileri ve bağımlılıklar gerçeği yansıtıyor mu? Bunu masa başında, düşük maliyetle sınarsınız.
• Ekibin karar ve koordinasyon yeteneği: Kriz ekibi eksik bilgiyle karar verebiliyor mu, yetki sınırını biliyor mu, bilgi akışı işliyor mu? Bu, senaryo baskısı altında yürütülen masa başı veya fonksiyonel tatbikatla ölçülür.
• Teknik ve operasyonel kurtarma kapasitesi: Sistemler hedef sürede ayağa kalkıyor mu, alternatif çalışma yeri gerçekten kullanılabiliyor mu? Bunu ancak fiilen bir şeyin yapıldığı fonksiyonel veya tam ölçekli tatbikat kanıtlar.

ISO 22301:2019 madde 8.5, süreklilik stratejilerinin ve çözümlerinin etkinliğini doğrulayan bir tatbikat programı ister. Tatbikatlar süreklilik hedefleriyle tutarlı olmalı, amacı açık senaryolara dayanmalı, planlı aralıklarla ve önemli değişikliklerden sonra yapılmalı; sonuçlar bulgu, öneri ve aksiyon içeren resmi bir raporla kayda alınmalıdır. Standart tek bir tür dayatmaz, seçimi kuruluşa bırakır. Denetçinin sorusu da buna göre değişir. “Tatbikat yaptınız mı?” diye sormaz; “Programınız stratejilerinizin tamamını makul bir döngüde kapsıyor mu?” diye sorar.

Tatbikat türleri karşılaştırma tablosu

Kaynaklar farklı adlar kullanır; örneğin NIST SP 800-84 masa başı ve fonksiyonel tatbikatı ayrı formatlar olarak tanımlar. Sahada dört kademeli bir sınıflandırma çoğu program için yeterli oluyor:

Tür	Ne yapılır?	Ölçtüğü yetenek	Operasyon riski
Plan gözden geçirme (walkthrough)	Plan sahipleriyle bölüm bölüm okunur	Planın güncelliği ve tutarlılığı	Yok
Masa başı (tabletop)	Kolaylaştırıcı senaryo ve ek bilgi verir, ekip tartışarak karar alır	Karar, yetki, iletişim akışı	Yok
Fonksiyonel	Belirli bir yetenek fiilen çalıştırılır: çağrı ağacı, sistem geri yükleme, alternatif yerde çalışma	Kurtarma süresi, prosedürün uygulanabilirliği	Düşük–orta (izole ortamda düşük)
Tam ölçekli	Birden çok ekip ve lokasyon gerçek kaynaklarla, gerçek zamanlı çalışır	Uçtan uca kurtarma ve koordinasyon	Orta–yüksek

Maliyet sıralaması da aynıdır. Plan gözden geçirme birkaç saatlik bir toplantıdır. Tam ölçekli tatbikat ise haftalarca hazırlık, iş birimlerinden kapasite, bazen tedarikçi katılımı ve hafta sonu mesaisi ister. Olgunlaşmamış bir iş sürekliliği ve uyum programında doğrudan tam ölçekli tatbikata atlayan kuruluşların çoğu ilk saatte tıkanır; çünkü planın temel eksikleri, pahalı bir senaryonun ortasında ortaya çıkar. Sıra atlanmaz.

Masa başı tatbikat senaryosu nasıl kurulur?

Masa başı tatbikat, senaryosu kadar iyidir. “Sunucu odası yandı” gibi genel bir anlatı, katılımcıdan “yedekten döneriz” gibi yüzeysel cevaplar alır ve hiçbir açığı göstermez. Senaryoyu şu sırayla kurun:

1. Hedefleri yazın: En fazla 3–4 ölçülebilir hedef. Örnek: “Kriz ekibi ilk 60 dakika içinde aktivasyon kararını yetkili kişiye aldırabiliyor mu?”, “Sipariş alma süreci için alternatif yöntem tanımlı mı?”
2. Kapsamı sınırlayın: Hangi lokasyon, hangi süreçler, hangi ekipler oyunda? Kapsam dışı kalan her şey için “sorunsuz çalışıyor” varsayımı yazılı olmalı; yoksa tartışma kapsam dışına kayar.
3. Gerçekçi tetikleyici seçin: İş etki analizi ve risk değerlendirmesinden çıkan senaryoları kullanın: fidye yazılımıyla ERP’nin şifrelenmesi, ana veri merkezinde uzun süreli elektrik kesintisi, kritik tedarikçinin hizmet verememesi, binaya erişimin engellenmesi.
4. Zaman çizelgesi ve ek bilgiler (inject) hazırlayın: Senaryo tek seferde anlatılmaz; T+0, T+2 saat, T+1 gün gibi aşamalarla yeni bilgi verilir. “Basından bir muhabir arıyor”, “Yedekler de şifrelenmiş görünüyor”, “En büyük müşteri sevkiyat tarihini soruyor.” Her inject’in hangi hedefi ölçtüğünü not edin.
5. Rolleri ayırın: Kolaylaştırıcı, gözlemci/not tutucu ve katılımcılar ayrı kişilerdir. Kolaylaştırıcı katılımcı olursa tartışmayı yönlendiren kişi aynı zamanda değerlendirilen kişi olur.
6. Beklenen davranışı önceden tanımlayın: Gözlemcinin formunda, her aşamada planın ne öngördüğü yazılı olmalı. Böylece “iyi geçti” izlenimi yerine plan ile davranış arasındaki fark kaydedilir.

Siber senaryolar masa başında en çok bulgu üreten senaryolardır. Teknik ekiple iş birimlerinin karar noktalarını aynı masada çakıştırırlar: sistemleri kapatma kararı, fidye ödememe kararı, müşteriye bildirim. Sahada en sık gördüğümüz tablo şu: BT “ağı izole edelim” der, üretim “hat durursa ne olacak” diye sorar ve kararı kimin vereceği planda yazmaz. Üretim ortamına özgü bir örnek için IATF 16949 siber saldırı acil durum planı ve tatbikatı yazısına bakabilirsiniz; kriz ekibinin toplantı ritmi ve karar kaydı ise kriz yönetimi ve kriz iletişimi planı rehberinde.

Fonksiyonel tatbikat: planlama ve riskler

Fonksiyonel tatbikatta konuşmak yetmez, bir şey fiilen yapılır. Yaygın örnekler: çağrı ağacının mesai dışında çalıştırılması (test tasarımı ve ölçüm için çağrı ağacı ve acil iletişim listesi rehberine bakın), kritik bir uygulamanın yedekten izole bir ortama geri yüklenmesi, bir ekibin bir gün boyunca alternatif çalışma yerinden çalışması, DR sahasına planlı geçiş ve geri dönüş.

Bu testler canlı operasyona dokunabilir. Planlama belgesinde şu başlıklar olmadan pencere açmayın:

• Kapsam ve izolasyon: Geri yüklenen sistem üretim ağına, e-posta sunucusuna veya entegrasyon arayüzlerine bağlanacak mı? Aynı isimli ikinci bir sunucunun üretim ağında görünmesi kimlik doğrulama ve veri tutarlılığı sorunu çıkarır. Geri yüklenen bir domain controller’ın ya da kuyruğundaki işleri yeniden gönderen bir uygulama sunucusunun üretime sızması, sahada en çok can yakan izolasyon hatasıdır.
• Durdurma kriterleri: Tatbikat hangi durumda kesilir, kararı kim verir? Örneğin canlı bir hizmette yanıt süresinin bozulması veya gerçek bir olayın başlaması.
• Geri dönüş planı: Tatbikat başarısız olursa üretimi eski haline getiren adımlar ve bu adımların süresi.
• Değişiklik kaydı ve onay: Değişiklik yönetiminden geçmiş, iş birimlerine duyurulmuş bir zaman penceresi.
• Ölçüm noktaları: Başlangıç, ilk sistem erişimi, uygulamanın iş birimince doğrulanması ve tamamlanma zaman damgaları.

Ölçümdeki klasik hata, sunucu açıldığında saati durdurmaktır. RTO, iş biriminin süreci yeniden yürütebildiği anda biter. Sunucunun açılmasıyla kullanıcının sipariş girebilmesi arasında lisans sunucusu, DNS kayıtları, entegrasyon servis hesapları ve yetki sorunları yüzünden saatler geçebilir. Kapanış imzası bu yüzden iş birimi temsilcisine aittir. BT’nin değil. Fidye yazılımı senaryosuna özgü teknik kurtarma adımları için siber güvenlik tarafındaki siber kurtarma tatbikatı rehberi ayrıntı veriyor.

Tam ölçekli tatbikat ne zaman gerekir?

Tam ölçekli tatbikatta birden çok süreç ve ekip aynı anda, gerçek kaynaklarla çalışır. Her kuruluş için yıllık bir zorunluluk değildir. Şu durumlarda gündeme alın:

• Müşteri veya düzenleyici, uçtan uca kurtarma yeteneğinin kanıtlanmasını açıkça istiyorsa,
• Ana tesis kaybında birden çok ekibin aynı alternatif yere taşınması gibi koordinasyonu belirleyici bir strateji varsa,
• Fonksiyonel testler tek tek başarılı olduğu halde ekipler arası devir noktalarında (BT kurtarması bitti, iş birimi devralıyor) belirsizlik sürüyorsa.

Tam ölçekli tatbikatın en büyük riski, hazırlık sürecinde planın “tatbikat için” düzeltilmesidir. Haftalarca hazırlanan ekip, gerçek bir olayda karşılaşmayacağı kadar iyi bir başlangıç noktasından oyuna girer. Senaryo ayrıntılarını katılımcılardan saklamak ve gözlemcileri bağımsız seçmek bu sapmayı azaltır.

Yıllık tatbikat programı örneği

Program, tatbikatların alt alta yazıldığı bir takvim değildir. Hangi stratejinin hangi yöntemle, hangi sıklıkta doğrulanacağını gösteren bir kapsama haritasıdır. Aşağıdaki tablo tek lokasyonlu, orta ölçekli bir kuruluş için örnektir; sıklıkları kendi BIA sonuçlarınıza göre ayarlayın.

Dönem	Tatbikat	Tür	Doğrulanan strateji
1. çeyrek	BCP ve iletişim listesi gözden geçirmesi	Plan gözden geçirme	Plan güncelliği
1. çeyrek	Mesai dışı çağrı ağacı testi	Fonksiyonel	Ekiplere ulaşma
2. çeyrek	Fidye yazılımı senaryosu	Masa başı	Kriz kararı, iletişim
3. çeyrek	ERP’nin izole ortama geri yüklenmesi	Fonksiyonel	BT kurtarma, RTO/RPO
3. çeyrek	Finans ekibinin alternatif yerden çalışması	Fonksiyonel	Alternatif çalışma yeri
4. çeyrek	Kritik tedarikçi kesintisi senaryosu	Masa başı	Tedarikçi sürekliliği

Programın yanında, her kritik sürecin en az bir tatbikatta yer aldığını gösteren bir eşleme tablosu tutun. Bir yılda tüm stratejilere ulaşamıyorsanız çok yıllı döngü tanımlayabilirsiniz; önemli olan hangi stratejinin ne zaman doğrulanacağının kayıtlı ve yönetimce onaylı olmasıdır. Yeni bir sistem devreye alındığında, organizasyon değiştiğinde veya gerçek bir olay yaşandığında program yeniden gözden geçirilir. Gerçek olay da bir tatbikattır. Kaydını aynı formatta tutun.

Değerlendirme raporu ve iyileştirme aksiyonları

Tatbikatın değeri, arkasından açılan aksiyonlarla ölçülür. Bitişte katılımcılarla kısa bir sıcak değerlendirme (hot debrief) yapılır; hafızalar tazeyken “nerede takıldık” sorusu sorulur. Resmi rapor birkaç gün içinde hazırlanır ve şu bölümleri içerir:

• Tatbikatın hedefleri, türü, kapsamı, tarihi ve katılımcılar,
• Her hedef için sonuç: karşılandı, kısmen karşılandı, karşılanmadı ve dayanağı,
• Ölçülen süreler ile hedef süreler (RTO, ilk iletişim süresi vb.) karşılaştırması,
• Planda bulunan hatalar ve plan dışında yapılan doğaçlamalar,
• İyi işleyen uygulamalar (bir sonraki revizyonda korunması gerekenler),
• Sahibi, termini ve önceliği belirlenmiş iyileştirme aksiyonları.

Doğaçlamalar raporun en değerli kısmıdır. Ekip plana bakmadan bir şeyi “bildiği yoldan” çözdüyse, ya plan yanlıştır ya da o bilgi tek bir kişinin kafasındadır. İkisi de bulgudur. Aksiyonlar ayrı bir listede unutulmamalı; düzeltici faaliyet kayıtlarına bağlanmalı ve yönetimin gözden geçirmesine girdi olarak raporlanmalıdır. Bir sonraki tatbikatı, önceki tatbikatta açılan aksiyonların kapanıp kapanmadığını doğrulayacak şekilde tasarlarsanız program kendi iyileştirme döngüsünü besler. Plan dokümanının hangi bölümlerinin tatbikatla güncelleneceğini görmek için iş sürekliliği planı içeriği yazısına bakabilirsiniz.

Tatbikat programını BIA ve süreklilik stratejileriyle uyumlu kurmak için iş sürekliliği planı ve iş etki analizi çalışmasıyla başlayabilir, ISO 22301 belgelendirme hedefiniz varsa programı ISO 22301 iş sürekliliği yönetimi kapsamında yapılandırabilirsiniz.

Sık sorulan sorular

Masa başı tatbikat ISO 22301 için yeterli mi?

Standart belirli bir tür zorunlu tutmaz; ama programın süreklilik stratejilerinin etkinliğini doğrulaması beklenir. Teknik kurtarma süresi veya alternatif çalışma yerinin kullanılabilirliği masa başında kanıtlanamaz. Bu yüzden programda en az birkaç fonksiyonel test bulunmalıdır.

Tatbikat ne sıklıkla yapılmalı?

Sabit bir sıklık yoktur. Yaygın uygulama, her kritik sürecin yılda en az bir kez bir tatbikatta yer alması ve büyük organizasyonel veya teknik değişiklikten sonra ilgili bölümün yeniden test edilmesidir. Sıklığı BIA’daki kritiklik ve değişim hızı belirler.

Tatbikatı önceden haber vermeden yapmak doğru mu?

Habersiz tatbikat gerçekçidir ama canlı operasyona etkisi yüksektir. Çağrı ağacı testi gibi düşük riskli tatbikatlarda habersiz uygulama mantıklıdır. Sistem geçişi içeren fonksiyonel testlerde ise yönetim onayı ve iş birimlerinin önceden bilgilendirilmesi şarttır.

Tatbikat raporunu kim onaylamalı?

Raporu tatbikat koordinatörü hazırlar, iş sürekliliği sorumlusu gözden geçirir. Sonuçlar ve açılan aksiyonlar yönetimin gözden geçirmesinde üst yönetime sunulur. Kritik bulgularda aksiyon sahiplerini ve terminleri yönetim kabul etmelidir.