แม้ในช่วงที่เกิดภัยพิบัติก็ยังมีเวลาสำหรับดื่มชาอยู่เสมอ
DRP (แผนฟื้นฟูภัยพิบัติ) เป็นสิ่งที่ไม่จำเป็นเลย แต่ถ้าจู่ๆ บีเว่อร์อพยพในช่วงฤดูผสมพันธุ์แทะผ่านใยแก้วนำแสงกระดูกสันหลังหรือผู้ดูแลระบบรุ่นเยาว์ทิ้งฐานการผลิตลง คุณจะต้องแน่ใจว่าคุณจะมีแผนไว้ล่วงหน้าว่าจะทำอย่างไรกับความอับอายทั้งหมดนี้
ในขณะที่ลูกค้าที่ตื่นตระหนกเริ่มตัดสายโทรศัพท์สนับสนุนทางเทคนิค รุ่นน้องกำลังมองหาไซยาไนด์ คุณจึงเปิดซองจดหมายสีแดงอย่างชาญฉลาดและเริ่มจัดทุกอย่างให้เป็นระเบียบ
ในโพสต์นี้ ฉันต้องการแบ่งปันคำแนะนำเกี่ยวกับวิธีการเขียน DRP และสิ่งที่ควรมี เราจะดูสิ่งต่อไปนี้ด้วย:
- มาเรียนรู้ที่จะคิดแบบคนร้ายกันเถอะ
- เรามาดูประโยชน์ของชาสักแก้วในช่วงวันสิ้นโลกกันดีกว่า
- ลองคิดถึงโครงสร้าง DRP ที่สะดวกสบายกัน
- มาดูวิธีทดสอบกัน
บริษัทใดบ้างที่อาจเป็นประโยชน์สำหรับ?
เป็นเรื่องยากมากที่จะขีดเส้นแบ่งเมื่อแผนกไอทีเริ่มต้องการสิ่งเหล่านี้ ฉันจะบอกว่าคุณต้องการ DRP อย่างแน่นอนหาก:
- การหยุดเซิร์ฟเวอร์ แอปพลิเคชัน หรือการสูญเสียฐานข้อมูลบางส่วนจะนำไปสู่การสูญเสียที่สำคัญต่อธุรกิจโดยรวม
- คุณมีแผนกไอทีที่เต็มเปี่ยม ในแง่ของแผนกในรูปแบบของหน่วยงานที่เต็มเปี่ยมของบริษัทด้วยงบประมาณของตัวเอง ไม่ใช่แค่พนักงานที่เหนื่อยล้าเพียงไม่กี่คนที่วางเครือข่าย ทำความสะอาดไวรัส และเติมเครื่องพิมพ์
- คุณมีงบประมาณตามจริงสำหรับความซ้ำซ้อนบางส่วนเป็นอย่างน้อยในกรณีฉุกเฉิน
เมื่อแผนกไอทีร้องขอ HDD อย่างน้อยสองสามตัวในเซิร์ฟเวอร์เก่าเพื่อสำรองข้อมูลเป็นเวลาหลายเดือน คุณไม่น่าจะจัดการย้ายบริการที่ล้มเหลวทั้งหมดเพื่อสำรองความจุได้ แม้ว่าเอกสารที่นี่จะไม่ฟุ่มเฟือย
เอกสารเป็นสิ่งสำคัญ
เริ่มต้นด้วยเอกสาร สมมติว่าบริการของคุณทำงานบนสคริปต์ Perl ที่ผู้ดูแลระบบเขียนเมื่อสามรุ่นก่อน แต่ไม่มีใครรู้ว่ามันทำงานอย่างไร หนี้ทางเทคนิคที่สะสมและการขาดเอกสารไม่เพียงแต่จะทำให้คุณบาดเจ็บที่หัวเข่าเท่านั้น แต่ยังรวมถึงแขนขาอื่นๆ ด้วย มันเป็นเรื่องของเวลามากกว่า
เมื่อคุณมีคำอธิบายที่ดีเกี่ยวกับส่วนประกอบการบริการแล้ว ให้ค้นหาสถิติอุบัติเหตุ พวกเขาจะเป็นเรื่องปกติอย่างสมบูรณ์อย่างแน่นอน ตัวอย่างเช่น ดิสก์ของคุณเต็มเป็นครั้งคราว ซึ่งทำให้โหนดล้มเหลวจนกว่าจะมีการล้างข้อมูลด้วยตนเอง หรือบริการลูกค้าไม่สามารถใช้งานได้เนื่องจากมีคนลืมต่ออายุใบรับรองอีกครั้งและ Let's Encrypt ไม่สามารถหรือไม่เต็มใจที่จะกำหนดค่า
ความคิดเหมือนผู้ก่อวินาศกรรม
ส่วนที่ยากที่สุดคือการคาดการณ์อุบัติเหตุที่ไม่เคยเกิดขึ้นมาก่อน แต่อาจทำให้บริการของคุณเสียหายโดยสิ้นเชิง ที่นี่ฉันและเพื่อนร่วมงานมักจะเล่นเป็นตัวร้าย ดื่มกาแฟและหาอะไรอร่อยๆ สักแก้วแล้วขังตัวเองอยู่ในห้องประชุม เพียงตรวจสอบให้แน่ใจว่าในการเจรจาเดียวกันนั้น คุณล็อกวิศวกรที่พัฒนาบริการเป้าหมายหรือทำงานร่วมกับบริการนั้นเป็นประจำ จากนั้นทั้งบนกระดานหรือบนกระดาษคุณเริ่มวาดภาพความน่าสะพรึงกลัวที่อาจเกิดขึ้นกับบริการของคุณ ไม่จำเป็นต้องลงรายละเอียดถึงพนักงานทำความสะอาดคนใดคนหนึ่งและดึงสายเคเบิลออก เพียงพิจารณาสถานการณ์ "การละเมิดความสมบูรณ์ของเครือข่ายท้องถิ่น" ก็เพียงพอแล้ว
โดยทั่วไปแล้ว สถานการณ์ฉุกเฉินโดยทั่วไปส่วนใหญ่จะแบ่งออกเป็นประเภทต่อไปนี้:
- เครือข่ายล่ม
- บริการระบบปฏิบัติการล้มเหลว
- ความล้มเหลวของแอปพลิเคชัน
- ความล้มเหลวของเหล็ก
- การจำลองเสมือนล้มเหลว
เพียงอ่านแต่ละประเภทและดูว่าบริการของคุณมีอะไรบ้าง ตัวอย่างเช่น Nginx daemon อาจล้มและไม่เพิ่มขึ้น - นี่หมายถึงความล้มเหลวในส่วนของระบบปฏิบัติการ สถานการณ์ที่เกิดขึ้นได้ยากที่ทำให้แอปพลิเคชันเว็บของคุณล้มเหลวคือความล้มเหลวของซอฟต์แวร์ ในขณะที่ดำเนินการผ่านขั้นตอนนี้ การวินิจฉัยปัญหาเป็นสิ่งสำคัญ วิธีแยกแยะอินเทอร์เฟซที่ค้างบนการจำลองเสมือนจากไดรฟ์ cis ที่เสียหายและเครือข่ายล้มเหลว เป็นต้น นี่เป็นสิ่งสำคัญที่จะต้องค้นหาผู้รับผิดชอบอย่างรวดเร็วและเริ่มดึงหางจนกว่าอุบัติเหตุจะคลี่คลาย
หลังจากจดบันทึกปัญหาทั่วไปแล้ว เราจะเทกาแฟเพิ่มและเริ่มพิจารณาสถานการณ์ที่แปลกประหลาดที่สุด เมื่อพารามิเตอร์บางตัวเริ่มไปไกลกว่าปกติ ตัวอย่างเช่น:
- จะเกิดอะไรขึ้นหากเวลาบนโหนดที่ใช้งานอยู่ย้อนกลับไปหนึ่งนาทีเมื่อเทียบกับเวลาอื่นๆ ในคลัสเตอร์
- จะเกิดอะไรขึ้นถ้าเวลาผ่านไป 10 ปีจะเป็นอย่างไร?
- จะเกิดอะไรขึ้นหากโหนดคลัสเตอร์สูญเสียเครือข่ายกะทันหันระหว่างการซิงโครไนซ์
- จะเกิดอะไรขึ้นหากโหนดสองโหนดไม่มีความเป็นผู้นำร่วมกันเนื่องจากการแยกกันชั่วคราวบนเครือข่าย
ในขั้นตอนนี้ วิธีย้อนกลับมีประโยชน์มาก คุณรับสมาชิกที่ดื้อรั้นที่สุดในทีมด้วยจินตนาการที่ไม่ดีและมอบหมายให้เขาจัดการก่อวินาศกรรมในเวลาที่สั้นที่สุดเท่าที่จะเป็นไปได้ซึ่งจะทำให้บริการล่มสลาย ถ้าวินิจฉัยยากยิ่งดี คุณจะไม่เชื่อหรอกว่าวิศวกรจะมีไอเดียแปลกๆ และเจ๋งๆ อะไรบ้าง หากคุณให้ไอเดียแก่พวกเขาที่จะทำลายบางสิ่ง และถ้าคุณสัญญากับพวกเขาว่าจะมีม้านั่งทดสอบสำหรับเรื่องนี้ ก็ไม่เป็นไร
DRP ของคุณนี้คืออะไร!
คุณได้กำหนดรูปแบบภัยคุกคามของคุณแล้ว นอกจากนี้ พวกเขายังคำนึงถึงผู้อยู่อาศัยในท้องถิ่นที่ตัดสายเคเบิลใยแก้วนำแสงเพื่อค้นหาทองแดง และเรดาร์ของทหารที่ส่งสัญญาณวิทยุตกทุกวันศุกร์เวลา 16:46 น. ตอนนี้เราต้องเข้าใจว่าจะทำอย่างไรกับทั้งหมดนี้
งานของคุณคือเขียนซองจดหมายสีแดงซึ่งจะเปิดในกรณีฉุกเฉิน คาดหวังได้ทันทีว่าเมื่อ (ไม่ใช่ถ้า!) ทุกอย่างจบลง จะมีเพียงเด็กฝึกงานที่ไม่มีประสบการณ์มากที่สุดเท่านั้นที่จะอยู่ใกล้ๆ มือของเขาจะสั่นอย่างรุนแรงจากความสยองขวัญของสิ่งที่เกิดขึ้น ดูว่าสัญญาณฉุกเฉินถูกนำมาใช้ในสำนักงานทางการแพทย์อย่างไร เช่น จะต้องทำอย่างไรในกรณีที่เกิดอาการช็อกจากภูมิแพ้ (Anaphylactic Shock) เจ้าหน้าที่ทางการแพทย์รู้ขั้นตอนทั้งหมดด้วยใจ แต่เมื่อคนใกล้ตัวเริ่มตาย บ่อยครั้งทุกคนก็กำทุกอย่างที่ขวางหน้าไว้อย่างช่วยไม่ได้ ในการดำเนินการนี้ มีคำแนะนำที่ชัดเจนบนผนังพร้อมรายการต่างๆ เช่น "เปิดบรรจุภัณฑ์ของสิ่งดังกล่าว" และ "ให้ยาหลายหน่วยทางหลอดเลือดดำ"
ฉุกเฉินก็คิดยาก! ควรมีคำแนะนำง่ายๆ สำหรับการแยกวิเคราะห์ไขสันหลัง
DRP ที่ดีประกอบด้วยบล็อกง่ายๆ หลายบล็อก:
- ใครต้องแจ้งเกี่ยวกับการเริ่มเกิดอุบัติเหตุ นี่เป็นสิ่งสำคัญเพื่อให้กระบวนการกำจัดเป็นแบบขนานให้มากที่สุด
- วิธีการวินิจฉัยอย่างถูกต้อง - ติดตามดูในชื่อบริการสถานะ systemctl และอื่น ๆ
- คุณสามารถใช้เวลาในแต่ละด่านได้นานแค่ไหน? หากคุณไม่มีเวลาแก้ไขด้วยตนเองภายในเวลา SLA เครื่องเสมือนจะถูกปิดและย้อนกลับจากการสำรองข้อมูลของเมื่อวาน
- จะแน่ใจได้อย่างไรว่าอุบัติเหตุสิ้นสุดลง
โปรดจำไว้ว่า DRP เริ่มต้นเมื่อบริการล้มเหลวโดยสิ้นเชิงและสิ้นสุดเมื่อบริการได้รับการกู้คืน แม้ว่าประสิทธิภาพจะลดลงก็ตาม การสูญเสียการจองไม่ควรกระตุ้นให้เกิด DRP คุณยังสามารถเขียนชาหนึ่งถ้วยลงใน DRP ได้ อย่างจริงจัง. ตามสถิติ อุบัติเหตุจำนวนมากเปลี่ยนจากไม่พึงประสงค์ไปสู่หายนะเนื่องจากการที่พนักงานตื่นตระหนกรีบเร่งเพื่อแก้ไขบางสิ่งบางอย่าง ฆ่าโหนดที่มีชีวิตเพียงโหนดเดียวด้วยข้อมูลหรือทำให้คลัสเตอร์สิ้นสุดลงในที่สุด ตามกฎแล้วการจิบชาสักแก้วสัก 5 นาทีจะทำให้คุณมีเวลาสงบสติอารมณ์และวิเคราะห์สิ่งที่เกิดขึ้น
อย่าสับสน DRP และพาสปอร์ตระบบ! อย่าโอเวอร์โหลดด้วยข้อมูลที่ไม่จำเป็น เพียงทำให้สามารถใช้ไฮเปอร์ลิงก์ได้อย่างรวดเร็วและสะดวกเพื่อไปยังส่วนที่ต้องการของเอกสารและอ่านในรูปแบบขยายเกี่ยวกับส่วนที่จำเป็นของสถาปัตยกรรมบริการ และใน DRP เองนั้นมีเพียงคำแนะนำโดยตรงเกี่ยวกับตำแหน่งและวิธีเชื่อมต่อกับคำสั่งเฉพาะสำหรับการคัดลอกและวาง
วิธีการทดสอบที่ถูกต้อง
ตรวจสอบให้แน่ใจว่าพนักงานที่รับผิดชอบสามารถดำเนินการทุกรายการได้ ในช่วงเวลาที่สำคัญที่สุดอาจกลายเป็นว่าวิศวกรไม่มีสิทธิ์ในการเข้าถึงระบบที่ต้องการ ไม่มีรหัสผ่านสำหรับบัญชีที่ต้องการ หรือเขาไม่รู้ว่า "เชื่อมต่อกับคอนโซลการจัดการบริการผ่านพร็อกซีที่ สำนักงานใหญ่” หมายความว่า แต่ละจุดควรจะง่ายมาก
ผิด — “ไปที่การจำลองเสมือนและรีบูตโหนดที่ไม่ทำงาน”
ได้อย่างถูกต้อง - “เชื่อมต่อผ่านอินเทอร์เฟซเว็บไปยัง virt.example.com ในส่วนโหนด ให้รีบูตโหนดที่ทำให้เกิดข้อผิดพลาด”
หลีกเลี่ยงความคลุมเครือ จำเด็กฝึกงานที่หวาดกลัว
อย่าลืมทดสอบ DRP นี่ไม่ใช่แค่แผนการแสดงเท่านั้น แต่ยังเป็นสิ่งที่จะช่วยให้คุณและลูกค้าของคุณออกจากสถานการณ์วิกฤติได้อย่างรวดเร็ว ทางที่ดีควรทำหลายครั้ง:
- ผู้เชี่ยวชาญหนึ่งคนและผู้เข้ารับการฝึกอบรมหลายคนทำงานบนม้านั่งทดสอบที่จำลองการบริการจริงให้ได้มากที่สุด ผู้เชี่ยวชาญหยุดบริการด้วยวิธีต่างๆ และช่วยให้ผู้เข้ารับการฝึกอบรมสามารถกู้คืนบริการได้ตาม DRP ปัญหา ความคลุมเครือของเอกสาร และข้อผิดพลาดทั้งหมดจะถูกบันทึกไว้ หลังจากที่ผู้เข้ารับการฝึกอบรมได้รับการฝึกอบรมแล้ว DRP จะถูกขยายและทำให้ง่ายขึ้นในพื้นที่ที่ไม่ชัดเจน
- การทดสอบบนบริการจริง ในความเป็นจริง คุณไม่สามารถสร้างสำเนาบริการจริงที่สมบูรณ์แบบได้ ดังนั้น ปีละสองครั้งจึงจำเป็นต้องปิดเซิร์ฟเวอร์บางส่วนเป็นประจำ ตัดการเชื่อมต่อ และก่อให้เกิดภัยพิบัติอื่นๆ จากรายการภัยคุกคาม เพื่อประเมินลำดับการกู้คืน ความล้มเหลวที่วางแผนไว้เป็นเวลา 10 นาทีในตอนกลางคืนยังดีกว่าความล้มเหลวกะทันหันเป็นเวลาหลายชั่วโมงในช่วงที่มีการใช้งานสูงสุดโดยที่ข้อมูลสูญหาย
- การแก้ไขปัญหาจริง ใช่ นี่เป็นส่วนหนึ่งของการทดสอบด้วย หากเกิดอุบัติเหตุที่ไม่อยู่ในรายการภัยคุกคาม จำเป็นต้องเสริมและสรุป DRP ตามผลการสอบสวน
ประเด็นสำคัญ
- หากเรื่องเลวร้ายสามารถเกิดขึ้นได้ มันจะไม่เพียงเกิดขึ้นเท่านั้น แต่ยังเกิดขึ้นในสถานการณ์ที่เลวร้ายที่สุดเท่าที่จะเป็นไปได้
- ตรวจสอบให้แน่ใจว่าคุณมีทรัพยากรสำหรับการถ่ายโอนภาระงานฉุกเฉิน
- ตรวจสอบให้แน่ใจว่าคุณมีข้อมูลสำรอง ซึ่งจะถูกสร้างขึ้นโดยอัตโนมัติและตรวจสอบความสอดคล้องอย่างสม่ำเสมอ
- คิดให้รอบคอบถึงสถานการณ์ภัยคุกคามทั่วไป
- ให้โอกาสวิศวกรในการเสนอทางเลือกที่ไม่ได้มาตรฐานในการให้บริการ
- DRP ควรเป็นคำสั่งที่เรียบง่ายและตรงไปตรงมา การวินิจฉัยที่ซับซ้อนทั้งหมดจะดำเนินการหลังจากกู้คืนบริการของลูกค้าแล้วเท่านั้น แม้ว่าจะมีความจุสำรองก็ตาม
- ระบุหมายเลขโทรศัพท์หลักและผู้ติดต่อใน DRP
- ทดสอบความเข้าใจของพนักงานเกี่ยวกับ DRP อย่างสม่ำเสมอ
- จัดเตรียมแผนอุบัติเหตุที่ไซต์การผลิต สแตนด์ไม่สามารถแทนที่ทุกสิ่งได้
ที่มา: will.com