BT hizmet sürekliliği yönetimi: kritik hizmetlerden teste kurulum yolu

BT hizmet sürekliliği ne demektir, neyi güvence altına alır?

BT hizmet sürekliliği, bir kesinti ya da felaket anında işin ihtiyaç duyduğu BT hizmetlerinin kabul edilebilir bir süre ve veri kaybı sınırı içinde yeniden ayağa kalkmasını sağlayan yönetim düzenidir. Odak sunucu ya da uygulama değil, hizmettir: müşterinin sipariş vermesi, bordronun çalışması, çağrı merkezinin telefon alması gibi iş sonuçlarıdır.

Bu yüzden BT hizmet sürekliliği yalnızca yedekleme işi değildir. Yedek almak veri kaybına karşı bir önlemdir; süreklilik yönetimi ise hangi hizmetin ne kadar sürede geri geleceğine karar verir, bunun için gereken altyapıyı, kişileri ve prosedürleri hazırlar ve bunu düzenli test eder. İş sürekliliği (BCP) kurumun tamamını kapsar, felaket kurtarma (DR) ise BT sistemlerinin geri getirilmesi kısmıdır. BT hizmet sürekliliği bu ikisinin BT tarafındaki kesişiminde durur.

Kurumda genellikle BT operasyon, bilgi güvenliği, risk ve iş birimleri birlikte sorumluluk taşır. İş birimleri neyin ne kadar önemli olduğunu, BT ise bunu hangi teknik yolla sağlayabileceğini söyler. Bu taraflar aynı dili konuşmadığında plan ya gereğinden pahalı ya da gereğinden zayıf kurulur.

Adım adım: süreklilik programını kurmak

Programı şu sırayla kurun.

Önce kapsamı ve sorumluluğu yazın. Hangi BT hizmetleri, hangi lokasyonlar ve hangi tehdit türleri kapsamda? Yönetim onayı alınmış bir sorumlu atayın. Sponsor olmayan süreklilik çalışması ilk yatırım talebinde durur.

Ardından hizmet envanterini çıkarın. Uygulamaları değil, iş sonucu üreten hizmetleri listeleyin ve her hizmetin hangi uygulama, veritabanı, ağ, kimlik doğrulama ve dış tedarikçi bileşenlerine dayandığını eşleştirin. Bu eşleştirme sonradan en kıymetli çıktıdır; çünkü bir hizmeti kurtarırken hangi bağımlılığın önce kalkması gerektiğini gösterir.

Sonra iş etki analizi yapın ve hizmetleri önceliklendirin. İş birimlerinden her hizmetin kesintide ne tür zarar ürettiğini ve hangi sürede bu zararın kabul edilemez hale geldiğini toplayın. Çıktı, hizmetleri kritiklik kademelerine ayıran bir listedir. Bu adım ayrıca ayrı bir beceri olarak ele alınır.

Ardından kurtarma hedeflerini koyun: kurtarma süresi hedefi (RTO) ve veri kaybı sınırı (RPO). Kademeye göre belirlenen bu hedefler, ardından seçilecek çözümün maliyetini ve mimarisini belirler.

Daha sonra kurtarma stratejisini seçin, planı yazın, ekibi eğitin ve test edin. Son olarak değişiklik yönetimi, yeni hizmet devreye alma ve olay sonrası incelemeyle planı güncel tutun. Plan bir kez yazılıp raflara kalkan bir doküman olursa ilk gerçek olayda işe yaramaz.

Kritik hizmetleri önceliklendirme ve kademelendirme

Tüm hizmetleri aynı hızla kurtarmak hem mümkün değildir hem de gereksiz maliyettir. Bu yüzden hizmetleri kritiklik kademelerine ayırırsınız. Kademeyi belirleyen sorular nettir.

• Kesinti anında doğrudan gelir ya da müşteri kaybı doğuyor mu?
• Yasal ya da sözleşmesel yükümlülük, örneğin raporlama süresi veya hizmet seviyesi taahhüdü ihlal ediliyor mu?
• Başka kritik hizmetler bu hizmete bağımlı mı?
• Kesinti ne kadar sürerse zarar telafi edilemez hale gelir?
• İş, kesinti sırasında manuel bir yöntemle sürdürülebilir mi?

Örneğin bir perakende şirketinde ödeme geçidi ve sipariş yönetimi en üst kademede, ürün fotoğraflarını yöneten içerik sistemi ise daha düşük kademede olabilir. Ama sipariş yönetimi kimlik doğrulama hizmetine dayanıyorsa, kimlik hizmeti de en az sipariş yönetimi kadar yüksek kademede kurtarılmalıdır. Bağımlılık analizi yapılmadan kademe vermek, plan sahada denendiğinde ortaya çıkan sürprizlerin en büyük kaynağıdır.

Kurtarma stratejisi: hedefe uygun çözümü seçmek

Strateji, hedeflerin maliyetle buluştuğu yerdir. Genel seçenekler şunlardır.

• Yedekten geri yükleme: düşük maliyetlidir, kurtarma süresi uzundur; kritiklik düşük hizmetlere uygundur.
• Hazır bekleyen yedek ortam: ana ortamın bir kopyası daha az kaynakla çalışır halde tutulur, kesintide büyütülür.
• Sürekli çoğaltma ve yedek ortama geçiş: veri kaybı çok az, kurtarma süresi kısadır; maliyet ve karmaşıklık yüksektir.
• Çoklu bölge ya da çoklu lokasyonda aktif çalışma: en yüksek kritikliğe sahip hizmetler içindir.
• Dış tedarikçi hizmetleri: bir tedarikçinin süreklilik taahhüdünü sözleşmeyle güvence altına almak.

Seçimi yaparken yedek ortamın gerçekten ayrı bir arıza alanında olduğundan emin olun; aynı veri merkezi ya da aynı bulut bölgesinde kalan bir kopya, bölgesel bir kesintiye karşı koruma sağlamaz. Kimlik doğrulama, ağ adresleme (DNS) ve sertifika gibi ortak bağımlılıkları da ayrıca düşünün; uygulama ayağa kalksa bile kullanıcı giriş yapamıyorsa hizmet kurtarılmış sayılmaz.

Plan, roller ve iletişim

Kurtarma planının her hizmet için şunları içermesi gerekir: tetikleme koşulu, kimin karar verdiği, kurtarma adımlarının sırası, her adımı yapacak kişi ve yedeği, gerekli erişim bilgilerinin nerede bulunduğu, geri dönüş ve doğrulama kriterleri. Adımlar, bir olay anında stresli çalışan birinin okuyup uygulayabileceği kadar net yazılmalıdır.

Planın dışında iletişim düzeni ayrıca tasarlanmalıdır. Kesinti sırasında yönetime, iş birimlerine, müşterilere ve gerekirse düzenleyicilere kimin, hangi kanaldan, hangi sıklıkta bilgi vereceği önceden belli olmalı. Ana iletişim sistemi de kesintiden etkilenebileceği için yedek bir iletişim kanalı tanımlayın. Plana erişim sorunu da gerçek bir risktir: plan yalnızca çöken sistemin içinde duruyorsa kimse okuyamaz.

Test etmek ve güncel tutmak

Test edilmemiş plan, varsayımlar toplamıdır. Test türlerini artan zorlukla uygulayın.

• Masa başı tatbikat: ekip belirli bir senaryoyu konuşarak adım adım yürür; plandaki boşluklar ve belirsiz sorumluluklar görülür.
• Bileşen testi: tek bir yedeği geri yüklemek ya da tek bir sistemi yedeğe geçirmek.
• Hizmet kurtarma testi: bir hizmetin uçtan uca ayağa kaldırılıp iş kullanıcısı tarafından doğrulanması.
• Kapsamlı geçiş tatbikatı: kritik hizmetlerin yedek ortamdan çalıştırılması; planlı ve iş etkisi yönetilen biçimde.

Her testten sonra bulgular kayda geçirilir, sahibi ve tarihi atanır, plan güncellenir. Ayrıca yeni sistem eklendiğinde, mimari değiştiğinde ya da kritik bir kişi ayrıldığında planı gözden geçirme tetikleyicisi koyun. Süreklilik, olgunluğa bir kez ulaşılan bir proje değil, değişiklik yönetimiyle birlikte yürüyen bir süreçtir.

Bu beceriyi geliştirmek ve Mindset bağlamı

Başlangıç için kendi kurumunuzda tek bir kritik hizmeti seçin ve bağımlılık haritasını çıkarın: hangi uygulama, veri, ağ ve kimlik bileşenine dayanıyor, bunlardan biri düşerse ne oluyor? Sonra aynı hizmet için hedef süre ve veri kaybı sınırını iş birimiyle konuşun. Bu çalışma tek başına bile eksikleri açık eder.

Mindset kataloğundaki İş Etki Analizi (BIA) ve Kritik BT Hizmetlerinin Önceliklendirilmesi eğitimi süreç envanteri ve hizmet eşleştirmesi, etki ölçeği, kurtarma hedeflerinin belirlenmesi gibi modüllerle bu kademelendirme işini işler; BCP / DR Planlama ve Felaket Kurtarma Planlaması eğitimleri ise plan yazımı, tatbikat tasarımı ve test süreçlerini kapsar. BT operasyon, risk ve bilgi güvenliği ekipleri programı birlikte kurmak istediğinde bu eğitimler aynı çerçeve üzerinde ortak dil sağlar.