การพัฒนาแผนกู้คืนภัยพิบัติแนวทางปฏิบัติที่ดีที่สุดหรือทรัพยากร? [ปิด]

ฉันได้รับมอบหมายให้นำโครงการเกี่ยวกับการอัปเดตแผนกู้คืนความเสียหายที่ค่อนข้างเก่า สำหรับตอนนี้เราแค่มองหาด้านไอทีของ DR ที่แยกออก ครั้งล่าสุดที่พวกเขาทำสิ่งนี้พวกเขากำหนดขอบเขตโดยสร้างความหายนะครั้งเดียว (ศูนย์ข้อมูลถูกน้ำท่วม) และวางแผนสำหรับการยกเว้นภัยพิบัติประเภทอื่น ๆ ทั้งหมด ฉันต้องการที่จะใช้วิธีการโค้งมนที่ดีขึ้น ฉันรู้ว่านี่เป็นปัญหาที่แก้ไขแล้วองค์กรอื่น ๆ ได้เขียนแผน DR ไว้

แผนของเราคือการนำแผน DR IT ของเราไปข้างหน้าและพูดว่า "เฮ้นี่คือสิ่งที่เราต้องการในแผน DR สำหรับไอทีมันสอดรับกับส่วนที่เหลือของมหาวิทยาลัยที่กำลังทำอยู่หรือไม่ ต้องการเปลี่ยนไหม? " เรามีความคิดที่ดีงามว่าส่วนที่เหลือของแผนคืออะไรและเราคาดหวังให้สิ่งนี้ดีกว่า

สิ่งที่ฉันกำลังมองหาคือแนวทางในการกำหนดขอบเขตแผน DR และคำถามที่ฉันควรคิดเกี่ยวกับ คุณมีแหล่งข้อมูลหนังสือการฝึกอบรมที่เกี่ยวข้องกับการพัฒนาแผน DR หรือไม่?

แหล่งข้อมูลที่ยอดเยี่ยมคือDisaster Recovery Journal ( ประมาณ )

แหล่งข้อมูลชุมชนที่มีอยู่รวมถึงร่างปัจจุบันของเอกสารการปฏิบัติทั่วไปที่ยอมรับได้ (GAP)ซึ่งมีโครงร่างที่ยอดเยี่ยมของกระบวนการและสิ่งที่ส่งมอบซึ่งเป็นแผนและกระบวนการต่อเนื่องทางธุรกิจที่มั่นคง นอกจากนี้ยังมีเอกสารสีขาวหลายฉบับที่ครอบคลุมหัวข้อ DR / BC ต่างๆ

กระบวนการดังกล่าวดูน่ากลัว แต่หากเข้าใกล้อย่างเป็นระบบโดยมีโครงร่างที่ดีว่าคุณต้องการจะจบที่ใด (เช่นเอกสาร DRJ GAP) คุณสามารถมั่นใจได้ว่าคุณจะใช้เวลาให้เกิดประโยชน์สูงสุดและเพิ่มมูลค่าของผลิตภัณฑ์สุดท้าย

ฉันพบว่าสิ่งพิมพ์รายไตรมาสของพวกเขาน่าสนใจและให้ข้อมูลเช่นกัน ( สมัครสมาชิก )

ตรวจสอบให้แน่ใจว่าคุณมีบัญชีรายชื่อติดต่อฉุกเฉิน อาคาเรียกคืนบัญชีรายชื่อ

ควรมีลักษณะเหมือนต้นไม้และแสดงให้เห็นว่าใครติดต่อใคร ในตอนท้ายของสาขาบุคคลสุดท้ายควรโทรไปก่อนและรายงานทุกคนที่ไม่สามารถติดต่อได้

(สิ่งนี้สามารถประสานผ่าน HR และใช้สำหรับภัยพิบัติทุกประเภท)

หากเราเพิ่มความคิดของเราเราสามารถสร้าง wiki ที่ดีจากโพสต์นี้เมื่อทุกคนได้เพิ่มความคิดของตนเอง ฉันเข้าใจว่ามีหลายสิ่งที่ต้องติดตาม แต่พวกเราบางคนมีลำดับความสำคัญเฉพาะเมื่อพูดถึงการฟื้นฟู เพื่อเริ่มต้นนี่คือของฉัน:

ตรวจสอบให้แน่ใจว่าคุณมีเอกสารออฟไลน์ / รีโมทของเครือข่ายของคุณ

ด้วย DR สิ่งพื้นฐานคือ RTOs ของคุณ (Recovery Time Objectives) และ RPOs (Recovery Point Objectives) ซึ่งแปลว่า "เวลาเท่าไหร่ที่ยอมรับได้ที่จะต้องใช้มันคืนและเราสามารถเสียข้อมูลได้มากแค่ไหน" ในโลกอุดมคติคำตอบคือ "ไม่มีและไม่มี" แต่สถานการณ์ DR เป็นกรณีพิเศษ สิ่งเหล่านี้ควรได้รับแรงผลักดันจากลูกค้าของคุณ แต่เนื่องจากคุณเริ่มจากมุมมองด้านไอทีคุณสามารถคาดเดาได้ดีที่สุด แต่เตรียมพร้อมที่จะปรับขึ้นหรือลงตามที่ต้องการ การตั้งเป้าหมายใกล้เคียงกับ "ไม่มีและไม่มี" ตามที่คุณสามารถรับได้เป็นสิ่งที่ดี แต่คุณจะต้องสามารถรับรู้ได้เมื่อจุดที่ผลตอบแทนลดน้อยลง

ปัจจัยทั้งสองนี้อาจแตกต่างกันในแต่ละช่วงเวลาของปีและแตกต่างกันไปตามระบบที่ต่างกัน

ฉันชอบวิธีการที่โค้งมนมากขึ้น มันเป็นการล่อลวงให้เขียนรายการเหตุการณ์ที่อาจนำไปสู่สถานการณ์จำลอง DR แต่สิ่งเหล่านี้เป็นส่วนหนึ่งของการฝึกซ้อมเพื่อลดความเสี่ยงและการลดความเสี่ยง ด้วย DR เหตุการณ์นี้ได้เกิดขึ้นแล้วและรายละเอียดของสิ่งที่เกี่ยวข้องน้อยกว่า (ยกเว้นในแง่ของผลกระทบต่อความพร้อมใช้งานของสิ่งอำนวยความสะดวก DR) หากคุณทำเซิร์ฟเวอร์หายคุณต้องนำมันกลับคืนโดยไม่คำนึงว่าเซิร์ฟเวอร์ถูกฟ้าผ่าฟอร์แมทโดยไม่ตั้งใจหรืออะไรก็ตาม วิธีการเพ่งความสนใจไปที่ขนาดและการแพร่กระจายของภัยพิบัติมีแนวโน้มที่จะให้ผลลัพธ์

วิธีหนึ่งที่จะใช้กับลูกค้าหากคุณพบว่าพวกเขาไม่เต็มใจที่จะมีส่วนร่วมคือการถามคำถาม DR จากมุมมองที่ไม่ใช่ด้านไอที ถามว่าแผนของพวกเขาคืออะไรถ้าไฟล์กระดาษทั้งหมดของพวกเขาขึ้นไปในเปลวไฟเป็นตัวอย่างที่นี่ วิธีนี้จะช่วยให้พวกเขามีส่วนร่วมในสิ่งที่กว้างขึ้น DR และสามารถป้อนข้อมูลที่เป็นประโยชน์ในแผนของคุณเอง

ในที่สุดการทดสอบแผนของคุณเป็นประจำนั้นมีความสำคัญต่อความสำเร็จ มันไม่ดีเลยที่มีแผนการ DR ที่สวยงามที่ดูดีบนกระดาษ แต่ก็ไม่เป็นไปตามวัตถุประสงค์

อันที่จริงรูปแบบการพัฒนา "เหตุการณ์เดียว" เป็นความคิดที่ดีเป็นขั้นตอนแรก เหตุผลหนึ่งที่ทำให้การวางแผนมีความสมจริงและเน้นมากขึ้น วางแผนสำหรับน้ำท่วมตลอดทาง จากนั้นสมมติว่ามีเหตุการณ์ที่แตกต่าง (พูดไฟฟ้าดับในระยะยาว) นำแผนนั้นไปใช้และแก้ไขสิ่งที่ผิดพลาด หลังจากทำซ้ำสองสามครั้งแผนควรจะค่อนข้างแข็งแกร่ง

ความคิดบางอย่าง ... - ให้แน่ใจว่าบัญชีสำหรับคนที่ไม่สามารถใช้งานได้ หากมีน้ำท่วมคุณไม่สามารถสันนิษฐานได้ว่าพนักงานที่เกี่ยวข้องทั้งหมดพร้อมให้บริการ บางคนอาจไปเที่ยวพักผ่อนหรือได้รับบาดเจ็บหรือติดต่อกับครอบครัว
- วางแผนสำหรับปัญหาการสื่อสารและจุดอ่อน มีหลายหมายเลขและหลายโหมด
- แผน DR จำเป็นต้องมีสายการบังคับบัญชา การรู้ว่าใครเป็นผู้ตัดสินใจสำคัญที่สุด
- แผนจะต้องมีการกระจายอย่างกว้างขวางรวมถึงนอกสถานที่และนอกกริด มันจะต้องสามารถเข้าถึงได้ในช่วงภัยพิบัติ!

ที่ที่ฉันทำงานอยู่ฉันมีส่วนร่วมในการทำข้อสอบ DR ขนาดใหญ่ในช่วงสองปีที่ผ่านมา เราได้ค้นพบว่าการทดสอบบริการผู้คนและกระบวนการต่าง ๆ ในสถานการณ์ "สมจริง" นั้นมีประโยชน์ บทเรียนบางบทได้เรียนรู้ (อาจชัดเจน) โดยหวังว่าคุณจะพบว่ามีประโยชน์:

• บริการที่ไม่ได้รับการทดสอบถึงแม้ว่าสิ่งที่พวกเขาเขียนไว้ในเอกสาร DR มักจะมีการพึ่งพาโดยนัยและก่อให้เกิดหายนะ การเขย่าพวกเขาด้วยการทดสอบจริงหรือสองอย่างนั้นเป็นผลลัพธ์ที่มีประโยชน์และสามารถวัดได้ของกระบวนการเตรียมการ DR
• คนที่ยังไม่ผ่านการทดสอบมักจะคิดว่าระบบของพวกเขาใช้ได้และพวกเขาจะ "รู้ว่าต้องทำอะไร" ในสถานการณ์ภัยพิบัติ เขย่าให้พวกเขาขึ้นมาด้วยการทดสอบจริงหรือสองเป็นที่ดี
• กระบวนการที่ไม่ผ่านการทดสอบจะล้มลงอย่างรวดเร็วในสถานการณ์ฉุกเฉินที่เกิดขึ้นจริง โดยเฉพาะอย่างยิ่งกระบวนการเพิ่มความซับซ้อนมุ่งเน้นไปที่การแจ้งให้ผู้บริหารระดับสูงทราบด้วยวิธีการที่งดงาม กระบวนการที่มีน้ำหนักเบามุ่งเน้นไปที่ความต้องการของเจ้าหน้าที่ปฏิบัติงานและเจ้าหน้าที่เผชิญเหตุอื่น ๆ แหล่งข้อมูลกลางเกี่ยวกับเหตุฉุกเฉินที่เกิดขึ้นได้การถ่ายโอนความรับผิดชอบอย่างชัดเจนและขั้นตอนการตอบสนองฉุกเฉิน 'ทุกวัน' จะดีที่สุด

ฉันเดาว่าสิ่งที่ฉันได้รับคือคุณไม่ควรทำทุกอย่างเกี่ยวกับกระบวนการวางแผน DR ของคุณในทางทฤษฎี ผลักดันให้ได้รับอนุญาตเพื่อทำลายสิ่งต่าง ๆ และทำให้ได้รับข้อมูลที่ยากต่อการเตรียมพร้อมขององค์กร แน่นอนว่าจะต้องได้รับการสนับสนุนอย่างจริงจังจากฝ่ายบริหาร แต่ก็สามารถมุ่งเน้นไปที่ธุรกิจที่จะใช้เวลาสองสามวันในการฝึกซ้อมที่เลวร้ายที่สุด

ตาแดง

มีหลายมาตรฐานจากBritish Standards Institute (BSi) ที่มุ่งเน้นการจัดการต่อเนื่องและการกู้คืนระบบ

• BS 25999-1: 2006การจัดการความต่อเนื่องทางธุรกิจส่วนที่ 1: หลักปฏิบัติ
• BS 25999-2: 2007การจัดการความต่อเนื่องทางธุรกิจ สเปค
• BS 25777: 2008 การจัดการความต่อเนื่องของเทคโนโลยีสารสนเทศและการสื่อสาร หลักปฏิบัติ

อาจดูเหมือนชัดเจน แต่เมื่อต้องการดูเอกสารประกอบนอกสถานที่ด้านบนตรวจสอบให้แน่ใจว่าคุณมีการสำรองข้อมูลนอกสถานที่ (ควรอยู่นอกภูมิภาค) นี่อาจเป็นบริการจัดเก็บข้อมูลออนไลน์หรือสถานที่สำหรับเทป

ฉันพูดอย่างเด่นชัดออกนอกภูมิภาคเพราะฉันมาจากพื้นที่ที่เราไม่มีภัยพิบัติทางธรรมชาติหลายปี แต่ถ้า / เมื่อเรามีหนึ่งมันอยู่ในระดับภูมิภาคที่มีการทำลายล้างสูง (แผ่นดินไหวภูเขาไฟ) เป็นเรื่องดีที่คุณมีข้อมูลสำรองไว้ในตู้นิรภัยที่ธนาคารจนกว่าธนาคารของคุณจะอยู่ภายใต้แมกมาของเหลวร้อน (/ Dr. Evil Voice)

สิ่งที่ฉันได้อ่านมาคือเอเจนซี่ที่แชร์ค่าใช้จ่ายในการบำรุงรักษาไซต์ที่มีชื่อเสียงสำหรับเมื่อ บริษัท ใหญ่ ๆ เข้าชม พวกเขาออกกฎหมายแผนสำหรับการคืนค่าภารกิจของทั้งสอง บริษัท ที่มีความสำคัญต่อไซต์ยอดนิยมโดยใช้การจำลองเสมือนและจากนั้นแบ่งปันพนักงานในระดับที่ทำให้แน่ใจได้ว่าไฟทั้งหมดกะพริบ แค่ความคิด

สำหรับหนังสือมีการวางแผนการกู้คืนความเสียหายโดย Jon William Toigo ตอนนี้อยู่ในรุ่นที่ 3 พร้อมblook รุ่นที่ 4 (บล็อก + หนังสือ) บนขอบฟ้า

ลอร่า

นี่คือลิงค์จาก SQLServerPedia ที่ให้พื้นฐานของ DR

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

อ่านเพิ่มเติมเกี่ยวกับ "ความต่อเนื่องทางธุรกิจ"