Rollback Plan สำคัญอย่างไร?
เมื่อ IT Change ล้มเหลวต้องทำอย่างไร

เย็นวันศุกร์ เวลา 18.00 น. ทีม IT ของบริษัทขนาดกลางแห่งหนึ่งตัดสินใจ patch ระบบ ERP หลักขององค์กร เหตุผลที่เลือกวันศุกร์เพราะคิดว่าจะกระทบผู้ใช้น้อยที่สุด แต่ 20 นาทีหลัง deploy เสร็จ โทรศัพท์ก็เริ่มดัง — ระบบล็อกอินไม่ได้ ฐานข้อมูลค้าง และรายงานที่ต้องส่งลูกค้าตอนเช้าวันจันทร์กำลังจะหาย ทีมงานมึนงงอยู่นานกว่า 3 ชั่วโมงเพราะไม่มีแผนสำรอง ไม่มี backup point ที่ชัดเจน และไม่มีใครรู้ว่าควรทำขั้นตอนไหนก่อน

เหตุการณ์แบบนี้เกิดขึ้นในองค์กรไทยบ่อยกว่าที่หลายคนคิด และสาเหตุหลักไม่ใช่ความสามารถของทีม IT แต่เป็น การขาด Rollback Plan ที่ดี

Rollback Plan คืออะไร?

Rollback Plan คือแผนงานที่กำหนดไว้ล่วงหน้าว่า หากการเปลี่ยนแปลงระบบ (IT Change) เกิดปัญหาหรือไม่เป็นไปตามที่คาดหวัง ทีมจะดำเนินการอย่างไรเพื่อนำระบบกลับสู่สภาพเดิมก่อน deploy ได้เร็วที่สุด โดยสูญเสีย downtime และข้อมูลให้น้อยที่สุด

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

องค์ประกอบของ Rollback Plan ที่ดี

Rollback Plan ที่มีประสิทธิภาพควรประกอบด้วยองค์ประกอบสำคัญดังนี้:

• Rollback Trigger Criteria — เงื่อนไขที่ชัดเจนว่าเมื่อใดควรตัดสินใจ rollback เช่น "ถ้าระบบไม่กลับมาทำงานภายใน 30 นาทีหลัง deploy" หรือ "ถ้า error rate เกิน 5%"
• Checkpoint และ Snapshot — backup หรือ snapshot ของระบบที่ถ่ายไว้ก่อน deploy โดยระบุ version และเวลาไว้ชัดเจน
• ขั้นตอน Rollback แบบ Step-by-Step — คำสั่งหรือขั้นตอนที่ทีมต้องทำตามลำดับ ไม่ควรต้องมานึกเองตอนเกิดปัญหา
• ผู้รับผิดชอบแต่ละขั้นตอน — กำหนดไว้ชัดว่าใครทำอะไร ใครเป็น decision maker ว่าจะ rollback หรือไม่
• Timeline เป้าหมาย (RTO) — Recovery Time Objective หรือเวลาสูงสุดที่ยอมรับได้ในการนำระบบกลับมา เช่น ภายใน 1 ชั่วโมง
• แผนการแจ้ง Stakeholders — ใครต้องได้รับแจ้งเมื่อมีปัญหา ผ่านช่องทางใด และข้อความต้องบอกว่าอะไร
• Test Environment ยืนยันแล้ว — ระบุว่าได้ทดสอบขั้นตอน rollback ใน staging ก่อนหรือไม่

Rollback vs Restore vs Fix-Forward ต่างกันอย่างไร?

หลายองค์กรสับสนระหว่างสามแนวทางนี้ ซึ่งมีความแตกต่างที่สำคัญ:

• Rollback — นำระบบกลับไปเป็น version ก่อนหน้าอย่างมีแผน เหมาะกับกรณีที่ change ใหม่ทำให้ระบบพัง และ version เดิมยังทำงานได้ดี
• Restore — กู้คืนข้อมูลจาก backup เน้นที่ข้อมูล ไม่ใช่ software version ใช้เมื่อข้อมูลสูญหายหรือเสียหาย
• Fix-Forward — เดินหน้าแก้ปัญหาใน version ใหม่แทนที่จะถอยกลับ เหมาะกับกรณีที่ rollback ยากหรือ dependency ข้างหน้าซับซ้อนจนถอยไม่ได้แล้ว

การเลือกแนวทางที่เหมาะสมขึ้นอยู่กับประเภทของ change ความเสี่ยง และสภาวะของระบบในขณะนั้น ซึ่งควรวางแผนล่วงหน้าไว้ทั้งสามแนวทางใน Change Request

ขั้นตอนเขียน Rollback Plan ก่อน Deploy จริง

1. ระบุ scope ของ change ให้ชัด — component ใดบ้างที่ได้รับผลกระทบ database, application server, network configuration หรือ third-party integration
2. ถ่าย snapshot หรือ backup ก่อน deploy ทุกครั้ง — ระบุ path, timestamp และวิธี verify ว่า backup นั้นใช้ได้จริง
3. ทดสอบขั้นตอน rollback ใน staging ก่อน — อย่าสมมติว่า rollback จะทำงานได้เองโดยไม่เคยลองทำ
4. กำหนด Rollback Trigger ล่วงหน้า — ตั้งเกณฑ์ตัวเลขชัดเจน เช่น error rate, response time หรือ business metric ที่ต้องดูหลัง deploy
5. เขียนคำสั่ง rollback ทีละบรรทัด — ถ้าเป็น CLI command ให้เขียนออกมาเลย ถ้าเป็นการกดปุ่มใน dashboard ให้ระบุ URL และ path ที่ต้องไป
6. กำหนด Go/No-Go decision time — เช่น "ถ้าภายใน 45 นาทีหลัง deploy ระบบยังไม่ปกติ ให้ initiate rollback ทันที"
7. เตรียม communication template ไว้ล่วงหน้า — ข้อความแจ้ง user, management และ vendor ที่กรอกแค่เวลาและรายละเอียดก็ส่งได้เลย

Emergency Change vs Normal Change: Rollback Plan ต่างกันอย่างไร?

สำหรับ Normal Change มีเวลาเพียงพอในการวาง Rollback Plan อย่างละเอียด ทดสอบ staging และนำเสนอต่อ Change Advisory Board (CAB) ก่อนอนุมัติ

สำหรับ Emergency Change แม้จะเร่งรีบ แต่ยังควรมี Rollback Plan ขั้นต่ำ ได้แก่ snapshot ก่อน deploy และ "undo command" ที่พร้อมใช้งานทันที หลาย ITIL framework แนะนำว่าถ้าไม่มี rollback path เลย ให้ถือว่า change นั้นยังไม่พร้อม deploy

วิธีบันทึก Rollback Plan ใน Change Request

Change Request (RFC) ที่ดีควรมี section "Rollback Plan" ที่ระบุข้อมูลต่อไปนี้เสมอ:

• เงื่อนไขที่จะ trigger rollback (เชิงตัวเลขหรือ observable criteria)
• ขั้นตอน rollback ทีละ step พร้อมผู้รับผิดชอบ
• เวลาเป้าหมาย (RTO) ที่ระบบต้องกลับมา
• ยืนยันว่า backup/snapshot ทำไว้เมื่อใด และอยู่ที่ไหน
• ชื่อผู้มีอำนาจตัดสินใจ rollback (Decision Authority)

การเก็บข้อมูลเหล่านี้ไว้ในระบบ Change Management ช่วยให้ทีมทุกคนเห็นข้อมูลเดียวกัน และสามารถ audit ย้อนหลังได้ว่า change ใดที่ต้อง rollback บ้าง เพื่อนำมาปรับปรุงกระบวนการในอนาคต

สรุป: Rollback Plan คือ Safety Net ที่ทุก IT Team ต้องมี

ไม่มี IT Change ใดที่รับประกันได้ 100% ว่าจะไม่มีปัญหา สิ่งที่แยก IT Team มืออาชีพออกจาก IT Team ที่ "โชคดี" คือ การเตรียมพร้อมรับมือเมื่อเกิดปัญหา ไม่ใช่การหวังว่าจะไม่เกิด

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

องค์กรที่ฝัง Rollback Plan ไว้เป็นส่วนหนึ่งของ Change Request ทุกใบจะมี downtime สั้นกว่า ความเสียหายน้อยกว่า และสามารถสร้างความเชื่อมั่นให้กับ stakeholders ได้มากกว่าในระยะยาว — เริ่มทำตั้งแต่วันนี้ก่อนที่จะมีวันศุกร์ที่ไม่มีแผนสำรองอีกครั้ง