คุณใช้เกณฑ์อะไรในการตัดสินใจระหว่าง rollback กับ hotfix?

Question

Accepted Answer

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

## เกณฑ์การตัดสินใจ

- **rollback ปลอดภัยและทำได้หรือไม่?** หากเวอร์ชันก่อนหน้ารู้ว่าดีและไม่มีอะไรย้อนกลับไม่ได้เกิดขึ้น ให้ rollback นี่คือคำตอบปกติ
- **release ที่เสียสร้าง state ที่ย้อนกลับไม่ได้หรือไม่?** **database migration** หรือข้อมูลเสียหายอาจทำให้ rollback แย่กว่าบั๊ก หากย้อนกลับอย่างปลอดภัยไม่ได้ คุณต้องแก้ไปข้างหน้า
- **เราเข้าใจการแก้หรือไม่?** rollback ไม่ต้องการการวินิจฉัย — นั่นคือพลังของมัน hotfix ที่คุณไม่เข้าใจเต็มที่อาจทำให้ incident หนักขึ้น; อย่า ship การเดาขึ้น prod ภายใต้ความกดดัน
- **เวลาถึงสถานะปลอดภัย** เลือกทางที่ถึงความเสถียรเร็วที่สุดด้วยความเสี่ยงน้อยที่สุด hotfix บรรทัดเดียวที่เข้าใจดีอาจชนะ rollback ที่ซับซ้อน; การแก้ไปข้างหน้าที่เสี่ยงไม่มีวันชนะการ revert ที่สะอาด
- **blast radius และความรุนแรง** เหตุล่มทั้งระบบเรียกร้องการกู้คืนที่เร็วที่สุด (มักเป็น rollback); การเสื่อมเล็กน้อยอาจยอมให้ hotfix อย่างระมัดระวังได้

## ตารางตัดสินใจอย่างรวดเร็ว

| สถานการณ์ | เลือก |
| --- | --- |
| เวอร์ชันก่อนหน้ารู้ว่าดี ไม่มี migration | Rollback |
| migration DB ที่ย้อนกลับไม่ได้ถูก ship | Hotfix / fix-forward |
| ไม่ทราบสาเหตุ ผลกระทบรุนแรง | Rollback (ซื้อเวลา) |
| บรรทัดเดียว เรื่องเล็ก เข้าใจดี | Hotfix |
| เส้นทาง rollback เองเสี่ยง/ไม่ได้ทดสอบ | Hotfix |

## trade-off และกับดัก

- **rollback** ปลอดภัยแต่รักษาแค่อาการ — คุณยังติดค้างการแก้จริงและ postmortem
- **hotfix** จัดการ root cause แต่ข้ามตาข่ายนิรภัยปกติ; บั๊กใน hotfix พบบ่อยเพราะมันถูกเร่งรีบ
- **เส้นทาง rollback ที่ไม่ได้ทดสอบ** เป็นกับดัก — หากไม่เคยซ้อม มันอาจล้มเหลวเมื่อคุณต้องการมากที่สุด ซ้อม rollback ก่อนที่คุณจะต้องใช้
- ระวัง **การ debug ใน production** ภายใต้ความกดดัน; หากคุณห่างจากการแก้ที่มั่นใจมากกว่าไม่กี่นาที ให้ rollback และสืบสวนอย่างใจเย็น

## ทำไมจึงสำคัญ

การตัดสินใจนี้เกิดขึ้นในช่วงเวลาที่เลวร้ายที่สุด — ระบบล่ม นาฬิกาเดิน ทุกคนจ้องมอง Tech Lead ที่มีกฎที่ชัดเจนและซ้อมมาแล้วสำหรับมันจะลด MTTR ลงอย่างมากและป้องกันความผิดพลาดคลาสสิกของการพยายามฉลาดกลาง incident ทั้งที่การ revert ที่น่าเบื่ออยู่ตรงนั้น กู้คืนก่อน ฉลาดทีหลัง

สถานการณ์	เลือก
เวอร์ชันก่อนหน้ารู้ว่าดี ไม่มี migration	Rollback
migration DB ที่ย้อนกลับไม่ได้ถูก ship	Hotfix / fix-forward
ไม่ทราบสาเหตุ ผลกระทบรุนแรง	Rollback (ซื้อเวลา)
บรรทัดเดียว เรื่องเล็ก เข้าใจดี	Hotfix
เส้นทาง rollback เองเสี่ยง/ไม่ได้ทดสอบ	Hotfix