คุณดำเนินการ blameless post-mortem หลังเกิดเหตุการณ์อย่างไร?

Question

Accepted Answer

**blameless post-mortem** มองเหตุการณ์ว่าเป็นความล้มเหลวของ *ระบบและเงื่อนไข* ไม่ใช่ของคน คำถามไม่ใช่ "ใครทำพัง" แต่เป็น "ระบบของเรายอมให้คนที่มีเหตุผลคนหนึ่งก่อเรื่องนี้ได้อย่างไร และเราจะทำให้มันเป็นไปไม่ได้อีกในครั้งหน้าได้อย่างไร"

## กระบวนการ

1. **สร้าง timeline** เรียบเรียงเหตุการณ์ขึ้นมาใหม่นาทีต่อนาที ตั้งแต่การตรวจพบ, การ escalate, การบรรเทา, ไปจนถึงการแก้ไข ยึดข้อเท็จจริงไว้
2. **หาปัจจัยที่ส่งผล** เหตุการณ์ส่วนใหญ่มีหลายปัจจัย ใช้เทคนิคอย่าง **5 Whys** เพื่อข้ามผ่านอาการที่ผิวเผินไปสู่ **root cause** เช่น alert ที่ขาดหาย, deploy ที่เปราะบาง หรือ runbook ที่ไม่ชัดเจน
3. **ผลิต action items** แต่ละข้อต้อง **เป็นรูปธรรม มีเจ้าของ และมีกำหนดวันส่ง** "ระวังให้มากขึ้น" ไม่ใช่ action item ส่วน "เพิ่ม pre-deploy migration check" คือ action item
4. **เผยแพร่ในวงกว้าง** เผยแพร่บทสรุปเพื่อให้ทั้งองค์กรได้เรียนรู้ ไม่ใช่แค่คนที่อยู่ในห้อง

## blameless ในทางปฏิบัติ

- อธิบาย **ว่าอะไร** เกิดขึ้น และ **ทำไมมันถึงสมเหตุสมผลในตอนนั้น** ไม่ใช่ **ใคร** ผิด
- สันนิษฐานว่าทุกคนทำอย่างมีเหตุผลด้วยข้อมูลที่พวกเขามี
- หากการกระทำของมนุษย์เพียงคนเดียวสามารถทำให้ production ล่มได้ นั่นคือ **ช่องโหว่ของระบบ** ไม่ใช่ความผิดส่วนบุคคล

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

วินาทีที่คนกลัวจะถูกตำหนิ พวกเขาจะปิดบังรายละเอียด, ลดความสำคัญของบทบาทตัวเอง และต้นเหตุที่แท้จริงก็ยังถูกฝังกลบ **psychological safety ขับเคลื่อนความซื่อสัตย์** และความซื่อสัตย์คือสิ่งเดียวที่ผลิตการแก้ไขที่อยู่ทนจริงๆ

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

เหตุการณ์คือค่าเล่าเรียนราคาแพง — blameless post-mortem คือวิธีที่คุณได้รับบทเรียนนั้นจริงๆ หากทำได้ดี outage เดิมจะไม่เกิดซ้ำ ระบบจะยืดหยุ่นขึ้นในทุกความล้มเหลว และทีมจะเชื่อมั่นว่าการยอมรับความผิดพลาดทำให้สิ่งต่างๆ ดีขึ้น ไม่ใช่แย่ลง