Afet kurtarma planı geliştirme en iyi uygulamaları veya kaynakları? [kapalı]

Eski ve biraz da olsa felaket kurtarma planının güncellenmesi ile ilgili bir proje yürütmekle görevlendirildim. Şimdilik sadece DR'nin BT tarafının çözülmesine bakıyoruz. Bunu en son yaptıklarında, tek bir felaket oluşturarak (veri merkezi sular altında kaldı) ve diğer tüm felaket tiplerinin dışlanmasını planlayarak kapsamlarını belirlediler. Daha iyi bir yaklaşım sergilemek istiyorum. Bunun çözülmüş bir sorun olduğunu biliyorum, diğer kuruluşlar DR planları yazdılar.

Planımız IT DR planımızı almak ve ilerlemek ve "Hey, IT için bir DR planında istediğimiz bu, Üniversitenin geri kalanının ne yaptığını temel alıyor mu?" değişti mi? " Planın geri kalanının ne olduğu hakkında çok iyi bir fikrimiz var ve bunun iyi geçmesini bekliyoruz.

Aradığım şey, bir DR planının nasıl kapsamına alınacağı ve hangi soruları düşünmem gerektiği konusunda rehberlik etmektir. DR planı geliştirme ile ilgili favori kaynaklarınız, kitaplarınız ve eğitiminiz var mı?

Mükemmel bir bilgi kaynağı, Afet Kurtarma Dergisi ( yaklaşık ).

Mevcut topluluk kaynakları , sürecin mükemmel bir taslağını ve sağlam bir iş sürekliliği planı ve süreci oluşturan çıktıları içeren Genel Kabul Görmüş Uygulamalar (GAP) belgesinin mevcut taslağını içerir . Ayrıca, çeşitli DR / BC konularını kapsayan çeşitli beyaz kağıtlar da mevcuttur .

Süreci göz korkutucu görünüyor, ancak nerede olmak istediğinizi (DRJ GAP belgesi gibi) iyi bir taslak ile sistematik olarak ele aldığınızda, harcanan zamanı optimize etmenizi ve son ürünün değerini en üst seviyeye çıkarmanızı sağlayabilirsiniz.

Üç aylık yayınlarının da ilginç ve bilgilendirici olduğunu düşünüyorum ( abone olun ).

Acil durum irtibat listeniz olduğundan emin olun. aka Geri Çağırma Kadrosu

Bir ağaca benzemeli ve kimin kiminle iletişim kuracağını göstermelidir. Bir şubenin sonunda, son kişi ilkini aramalı ve iletişim kuramayacak birini rapor etmelidir.

(Bu İK yoluyla koordine edilebilir ve her türlü felaket için kullanılabilir)

Fikirlerimizi eklersek, herkes kendi fikirlerini ekledikten sonra bu gönderiden hoş bir wiki oluşturabiliriz. Anlaşılan orada takip edilecek bir sürü şey var, ama bazılarının iyileşme konusunda özel öncelikleri var. Başlamak için işte benim.

Ağınızın çevrimdışı / uzak belgelerine sahip olduğunuzdan emin olun.

DR ile temel şeyler RTO'larınız (Kurtarma Süresi Hedefleri) ve RPO'larınız (Kurtarma Noktası Hedefleri) olup kabaca "geri almak için harcamak için ne kadar zaman kabul edilebilir ve ne kadar veri kaybedebiliriz" olarak çevrilir. İdeal bir dünyada cevaplar "hiçbiri ve hiçbiri" olacaktır, ancak bir DR senaryosu istisnai bir durumdur. Bunlar gerçekten müşterileriniz tarafından yönlendirilmelidir, ancak BT açısından başladığınızdan beri en iyi tahminde bulunabilirsiniz, ancak gerektiği gibi ayarlama veya azaltmaya hazır olun. Makul alabileceğiniz kadar "hiçbiri ve hiçbiri" ye yaklaşmayı hedeflemeniz iyidir, ancak azalan getirilerin ne zaman geldiğini farketmeniz gerekir.

Bu iki faktör, yılın farklı zamanlarında farklı olabilir ve farklı sistemlerde farklı olabilir.

Çok yönlü yaklaşımı severim; Bir DR senaryosuna yol açabilecek olayları listelemek cazip gelebilir, ancak bunlar gerçekten bir risk analizi / azaltma alıştırmasına aittir. DR ile olay çoktan gerçekleşti ve bunun ne kadar az alakalı olduğu ile ilgili özellikler (belki de DR tesislerinin kullanılabilirliğini etkileme hariç). Eğer bir sunucuyu kaybederseniz, yıldırım çarptığına, kazayla biçimlendirilmiş veya neyse ona bakılmaksızın geri almanız gerekir. Afetin ölçeğine ve yayılmasına odaklanan bir yaklaşımın sonuç vermesi daha olasıdır.

Müşterileri kullanmakta kullanılabilecek bir yaklaşım, buna katılmaya isteksiz olduklarını görürseniz, BT dışı bir açıdan onlara DR soruları sormaktır. Bütün kağıt dosyalarının alevler içinde yükselmesi durumunda planlarının ne olduğunu sormak burada bir örnektir. Bu, daha geniş DR olayına daha fazla dahil olmalarına yardımcı olabilir ve faydalı bilgileri kendi planlarınıza aktarabilir.

Son olarak planınızı düzenli olarak test etmek başarı için çok önemlidir. Kağıt üzerinde harika görünen güzel bir DR planına sahip olmak iyi bir şey değil ama bu onun hedeflerini karşılamıyor.

Aslında, "tek olay" geliştirme modeli ilk adım olarak iyi bir fikirdir. Bunun bir nedeni, planlama egzersizini daha gerçekçi ve odaklı kılmasıdır. Tamamen sel için plan yap. Sonra farklı bir olayı varsayalım (örneğin, uzun süreli elektrik kesintisi), bu planı uygulayın ve kırılmaları düzeltin. Birkaç yinelemeden sonra, plan nispeten sağlam olmalıdır.

Bazı düşünceler ... - müsait olmayan insanları hesaba kattığınızdan emin olun. Bir sel varsa, ilgili tüm personelin uygun olduğunu varsayamazsınız. Birileri tatilde olabilir, yaralanabilir veya ailesiyle ilgilenebilir.
- İletişim problemlerini ve zayıf yönlerini planlamak. Birden fazla numara ve birden fazla mod var.
- DR planının bir komuta zincirine ihtiyacı var. Kimin karar verdiğini bilmek çok önemlidir.
- Planın tesis dışı ve şebeke dışı da dahil olmak üzere yaygın olarak dağıtılması gerekir. Afet sırasında erişilebilir olması gerekiyor!

Çalıştığım yerde, son iki yılın her birinde geniş çaplı bir DR testi yapmakla meşgul oldum. Hizmetlerimizi, insanlarımızı ve süreçlerimizi "gerçekçi" durumlarda test etmenin faydalı olduğunu keşfettik. Bazı dersler öğrenilmiş (belki de açık), umarım onları faydalı bulursunuz:

• Test edilmemiş hizmetler, DR belgelerinde yazdıklarına rağmen, genellikle örtük, felakete neden olan bağımlılıklara sahiptir. Onları gerçekçi bir testle ya da iki ile çalkalamak, bir DR hazırlama işleminin kullanışlı ve ölçülebilir bir çıktısıdır.
• Test edilmemiş insanlar, sistemlerinin iyi olduğunu düşünür ve felaket durumunda “ne yapacaklarını bilirler”. Onları sıkışmak kadar gerçekçi bir testi ya da iki ile harika.
• Gerçek olmayan acil durumlarda denenmemiş işlemler hızla dağılır. Özellikle, karmaşık eskalasyon süreçleri temel olarak üst yönetim kesintisini muhteşem şekillerde bilgilendirmeye odaklandı. Operasyon personelinin ve diğer yanıt verenlerin ihtiyaçlarına odaklanan hafif süreçler, acil durumun ortaya çıkmasıyla ilgili merkezi bilgi kaynakları, açık sorumluluk sorumluluğu ve 'günlük' acil durum müdahale prosedürleri en iyi sonucu verir.

Anladığım kadarıyla DR planlama sürecinizle ilgili her şeyi teorik yapmamaya çalışmalısınız. Aslında olayları kırmak ve böylece kuruluşunuzun hazırlığı hakkında kesin veriler elde etmek için izin isteyin. Elbette bu, yönetimden ciddi bir destek gerektirecektir, ancak iş için gerçekten en kötüsü için prova yaparak birkaç gün geçirmek için harika bir şekilde odaklanabilir.

Cian

Süreklilik yönetimi ve felaket kurtarma konusuna odaklanan British Standards Institute (BSi) ' den birkaç standart var .

• BS 25999-1: 2006 İş sürekliliği yönetimi, Bölüm 1: Uygulama kodu
• BS 25999-2: 2007 İş sürekliliği yönetimi. Şartname
• BS 25777: 2008 Bilgi ve iletişim teknolojisi sürekliliği yönetimi. Uygulama kodu

Belli gözükebilir, ancak yukarıdaki ofis dışı dokümantasyonla devam etmek için tesis dışı (tercihen bölge dışı) yedekler aldığınızdan emin olun. Bu bir çevrimiçi depolama hizmeti veya kaset alabileceğiniz bir yer olabilir.

Tercihen bölge dışına diyorum, çünkü yıllık çok fazla doğal afetin olmadığı bir bölgeden geliyorum, fakat eğer varsa, bölgesel bir ölçekte kitle imhası (depremler, volkanlar). Bankanızın sıvı sıcak magma (/ Dr. Evil Voice) altında olana kadar yedeklerinizi bankadaki bir emanet kasasında bulundurmanız iyidir.

Hakkında okuduğum bir şey, büyük kuruluşun vurduğu zamanlar için sıcak bir siteyi sürdürmenin maliyetini paylaşan ajanslar. Her iki şirketin de sanallaştırma vb. Kullanarak sıcak saha için kritik önem taşıyan misyonunu geri kazanma planlarını yürürlüğe koyuyorlar ve ardından personeli yanıp sönen her şeyin kesin olduğundan emin olmak için paylaşıyorlar. Sadece bir düşünce.

Jon William Toigo'nun felaket kurtarma planlaması var , şimdi 3. baskıda, 4. baskı bloğunda (blog + kitap) ufukta.

Laura

İşte DR'nin temellerini veren SQLServerPedia'dan bir link.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Ayrıca "İş Sürekliliği" konusunu okuyun