Her sabah bilgi teknolojileri ekibine aynı bildirim geliyor: “Yedekleme başarıyla tamamlandı.” Yönetim raporunda ilgili gösterge yeşil. Dosyaların kopyalandığı, işlemin hata vermeden sonuçlandığı görülüyor.

Bir kesinti yaşandığında ise işletmenin sorusu değişiyor: Sipariş alabiliyor muyuz? Üretim emrini açabiliyor muyuz? Depodan doğru ürünü çıkarabiliyor, sevkiyat belgesini düzenleyebiliyor muyuz?

Yedekleme işleminin tamamlanması bu soruların tamamına cevap vermez. Verinin geri yüklenmesi, uygulamanın çalışması ve iş sürecinin kullanılabilir hâle gelmesi ayrı ayrı değerlendirilmelidir.

Belgelendirme, denetim, danışmanlık ve eğitim alanlarındaki 20 yıllık mesleki birikimimle bu konuya bakarken, teknik başarı kaydıyla işletmenin hizmet verebilme kapasitesi arasındaki bağlantıyı önemsiyorum. Yönetimin ihtiyaç duyduğu güvence, belirli bir dosyanın saklanmasının ötesine geçer.

Asıl soru, kritik işi kabul edilebilir koşullarda yeniden yapıp yapamadığımızdır.

Bir kesintide her sistemi aynı anda çalışır hâle getirmek mümkün olmayabilir. Önceliğin hangi hizmete verileceği, işin etkileri değerlendirilerek belirlenmelidir.

Üretim yapan bir işletmede sipariş, reçete, stok ve etiketleme sistemleri birbirine bağlı olabilir. Hizmet kuruluşunda ise randevu, müşteri kaydı, iletişim ve ödeme sistemleri birlikte çalışıyor olabilir.

Teknik ekip hangi sunucunun önce kurulacağını bilebilir. Ancak hangi işin ne kadar süre durabileceğini ve hangi düzeyde hizmetle yeniden başlayabileceğini süreç sahipleriyle yönetim belirlemelidir.

ISO 22301, iş sürekliliği yönetim sistemlerine ilişkin uluslararası çerçeveyi sunar. Bu çerçevede ele alınan hazırlık, kuruluşun faaliyetlerini kesintiler karşısında sürdürebilme ihtiyacıyla ilişkilidir.

Temsili bir üretim işletmesinde sipariş ve stok uygulamasının yedeği başarıyla geri yükleniyor. Kullanıcı giriş ekranı açılıyor. Teknik test tamamlanmış kabul ediliyor.

Depo çalışanı sevkiyat hazırlamaya başladığında etiket yazıcısının bağlantısının çalışmadığı anlaşılıyor. Taşıyıcıya veri gönderen entegrasyon da devreye alınmamış. Ürün stokta, sipariş sistemde; fakat sevkiyat tamamlanamıyor.

Bu örnekte geri yükleme işlemi işe yaramıştır. Ancak sınanan kapsam, işletmenin ihtiyacını bütünüyle karşılamamıştır.

Testin kabul ölçütü baştan “Bir siparişin depoda hazırlanması ve sevkiyat kaydının tamamlanması” olarak tanımlansaydı bağlantılı bileşenler daha görünür olurdu.

Yedekten dönüş hazırlığı; uygulama, yetkilendirme, bağlantılar, gerekli cihazlar ve iş akışının birlikte değerlendirilmesini gerektirir. En kritik eksik, tek başına önemsiz görünen bir bağımlılık olabilir.

Önce işletmenin hangi hizmetleri kritik kabul ettiğini ve bu önceliklerin nasıl belirlendiğini incelerim. Ardından yedekleme kapsamıyla bu hizmetler arasındaki bağlantıya bakarım.

Gerekli veriler, yapılandırmalar ve erişim bilgileri kapsama alınmış mı? Geri yükleme için ihtiyaç duyulan anahtarlar veya yönetici yetkileri kesinti sırasında erişilebilir olacak mı? Bu erişim güvenli biçimde düzenlenmiş mi?

Test kayıtlarında yalnızca “başarılı” sonucunu görmekle yetinmem. Hangi yedekten dönüldüğü, işlemin ne zaman başladığı, ne zaman tamamlandığı ve hangi işlevlerin kontrol edildiği anlaşılmalıdır.

Teknik ekibin onayının yanında ilgili iş biriminin değerlendirmesi önemlidir. Satış örnek siparişi açabilmiş mi? Depo stok hareketini gerçekleştirebilmiş mi? Geri yüklenen kayıtların doğruluğu örneklerle sınanmış mı?

NIST’in yedekleme rehberi de verinin korunmasıyla birlikte yedeklerin sürdürülmesi ve sınanmasına odaklanır. Yedeğin mevcut olduğunu bilmek, kullanılabilirliğini değerlendiren testin yerini tutmaz.

İkinci temsili örnekte gece alınan yedek kullanılarak sistem geri getiriliyor. Ancak kesintiden önce sabah saatlerinde yeni siparişler girilmiş. Kesinti sırasında da çalışanlar bazı işlemleri geçici dosyalarda takip etmiş.

Sistem çalışmaya başladığında yeni bir soru ortaya çıkıyor: Hangi işlemler kayıp, hangileri yeniden girilmeli ve hangileri zaten tamamlandı?

Kontrolsüz veri girişi mükerrer sipariş, yanlış stok veya tekrarlanan fatura oluşturabilir. Bu nedenle kesinti sırasında kullanılan alternatif kayıtların normal sisteme nasıl aktarılacağı önceden düşünülmelidir.

Burada iki ayrı hedef bulunur: Hizmetin ne kadar sürede geri gelmesi gerektiği ve ne kadar geriye ait veri kaybının kabul edilebileceği. Bu hedefler birbirinin yerine kullanılamaz.

Bir sistem hızlı açılmış olabilir; fakat kaybolan işlem aralığı işletmenin kabul edebileceğinden büyükse hedef karşılanmamış olabilir. Değerlendirme, süreç sahiplerinin gerçek ihtiyacına dayanmalıdır.

İşletmelere ilk önerim, tek bir kritik iş akışını seçerek başlamalarıdır. Örneğin “siparişin alınmasından sevkiyata kadar” olan süreç için gerekli sistemler, kişiler ve dış hizmetler birlikte listelenebilir.

İkinci önerim, testin başarı ölçütlerini önceden yazmalarıdır. Uygulamanın açılması, örnek işlemin tamamlanması, kayıtların tutarlılığı ve iş biriminin kabulü ayrı adımlar olarak değerlendirilebilir.

Test, canlı faaliyeti ve gerçek verileri riske atmayan, yetkilendirilmiş bir ortamda planlanmalıdır. Gerçek bir siber olay sonrasında ise zararlı etkinin giderildiği değerlendirilmeden sistemleri yeniden bağlamak güvenli kabul edilemez. Tatbikatla olay müdahalesinin koşulları ayrılmalıdır.

Üçüncü önerim, dış hizmet sağlayıcıların sorumluluklarını netleştirmeleridir. “Bulutta tutuluyor” veya “hizmet sağlayıcı yedekliyor” ifadeleri tek başına yeterli açıklama değildir. Nelerin korunduğu, geri dönüşü kimin başlatacağı ve hangi desteğin sağlanacağı bilinmelidir.

Son olarak testte bulunan eksikler kapatıldıktan sonra ilgili adım yeniden sınanmalıdır. Eksik bağlantının tanımlanmış olması, çalıştığının gösterilmesiyle tamamlanır.

Bunlar işletmenin koşullarına göre uyarlanabilecek danışmanlık önerileridir. Amaç, teknik kayıtlarla yönetimin süreklilik beklentisini aynı değerlendirmede buluşturmaktır.

Bir sonraki yönetim toplantısında yedekleme raporunun yanına şu soruyu ekleyin:

Bu sorunun cevabı, yedekleme yatırımının işletmeye sağladığı güvenceyi somutlaştıracaktır.