บล็อก

13 คะแนนที่ต้องรวมไว้ในแผนฟื้นฟูภัยพิบัติของคุณ

แผนกู้คืนระบบ (DRP) is a document you need to keep handy to handle unexpected incidents that could shut down your company’s IT systems and hinder its overall operation.
A DRP aims to get your business up and running as quickly as possible during a disaster or data breach. With an การกู้คืนระบบที่มีประสิทธิภาพ วางแผนมีโอกาสน้อยที่คุณจะสูญเสียผลกำไรเป็นเวลานานเกินไป นอกจากนี้ควรมีการสำรองข้อมูลไว้เพื่อป้องกันไม่ให้ข้อมูลที่ละเอียดอ่อน (หมายเลขประกันสังคมหรือข้อมูลบัตรเครดิต) ถูกบุกรุก

ธุรกิจของคุณมีแผนฟื้นฟูภัยพิบัติหรือไม่?

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

Disasters come uninvited with loads of complex challenges, which organizations might take months or years to overcome. Cyber attacks, tornadoes, terrorist attacks, hurricanes, and floods are some of the disasters that can cause data breaches. A disaster plan is a long-term assurance of business operability as it is designed in such a way that it enables businesses to reduce damages of unpredicted outages.

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

1. วิเคราะห์ภัยคุกคามที่อาจเกิดขึ้นและปฏิกิริยาที่เป็นไปได้

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

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

วิธีที่ดีที่สุดคือการอัปเดตตัวเองเกี่ยวกับแผนการที่แฮกเกอร์ใช้ คุณสามารถหลีกเลี่ยงการติดเชื้อฟิชชิงและมัลแวร์ส่วนใหญ่ได้

2. แก้ไขวัตถุประสงค์การกู้คืนจากภัยพิบัติ

การกู้คืนจากภัยพิบัติช่วยให้คุณสามารถดำเนินธุรกิจได้ตามปกติอย่างต่อเนื่องดังนั้นคุณต้องแก้ไขบริการไอทีที่สำคัญที่สุดในการบริหารองค์กรของคุณ นอกจากนี้ Recovery Time Objective (RTO) และ Recovery Point Objective (RPO) ที่จำเป็นสำหรับบริการ / เครื่องเหล่านี้ แต่คุณตระหนักถึง RTO และ RPO หรือไม่?

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

RPO: ช่วงเวลาที่สามารถยอมรับข้อมูลได้ หลังจากเกิดภัยพิบัติหากธุรกิจของคุณสามารถอยู่รอดจากการสูญหายของข้อมูลได้เพียงสี่ชั่วโมงหลังจากดำเนินธุรกิจเต็มวันสิ่งนี้อาจนำไปสู่การสูญเสียข้อมูลสำคัญอย่างหายนะดังนั้น RPO ของคุณจะใช้เวลาสี่ชั่วโมง

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

3. รับรู้ผู้มีส่วนได้ส่วนเสียในแผนฟื้นฟูภัยพิบัติของคุณ

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

4. สร้างไซต์กู้คืนระบบ

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

5. รวบรวมเอกสารโครงสร้างพื้นฐานทั้งหมด

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

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

6. เชอร์รี่เลือกเทคโนโลยีที่แม่นยำ

Disaster Recovery as a Service (DRaaS) and on-premise disaster recovery is not just the feasible solutions available for business continuity. The next option is to make use of cloud-based disaster recovery in order to spin up your disaster recovery site on a public cloud-like Microsoft AzureAWS และ Google Cloud in minutes using an automated disaster recovery solution.

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

7. เปิดช่องทางการสื่อสาร

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

8. สรุปขั้นตอนการตอบสนองต่อเหตุการณ์

หากคุณมีแผนกู้คืนระบบจำเป็นต้องมี“ ขั้นตอนการรับมือกับเหตุการณ์” ในที่นี้ บริษัท ต่างๆจะกำหนดรายละเอียดว่าเหตุการณ์ใดบ้างที่ต้องประกาศว่าเป็นภัยพิบัติ ตัวอย่างเช่นหากระบบของคุณล่มคุณจะถือว่านั่นเป็นหายนะหรือไม่? นอกจากนี้แผนยังควรระบุวิธีการตรวจสอบความเสียหายและวิธีการรายงาน - โดยระบบตรวจสอบอัตโนมัติได้รับการเรียกร้องจากทีมวิศวกรรมความน่าเชื่อถือของไซต์ (SRE) หรือรายงานโดยลูกค้า?

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

9. สรุปขั้นตอนการตอบสนองการดำเนินการ

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

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

10. เตรียมพร้อมสำหรับความล้มเหลวในโครงสร้างพื้นฐานหลัก

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

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

11. รายงานเหตุการณ์ต่อผู้มีส่วนได้ส่วนเสีย

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

12. ทำการทดสอบอย่างละเอียด

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

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

13. อัปเดตแผนฟื้นฟูภัยพิบัติของคุณ

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

การออกจากระบบ:

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

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

ทิ้งคำตอบไว้

thThai