On-call, Incident & Postmortem

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

On-call — ใครรับผิดชอบตอนตี 3

On-call = การจัดเวรว่าใครเป็นคนรับ alert และแก้ปัญหาในช่วงเวลานั้น (รวมถึงนอกเวลางาน)

หลักการ on-call ที่ยั่งยืน (ไม่ทำให้คนลาออก):

• หมุนเวียนเป็นธรรม — สลับเวรกันในทีม ไม่ใช่คนเดิมตลอด
• มีคนสำรอง (secondary) — เผื่อ primary ไม่รับสาย
• Alert ต้องมีคุณภาพ — ถ้าถูกปลุกด้วย false positive บ่อยๆ = ระบบ alert คุณพัง (ย้อนกลับไปบทที่ 14!)
• วัดภาระ on-call — นับจำนวน page ต่อเวร ถ้าเยอะเกินไปต้องแก้ที่ต้นเหตุ ไม่ใช่ให้คนทน

คุณภาพของ on-call = กระจกสะท้อนคุณภาพของ monitoring ถ้าคนถูกปลุกบ่อยด้วยเรื่องไร้สาระ แปลว่า alert ตั้งไม่ดี (บทที่ 14) การลงทุนทำ alert ให้ดีคือการลงทุนในสุขภาพจิตของทีม

Severity — จัดระดับความรุนแรงของ incident

พอ alert เด้งเป็น incident จริง ต้องจัดระดับเพื่อรู้ว่าต้องระดมคนแค่ไหน:

ระดับ	ความหมาย	ตัวอย่าง	การตอบสนอง
SEV1	ระบบหลักล่ม กระทบผู้ใช้วงกว้าง	ทั้งเว็บล่ม, จ่ายเงินไม่ได้เลย	ระดมทีม ทันที ทุกเวลา
SEV2	กระทบบางส่วน/บาง feature	search ใช้ไม่ได้ แต่ซื้อได้	แก้ด่วนในเวลางาน/on-call
SEV3	ผลกระทบเล็ก มี workaround	รูปโหลดช้าบางหน้า	จัดคิวแก้ปกติ

Runbook — คู่มือ "ถ้าเจอ X ให้ทำ Y"

Runbook คือเอกสารที่บอกว่า เมื่อ alert นี้เด้ง ให้ทำอะไรทีละขั้น — เชื่อมกับ alert โดยตรง (จำ annotation runbook: ในบทที่ 14)

runbook ที่ดีมี:

## Alert: HighErrorRate

### อาการ
error rate ของ checkout เกิน 5%

### ผลกระทบ
ลูกค้าสั่งซื้อไม่สำเร็จ → กระทบรายได้โดยตรง

### วิธีตรวจสอบ (ใช้ 3 pillars!)
1. เปิด RED dashboard ของ payment → ดูว่า error เริ่มตอนไหน
2. เทียบกับเวลา deploy ล่าสุด (Events)
3. เปิด trace ที่ fail ใน Jaeger → หา span ที่ error
4. อ่าน log ของ trace_id นั้น → หา error message จริง

### วิธีแก้เบื้องต้น (mitigation)
- ถ้าเพิ่ง deploy → rollback ทันที
- ถ้า DB pool เต็ม → เพิ่ม pool size / restart
- ถ้า external API ล่ม → เปิด circuit breaker

### ถ้าแก้ไม่ได้ → escalate ไป: [ทีม/คน]

Runbook เปลี่ยนคนที่ถูกปลุกตอนตี 3 (ที่อาจไม่ได้เชี่ยวชาญ service นั้น) ให้แก้ปัญหาได้ทันที โดยไม่ต้องปลุกคนทั้งทีม — และมันคือที่ที่ 3 pillars ถูกใช้จริง เป็น checklist การ debug

Incident Response — ลำดับการรับมือ

เมื่อเกิด SEV1/SEV2 มี flow มาตรฐาน:

1. Detect — alert เด้ง (monitoring ทำงาน! ลด MTTD บทที่ 00)
2. Triage — ประเมิน severity + ผลกระทบ
3. Mitigate ก่อน fix — หยุดเลือดก่อน (rollback, failover, scale) — เป้าหมายแรกคือให้ผู้ใช้กลับมาใช้ได้ ไม่ใช่หา root cause
4. Communicate — แจ้ง stakeholder/ลูกค้า (status page)
5. Resolve — แก้ให้หายจริง
6. Postmortem — เรียนรู้จากมัน

ข้อ 3 สำคัญมาก มือใหม่มักติดกับดัก "ขอหา root cause ให้เจอก่อน" ทั้งที่ระบบยังล่มอยู่ — mitigate ก่อนเสมอ (เช่น rollback) แล้วค่อยสืบสวนสาเหตุตอนระบบกลับมาปกติแล้ว ทุกนาทีที่ล่ม = ผู้ใช้เดือดร้อน/เสียเงิน

Postmortem — เรียนรู้แบบ "ไม่โทษคน" (Blameless)

หลัง incident จบ เขียน postmortem เพื่อไม่ให้เกิดซ้ำ หัวใจคือ blameless — โฟกัสที่ ระบบและกระบวนการ ไม่ใช่ โทษคน

ถ้า postmortem กลายเป็นการหาคนผิด → คนจะปิดบังข้อมูล, ไม่กล้ารายงาน incident, และคุณจะไม่มีวันเรียนรู้อะไรเลย Blameless culture คือรากฐานที่ทำให้ทีมกล้าพูดความจริงและระบบดีขึ้นจริง

postmortem ที่ดีตอบ:

• เกิดอะไรขึ้น — timeline พร้อมเวลา (ได้จาก monitoring!)
• กระทบอะไร — ผู้ใช้กี่คน นานเท่าไหร่ (MTTD, MTTR เป็นเท่าไหร่จริง)
• ทำไมเกิด — root cause (ถาม "why" ซ้ำๆ / 5 Whys)
• ทำไมกว่าจะรู้/แก้ นานขนาดนี้ — monitoring จับได้ช้าไหม? alert ขาดไหม?
• Action items — จะทำอะไรเพื่อไม่ให้เกิดซ้ำ (มีเจ้าภาพ + กำหนดเวลา)

Action item ที่พบบ่อยจาก postmortem มักย้อนกลับมาที่ monitoring: "เพิ่ม alert สำหรับ X ที่เราไม่ได้จับ", "ทำ dashboard ให้เห็น Y", "ใส่ trace ใน service Z" — incident แต่ละครั้งคือ feedback ว่า observability ตรงไหนยังมีจุดบอด วนกลับไปปรับปรุงมัน

วงจรที่สมบูรณ์

Monitoring ดี → รู้เร็ว (MTTD ต่ำ) → runbook ช่วยแก้เร็ว (MTTR ต่ำ)
     ▲                                              │
     └──── postmortem หา action ปรับปรุง ◀───────────┘

นี่คือวงจรที่ทำให้ระบบ น่าเชื่อถือขึ้นเรื่อยๆ ทุกครั้งที่พัง

สรุป

• On-call ต้องยั่งยืน — alert คุณภาพดีคือการดูแลทีม (โยงบทที่ 14)
• จัด severity (SEV1/2/3) เพื่อระดมคนให้เหมาะกับความรุนแรง
• Runbook = checklist "เจอ X ทำ Y" ที่ใช้ 3 pillars debug — ผูกกับ alert
• Incident: mitigate (หยุดเลือด) ก่อน fix (หาสาเหตุ) เสมอ
• Blameless postmortem — โทษระบบ ไม่โทษคน — และ action items มักวนกลับมาปรับปรุง monitoring

---

🎓 จบหลักสูตร Zero to Hero!

คุณเดินทางครบแล้ว:

• ปูพื้นฐาน — ทำไม monitoring, 3 pillars, เก็บอะไรบ้าง
• แนวคิดหลัก — Golden Signals, RED/USE, SLO/Error Budget, cardinality, alerting
• Metrics — Prometheus, PromQL, Grafana + 2 labs (จากศูนย์ถึง alert)
• Logs — logging fundamentals + ELK ที่คุณมีอยู่ จัดระเบียบเป็นระบบ
• Traces — distributed tracing, OpenTelemetry + lab Jaeger
• Hero — correlate 3 pillars + incident response จริง

repo ของคุณตอนนี้มีครบทั้ง 3 เสาแล้ว 🎉 ขั้นต่อไปคือ ลองทำ lab ทั้งหมดด้วยมือ แล้วเอาไป instrument โปรเจกต์จริงของตัวเอง — observability เก่งขึ้นได้ด้วยการลงมือ ไม่ใช่แค่การอ่าน

กลับไปทำ lab ที่ docker/prometheus/ และ docker/tracing/ ควบคู่กับ ELK labs เดิม แล้วลองต่อ trace_id ระหว่าง log กับ trace ดู — นั่นคือก้าวจาก "รู้" ไปสู่ "ทำเป็น"