DR Plan ที่รอดวันจริง: ใครตัดสินใจ ใครสื่อสาร ตอนระบบล่ม

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

Disaster Recovery (DR) Plan ส่วนใหญ่ตอบคำถามฝั่งเทคนิคได้ดี มันบอกว่าจะ restore ข้อมูลจากไหน ย้ายโหลดไป standby ตัวไหน และลำดับการนำระบบกลับมาเป็นอย่างไร ส่วนที่มักหายไปคือฝั่งของคน ใครประกาศว่านี่คือเหตุร้ายแรง ใครสั่ง failover และใครบอกผู้ใช้ว่าเกิดอะไรขึ้น

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

เพราะแผนที่ดีบนกระดาษ ไม่ได้แปลว่าคืนนั้นจะราบรื่น

ตัวเลขหนึ่งอธิบายว่าทำไมเราถึงเน้นเรื่องคนมากกว่าเครื่องมือ จากรายงาน Annual Outage Analysis 2025 ของ Uptime Institute ซึ่งสำรวจผู้ดำเนินงาน data center ทั่วโลก องค์กรราว 40% เคยเจอเหตุระบบล่มครั้งใหญ่ที่มีสาเหตุจาก human error ในรอบสามปี และในกลุ่มนั้น 85% มาจากการที่คนไม่ทำตามขั้นตอน หรือขั้นตอนเองมีข้อบกพร่อง (ที่มา: Uptime Institute, 2025) สัญญาณจากตัวเลขนี้ชัดเจน งานส่วนใหญ่ของ DR ที่ล้มเหลว ล้มที่ขั้นตอนและการตัดสินใจของคน ก่อนจะไปถึงเรื่องเทคโนโลยี

ใครมีสิทธิ์ประกาศว่านี่คือ disaster

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

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

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

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

มาตรฐานสากลด้าน business continuity อย่าง ISO 22301 วางกรอบเรื่องนี้ไว้ในระดับองค์กร ว่าต้องนิยามบทบาทและอำนาจตัดสินใจก่อนเกิดเหตุ (อ้างอิง: ISO 22301:2019) ฝั่งการรับมือเหตุด้านความมั่นคงปลอดภัย NIST SP 800-61 ก็ย้ำหลักเดียวกัน คือกำหนดผู้รับผิดชอบและเส้นทางการยกระดับเหตุไว้ตั้งแต่ก่อนวันจริง (อ้างอิง: NIST SP 800-61 Rev.2) กรอบทั้งสองไม่ได้บังคับรูปแบบตายตัว แต่ตรงกันในหลักการว่าการตัดสินใจต้องมีเจ้าของที่ชัดเจน

เกณฑ์ตัดสินใจต้องเป็นตัวเลข ไม่ใช่ความรู้สึก

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

เมื่อมีสองค่านี้ การตัดสินใจกลายเป็นเรื่องเทียบตัวเลข ถ้าประเมินว่าระบบหลักจะกลับมาช้ากว่ากรอบ RTO ให้เดินหน้า failover ถ้าการ failover จะทำให้ข้อมูลหายมากกว่ากรอบ RPO ต้องมีขั้นตอนรองรับส่วนที่หาย เช่น การกระทบยอดย้อนหลัง เกณฑ์เหล่านี้ควรอยู่ใน runbook ของแต่ละระบบ ไม่ใช่เก็บไว้ในหัวของคนใดคนหนึ่ง

การตั้งค่า RTO และ RPO ที่สมเหตุสมผลเป็นงานที่ทำตอนออกแบบระบบ ไม่ใช่ตอนเกิดเหตุ NIST SP 800-34 อธิบายวิธีหาค่าเหล่านี้ผ่านการทำ business impact analysis ซึ่งจัดลำดับว่าระบบไหนสำคัญแค่ไหน และยอมหยุดได้นานเท่าไร (อ้างอิง: NIST SP 800-34 Rev.1) งานนี้ทำครั้งเดียวแล้วใช้ได้ยาว และเป็นฐานให้ทุกการตัดสินใจในคืนที่เกิดเหตุ

failover หรือ รอ คือการตัดสินใจที่แพงที่สุดในคืนนั้น

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

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

ในทางปฏิบัติ ทางเลือกไม่ได้มีแค่สองขั้วเสมอ บางระบบรองรับการ failover เฉพาะบางส่วนได้ เช่น ย้ายเฉพาะการอ่านไป standby ก่อน แล้วค่อยย้ายการเขียนเมื่อมั่นใจ การมีทางเลือกกลางแบบนี้ต้องออกแบบและทดสอบไว้ล่วงหน้า เพราะไม่มีใครคิดสถาปัตยกรรมใหม่ได้ตอนระบบกำลังดับ

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

เรื่องการทดสอบ restore ให้ได้จริง และการเขียนเงื่อนไขนี้ลงใน TOR ตั้งแต่รอบจัดซื้อ เราเล่าไว้แยกอีกบทความหนึ่งเรื่อง เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้ บทความนี้จึงขอโฟกัสที่ช่วงเกิดเหตุจริงแทน

การสื่อสารตอนเกิดเหตุ ต้องตกลงกันไว้ก่อน

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

NIST SP 800-61 แนะนำให้กำหนดแนวทางการสื่อสารไว้ล่วงหน้า ว่าใครพูดกับใคร ข้อมูลระดับไหนที่แชร์ได้ และตั้งช่องทางติดต่อทั้งในและนอกเวลางานไว้ให้พร้อม ครอบคลุมผู้บริหารสารสนเทศ ทีม security และผู้รับผิดชอบ business continuity (อ้างอิง: NIST SP 800-61 Rev.2)

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

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

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

ส่งเวร on-call ตอนที่เหตุยังไม่จบ

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

Uptime Institute ระบุว่าความล้าของพนักงานเป็นหนึ่งในปัจจัยที่ทำให้ human error กลายเป็นสาเหตุของเหตุระบบล่ม (ที่มา: Uptime Institute, 2024) การยอมให้คนที่ทำงานมานานหลายชั่วโมงตัดสินใจเรื่องใหญ่ต่อไปเรื่อย ๆ คือความเสี่ยงที่มองไม่เห็นจนกว่าจะเกิดพลาด

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

หลังเหตุจบ ทำ postmortem ที่ไม่โทษคน

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

แนวปฏิบัติ blameless postmortem ที่ทีม SRE ของ Google อธิบายไว้ ตั้งอยู่บนหลักว่าเมื่อเลิกโทษตัวบุคคล คนจะกล้ารายงานสิ่งที่เกิดขึ้นจริง และองค์กรจะได้ข้อมูลที่ครบพอจะแก้ที่ระบบ (อ้างอิง: Google SRE, Postmortem Culture) เอกสารหนึ่งฉบับควรมีไทม์ไลน์ ผลกระทบต่อผู้ใช้ สาเหตุที่แท้จริง และรายการสิ่งที่ต้องแก้ โดยแต่ละข้อมีเจ้าของและกำหนดเวลา

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

จุดนี้วนกลับไปที่ตัวเลขตอนต้น เมื่อเหตุจาก human error ส่วนใหญ่มาจากการไม่ทำตามขั้นตอนหรือขั้นตอนบกพร่อง ทางแก้ที่ให้ผลจึงอยู่ที่การปรับ runbook และเกณฑ์การตัดสินใจให้คนคนต่อไปทำถูกได้ง่ายขึ้น สอดคล้องกับที่ผู้ตอบแบบสำรวจของ Uptime ราวสี่ในห้าเชื่อว่าการจัดการและกระบวนการที่ดีกว่าจะช่วยกันเหตุล่าสุดได้ (ที่มา: Uptime Institute, สำรวจปี 2023)

สรุป

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

และซ้อมมันอย่างน้อยหนึ่งครั้ง ก่อนที่จะต้องใช้จริง

หากองค์กรของคุณมี DR Plan อยู่แล้วแต่ยังไม่เคยซ้อมในมุมของคนและการตัดสินใจ และอยากให้มีคนช่วยอ่านทบทวนก่อน เรายินดีคุยด้วย ไม่มีกำหนดเวลาบังคับ และไม่ต้องรีบตัดสินใจ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างทบทวนแผนรับมือเหตุ เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน และหากคุยแล้วพบว่าแผนที่มีอยู่เพียงพอแล้ว เราจะบอกตรง ๆ