Herkese merhaba, adım Igor Tyukachev ve iş sürekliliği danışmanıyım. Bugünkü yazımızda ortak gerçekler üzerine uzun ve meşakkatli bir tartışma yapacağız.Deneyimlerimi paylaşmak ve şirketlerin iş sürekliliği planı geliştirirken yaptığı temel hatalardan bahsetmek istiyorum.
1. Rastgele RTO ve RPO
Gördüğüm en önemli hata, iyileşme süresinin (RTO) birdenbire ortadan kaldırılmasıdır. Hiç yoktan var - örneğin, birinin önceki iş yerinden getirdiği SLA'dan iki yıl öncesine ait bazı rakamlar var. Bunu neden yapıyorlar? Sonuçta, tüm yöntemlere göre, öncelikle iş süreçlerine yönelik sonuçları analiz etmeniz ve bu analize dayanarak hedef kurtarma süresini ve kabul edilebilir veri kaybını hesaplamanız gerekir. Ama böyle bir analiz yapmak bazen uzun zaman alır, bazen pahalı olur, bazen nasıl yapılacağı çok belli olmaz, ne yapılması gerektiğini vurgulayın. Ve birçok kişinin aklına ilk gelen şey: “Hepimiz yetişkiniz ve işlerin nasıl yürüdüğünü anlıyoruz. Zaman ve para kaybetmeyelim! Artı veya eksiyi olması gerektiği gibi alalım. Proleter ustalığını kullanarak kafanı çıkar! RTO iki saat olsun.”
Bu neye yol açıyor? Belirli rakamlarla gerekli RTO/RPO'yu sağlamaya yönelik faaliyetler için yönetime para almak üzere geldiğinizde, bunun her zaman gerekçelendirilmesi gerekir. Gerekçe yoksa şu soru ortaya çıkıyor: Bunu nereden aldın? Ve cevaplanacak hiçbir şey yok. Sonuç olarak işinize olan güven kaybolur.
Üstelik bazen bu iki saatlik iyileşmenin maliyeti bir milyon dolara mal oluyor. Ve RTO'nun süresini haklı çıkarmak bir para meselesidir ve bu konuda çok büyük bir meseledir.
Ve son olarak, BCP ve/veya DR planınızı sanatçılara (kaza anında koşuyor ve kollarını sallıyor olacaklar) getirdiğinizde, onlar da benzer bir soru soracaklar: Bu iki saat nereden geldi? Ve eğer bunu net bir şekilde anlatamazsanız o zaman ne size ne de belgenize güvenirler.
Bir kağıt parçası uğruna bir kağıt parçası, bir abonelikten çıkma olduğu ortaya çıkıyor. Bu arada, bazıları bunu sırf düzenleyicinin gereksinimlerini karşılamak için kasıtlı olarak yapıyor.
Anladın mı
2. Her şeyin ilacı
Bazı insanlar, tüm iş süreçlerini her türlü tehditten korumak için bir BCP planının geliştirildiğine inanıyor. Son dönemde “Kendimizi nelerden korumak istiyoruz?” sorusu gündeme geliyor. Cevabı duydum: "Her şey ve daha fazlası."
Ancak gerçek şu ki, plan yalnızca koruma amaçlıdır özel Şirketin temel iş süreçleri özel tehditler. Bu nedenle bir plan geliştirmeden önce risklerin ortaya çıkışını değerlendirmek ve bunların işletme açısından sonuçlarını analiz etmek gerekir. Şirketin hangi tehditlerden korktuğunu anlamak için risk değerlendirmesine ihtiyaç vardır. Binanın yıkılması durumunda bir süreklilik planı, yaptırım baskısı durumunda başka bir süreklilik planı, su baskını durumunda ise üçüncü bir plan olacaktır. Farklı şehirlerdeki iki aynı sitenin bile önemli ölçüde farklı planları olabilir.
Bir şirketin tamamını, özellikle de büyük bir BCP'yle korumak imkansızdır. Örneğin devasa X5 Perakende Grubu, iki temel iş süreciyle sürekliliği sağlamaya başladı (bunun hakkında yazmıştık) ). Ve tüm şirketi tek bir planla kuşatmak kesinlikle gerçekçi değil; bu, herkesin sorumlu olduğu ve kimsenin sorumlu olmadığı "toplu sorumluluk" kategorisindendir.
ISO 22301 standardı aslında şirketteki süreklilik sürecinin başladığı politika kavramını içermektedir. Neyi, neyden koruyacağımızı anlatıyor. İnsanlar koşarak gelip şunu şunu eklemek isterse, örneğin:
— BCP'ye saldırıya uğrama riskini de ekleyelim mi?
Veya
— Geçtiğimiz günlerde yağmur sırasında üst katımızı su bastı - su baskını durumunda ne yapılacağına dair bir senaryo ekleyelim mi?
Daha sonra onları hemen bu politikaya yönlendirin ve belirli şirket varlıklarını yalnızca önceden kararlaştırılan belirli tehditlere karşı koruduğumuzu, çünkü bunların artık öncelikli olduğunu söyleyin.
Değişiklik önerileri gerçekten uygun olsa bile, bunları politikanın bir sonraki versiyonunda dikkate almayı teklif edin. Çünkü bir şirketi korumak çok paraya mal olur. Dolayısıyla BCP planındaki tüm değişikliklerin bütçe komitesinden ve planlamadan geçmesi gerekiyor. Şirketin iş sürekliliği politikasını yılda bir kez veya şirketin yapısında veya dış koşullardaki önemli değişikliklerden hemen sonra gözden geçirmenizi öneririz (okuyucuların bunu söylediğim için kusura bakmayın).
3. Fanteziler ve gerçeklik
Çoğu zaman, bir BCP planı hazırlarken yazarların dünyanın ideal bir resmini tanımlamaları olur. Mesela “ikinci bir veri merkezimiz yok ama varmış gibi plan yazacağız.” Ya da işletme henüz altyapının bir kısmına sahip değil ancak çalışanlar yine de gelecekte ortaya çıkması umuduyla bunu plana ekleyecekler. Daha sonra şirket, planı gerçeğe dönüştürecek: ikinci bir veri merkezi inşa edecek ve diğer değişiklikleri açıklayacak.
Solda BCP'ye karşılık gelen altyapı, sağda ise gerçek altyapı
Bunların hepsi bir hata. Bir BCP planı yazmak para harcamak anlamına gelir. Şu anda işe yaramayan bir plan yazarsanız, çok pahalı kağıtlara para ödersiniz. Ondan kurtulmak imkansızdır, onu sınamak imkansızdır. İş uğruna çalışmak olduğu ortaya çıktı.
Oldukça hızlı bir şekilde bir plan yazabilirsiniz ancak bir yedekleme altyapısı oluşturmak ve tüm koruma çözümlerine para harcamak uzun ve pahalıdır. Bu bir yıldan fazla sürebilir. Zaten bir planınız olduğu ortaya çıkabilir ve bunun altyapısı iki yıl içinde ortaya çıkacak. Neden böyle bir plana ihtiyaç duyuldu? Seni neyden koruyacak?
BCP geliştirme ekibinin uzmanlar için ne yapmaları gerektiğini ve ne zaman yapmaları gerektiğini bulmaya başlaması da bir hayaldir. Şu kategoriden geliyor: “Taygada bir ayı gördüğünüzde ayıdan ters yöne dönüp ayının hızını aşan bir hızla koşmanız gerekiyor. Kış aylarında izlerinizi kapatmanız gerekiyor.”
4. Üst kısımlar ve kökler
Dördüncü en önemli hata ise planı çok yüzeysel ya da çok detaylı yapmaktır. Altın bir ortalamaya ihtiyacımız var. Plan aptallar için çok detaylı olmamalı ama böyle bir şeyle sonuçlanacak kadar genel de olmamalı:
Genel olarak kolay
5. Sezar'a göre Sezar'ınki nedir, tamirciye göre tamircininki nedir?
Bir sonraki hata bir öncekinden kaynaklanıyor: Tek bir plan, yönetimin tüm düzeyleri için tüm eylemleri kapsayamaz. BCP planları genellikle büyük finansal akışı olan büyük şirketler için geliştirilir (bu arada, bizim Ortalama olarak büyük Rus şirketlerinin %48'i önemli mali kayıplara yol açan acil durumlarla ve çok seviyeli bir yönetim sistemiyle karşı karşıya kaldı. Bu tür şirketler için her şeyi tek bir belgeye sığdırmaya çalışmamalısınız. Şirket büyük ve yapılandırılmışsa planın üç ayrı düzeyi olmalıdır:
- stratejik seviye - üst düzey yönetim için;
- taktik seviye - orta düzey yöneticiler için;
- ve operasyonel seviye - sahada doğrudan yer alanlar için.
Örneğin, arızalı bir altyapının onarılmasından bahsediyorsak, stratejik düzeyde kurtarma planının etkinleştirilmesine karar verilir, taktik düzeyde süreç prosedürleri tanımlanabilir ve operasyonel düzeyde belirli hizmete alma talimatları vardır. ekipman parçaları.
Bütçesiz BCP
Herkes kendi sorumluluk alanını ve diğer çalışanlarla olan bağlantılarını görüyor. Kaza anında herkes bir plan açar, hızla üzerine düşeni bulur ve ona göre hareket eder. İdeal olarak, hangi sayfaları açacağınızı ezbere hatırlamanız gerekir, çünkü bazen dakikalar önemlidir.
6. Rol yapma
Bir BCP planı hazırlarken başka bir hata: Plana belirli isimleri, posta adreslerini ve diğer iletişim bilgilerini eklemeye gerek yoktur. Belgenin metninde yalnızca kişisel olmayan roller belirtilmeli ve bu rollere belirli görevlerden sorumlu olanların isimleri verilmeli ve bunların irtibat kişileri plan ekinde listelenmelidir.
Neden?
Günümüzde çoğu insan her iki ila üç yılda bir iş değiştiriyor. Ve plan metnine tüm sorumluları ve onların bağlantılarını yazarsanız, planın sürekli olarak değiştirilmesi gerekecektir. Ve büyük şirketlerde, özellikle de devlet şirketlerinde, herhangi bir belgede yapılan her değişiklik tonlarca onay gerektirir.
Acil bir durum ortaya çıkarsa ve planı çılgınca gözden geçirmek ve doğru kişiyi aramak zorunda kalırsanız, değerli zamanınızı kaybedeceğinizden bahsetmiyorum bile.
Hayat hilesi: Bir uygulamayı değiştirdiğinizde çoğu zaman onu onaylamanıza bile gerek kalmaz. Bir ipucu daha: Plan güncelleme otomasyon sistemlerini kullanabilirsiniz.
7. Versiyonlama eksikliği
Genellikle 1.0 sürümünde bir plan oluştururlar ve ardından tüm değişiklikleri düzenleme modu olmadan ve dosya adını değiştirmeden yaparlar. Aynı zamanda önceki versiyona göre neyin değiştiği çoğu zaman belirsizdir. Versiyonlamanın yokluğunda plan, hiçbir şekilde takip edilmeyen kendi hayatını yaşar. Herhangi bir BCP planının ikinci sayfası, sürümü, değişikliklerin yazarını ve değişikliklerin listesini belirtmelidir.
Bunu artık kimse çözemez
8. Kime sormalıyım?
Çoğu zaman şirketlerde BCP planından sorumlu bir kişi bulunmaz ve iş sürekliliğinden sorumlu ayrı bir departman da bulunmaz. Bu onurlu sorumluluk CIO'ya, onun yardımcısına ya da "siz bilgi güvenliğiyle ilgileniyorsunuz, bu yüzden ek olarak BCP de var" ilkesine göre verilmiştir. Sonuç olarak plan, yukarıdan aşağıya doğru geliştirilir, üzerinde mutabakata varılır ve onaylanır.
Planın saklanmasından, içindeki bilgilerin güncellenmesinden ve revize edilmesinden kim sorumludur? Bu reçete edilmeyebilir. Bunun için ayrı bir çalışanı işe almak israftır, ancak mevcut olanlardan birine ek görevler yüklemek elbette mümkündür, çünkü artık herkes verimlilik için çabalıyor: "Ona bir fener asalım ki geceleri biçebilsin" ama bu gerekli mi?
BCP'nin kuruluşundan iki yıl sonra sorumlularını arıyoruz
Bu nedenle çoğu zaman şu şekilde olur: Bir plan geliştirildi ve tozla kaplansın diye uzun bir kutuya konuldu. Hiç kimse bunu test etmiyor veya alaka düzeyini koruyamıyor. Bir müşteriye geldiğimde en sık duyduğum cümle şu: “Bir plan var ama çok önceden geliştirildi, test edilip edilmediği bilinmiyor, işlemediğine dair şüpheler var.”
9. Çok fazla su
Girişin beş sayfa uzunluğunda olduğu, ön koşulların açıklandığı ve projedeki tüm katılımcılara teşekkür edildiği, şirketin ne yaptığı hakkında bilgilerin yer aldığı planlar var. Yararlı bilgilerin bulunduğu onuncu sayfaya geldiğinizde veri merkeziniz çoktan sular altında kalmıştır.
Güncel okumaya çalışırken veri merkeziniz sular altında kalırsa ne yapmalısınız?
Tüm kurumsal “suyu” ayrı bir belgeye yerleştirin. Planın kendisi son derece spesifik olmalıdır: Bu görevden sorumlu kişi bunu yapar, vb.
10. Ziyafet kimin pahasına?
Çoğu zaman plan yaratıcıları şirketin üst yönetiminden destek almaz. Ancak iş sürekliliğini yönetemeyen veya gerekli bütçe ve kaynaklara sahip olmayan orta düzey yönetimden destek var. Örneğin BT departmanı bütçesi dahilinde BCP planını oluşturuyor ancak CIO şirket resminin tamamını göremiyor. En sevdiğim örnek video konferanstır. CEO'nun video konferansı işe yaramazsa kimin içini çıkaracak? “Sağlık sağlamayan” CIO. Peki CIO açısından şirketteki en önemli şey nedir? İnsanların onu her zaman "sevdiği" şey: anında iş açısından kritik bir sisteme dönüşen video konferans. Ve iş açısından bakıldığında - VKS yok, sadece düşünün, Brejnev döneminde olduğu gibi telefonda konuşacağız...
Ayrıca BT departmanı genellikle bir felaket durumunda asıl görevinin kurumsal BT sistemlerinin işleyişini yeniden sağlamak olduğunu düşünür. Ancak bazen bunu yapmanıza gerek kalmaz! Çok pahalı bir yazıcıda kağıt parçalarının basılması şeklinde bir iş süreci varsa, o zaman yedek olarak böyle ikinci bir yazıcı satın almamalı ve arıza durumunda yanına koymamalısınız. Kağıt parçalarını elle geçici olarak renklendirmek yeterli olabilir.
BT bünyesinde sürekli koruma oluşturuyorsak üst yönetimin ve iş temsilcilerinin desteğini almalıyız. Aksi takdirde, BT departmanının içinde dolaşarak belirli bir dizi sorunu çözebilirsiniz, ancak gerekli olanların hepsini çözemezsiniz.
Yalnızca BT departmanının DR planları olduğunda durum böyle görünüyor
10. Test yok
Bir plan varsa test edilmesi gerekir. Standartlara aşina olmayanlar için bu hiç de açık değildir. Mesela her yerde “acil çıkış” tabelaları asılı. Ama söyle bana, yangın kovan, kancan ve küreğin nerede? Yangın musluğu nerede? Yangın söndürücü nereye yerleştirilmelidir? Ama bunu herkesin bilmesi gerekiyor. Bir ofise girerken yangın söndürücü bulmak bize hiç mantıklı gelmiyor.
Belki planın test edilmesinin gerekliliği planın kendisinde belirtilmelidir, ancak bu tartışmalı bir karardır. Her durumda, bir planın ancak en az bir kez test edilmesi durumunda işe yaradığı düşünülebilir. Yukarıda da bahsettiğim gibi “Bir plan var, tüm altyapı hazırlanmış ama her şeyin planda yazıldığı gibi olacağı da bir gerçek değil. Çünkü test etmediler. Asla".
Sonuç olarak
Bazı şirketler ne tür sorunların yaşanabileceğini ve bunların ne kadar olası olduğunu anlamak için geçmişlerini analiz edebilir. Araştırmalar ve deneyimler kendimizi her şeyden koruyamayacağımızı gösteriyor. Er ya da geç her şirketin başına bir şey gelebilir. Bir diğer husus ise bu veya buna benzer bir duruma ne kadar hazırlıklı olacağınız ve zamanında işinizi toparlayıp toparlayamayacağınızdır.
Bazı insanlar sürekliliğin her türlü riskin gerçekleşmemesi için nasıl ortadan kaldırılacağıyla ilgili olduğunu düşünüyor. Hayır, mesele şu ki riskler gerçekleşecek ve biz buna hazır olacağız. Askerler savaşta düşünmek için değil, harekete geçmek için eğitilirler. BCP planı için de durum aynıdır: işinizi mümkün olan en kısa sürede geri yüklemenize olanak tanır.
BCP gerektirmeyen tek ekipman
İgor Tyukaçev,
İş Sürekliliği Danışmanı
Bilgisayar Sistemleri Tasarım Merkezi
"Jet Bilgi Sistemleri"
Kaynak: habr.com