3. Incident Management & Systematic Troubleshooting

ทำไมหัวข้อนี้สำคัญกับ interview

ผู้สัมภาษณ์อยากรู้ว่า "ตอนไฟไหม้" คุณ มีระบบคิด หรือแค่สุ่มลอง. คำถามยอดฮิตคือ "เล่า incident ที่เคยเจอ" และ "อธิบายวิธีไล่หา root cause". คำตอบที่ดีต้องมี โครงสร้าง (detect → triage → mitigate → RCA → postmortem) และสะท้อนวัฒนธรรม blameless.

หัวใจของ incident management: หยุดเลือดก่อน (mitigate) แล้วค่อยหาสาเหตุ (RCA) — สลับลำดับเมื่อไรมักทำ outage ยาวขึ้น.

Core Concepts

Incident Lifecycle

วงจร incident — เป้าหมายคือลด MTTD และ MTTR

Severity Levels (ตัวอย่างที่พบบ่อย)

Sev	ความหมาย	ตัวอย่าง	การตอบสนอง
SEV1	กระทบผู้ใช้วงกว้าง/รายได้	ทั้งระบบล่ม, checkout พังหมด	page ทันที, ตั้ง war room
SEV2	กระทบบางส่วน/degraded	feature หลักช้ามาก	page on-call
SEV3	กระทบจำกัด มี workaround	bug ไม่ critical	จัดการในเวลาทำงาน
SEV4	แทบไม่กระทบผู้ใช้	cosmetic, log noise	backlog

Metrics ที่ต้องรู้

MTTD (Mean Time To Detect) — จากเกิดปัญหาถึงรู้ตัว. ลดด้วย monitoring ที่ดี.
MTTR (Mean Time To Recover/Repair) — จากรู้ตัวถึงกู้คืน. ลดด้วย runbook + automation.
MTBF (Mean Time Between Failures) — ระบบอยู่ได้นานแค่ไหนก่อนพังอีก.

ประโยคที่ทำให้ดูมือโปร

"เป้าหมายหลักตอน incident คือ ลด MTTR ไม่ใช่หา root cause ให้เจอเดี๋ยวนั้น" — mitigate ก่อน (rollback/failover/scale) แล้วค่อยสืบสวนสาเหตุตอนระบบนิ่งแล้ว.

On-call & Roles

Rotation: primary + secondary (backup), มี escalation policy เมื่อ primary ไม่ตอบใน X นาที.
Incident Commander (IC): คนตัดสินใจและคุมทิศทาง (ไม่จำเป็นต้องเป็นคนแก้เอง).
Comms lead: อัปเดต stakeholder/สถานะให้ทีมโฟกัสงานแก้.
Ops/Subject-matter expert: ลงมือ debug/แก้.

การแยกบทบาทสำคัญมากใน SEV1: ป้องกัน "ทุกคนแก้พร้อมกันแต่ไม่มีใครคุมภาพรวม".

Structured Troubleshooting — ไล่หา root cause อย่างเป็นระบบ

ยืนยันปัญหา จาก signal จริง (metric/alert) ไม่ใช่ข่าวลือ — ตั้งขอบเขต "อะไรพัง อะไรยังปกติ".
ตั้งสมมติฐาน (hypothesis-driven) แล้วทดสอบทีละอัน อย่าสุ่มแก้.
ใช้ differential diagnosis: "มีอะไรเปลี่ยนล่าสุด?" (deploy, config, traffic, dependency).
Bisection: ตัดครึ่งพื้นที่ปัญหา (เช่น ปิดครึ่ง traffic, ย้อน commit ครึ่งทาง) เพื่อ localize.
USE method กับ resource: เช็ก Utilization / Saturation / Errors ของ CPU, mem, disk, net.
5 Whys เพื่อขุดจาก symptom ลงไปถึง cause เชิงระบบ.

ตัวอย่าง 5 Whys:

text

อาการ: checkout ตอบ 503
1. ทำไม 503? → app หมด connection ไป DB
2. ทำไมหมด? → connection pool เต็ม
3. ทำไมเต็ม? → query ค้างนานผิดปกติ
4. ทำไม query ค้าง? → ขาด index หลัง schema เปลี่ยน
5. ทำไมขาด index? → migration ไม่ครอบ index + ไม่มี review checklist
→ root cause เชิงระบบ: process review ไม่จับ index (ไม่ใช่ "คนทำ migration ผิด")

Blameless Postmortem

เขียนหลัง incident (มัก SEV1–2) ครอบคลุม: timeline, impact, root cause, สิ่งที่ทำได้ดี, สิ่งที่ผิดพลาด, action items (มี owner + due date). หลัก blameless: โฟกัสที่ ระบบและ process ที่ยอมให้ error เกิด ไม่ใช่โทษบุคคล — เพราะการโทษคนทำให้คน ปิดบังปัญหา และไม่มีใครกล้าแตะ production.

blameless ไม่ได้แปลว่าไม่มีความรับผิดชอบ

blameless = ถามว่า "ทำไมระบบถึงยอมให้พลาดได้ง่ายขนาดนี้" ไม่ใช่ "ใครกดผิด". ยังต้องมี action items ที่ชัดและมีเจ้าภาพ — แค่ไม่ลงโทษบุคคล.

เชื่อมกับ AWS / Cloud ที่คุณรู้อยู่แล้ว

แนวคิด	บริการ/แนวทางบน AWS
Detect (alert)	CloudWatch Alarms → SNS → PagerDuty/OpsGenie
On-call & escalation	AWS Systems Manager Incident Manager (response plan + escalation)
Mitigation อัตโนมัติ	SSM Runbooks / Automation, Auto Scaling, ALB failover, Route 53 health check
War room / timeline	Incident Manager timeline, CloudWatch dashboard รวม
Rollback	CodeDeploy (blue/green, automatic rollback), IaC ย้อน version

ผูกกับประสบการณ์ที่มี

เวลาถูกถาม ให้ยกตัวอย่างจริง เช่น "ตั้ง CloudWatch Alarm บน 5xx ของ ALB → SNS → PagerDuty, mitigate ด้วยการ rollback ผ่าน CodeDeploy แล้วค่อยทำ RCA". นี่แสดงว่าคุณ เชื่อม cloud tooling กับ incident process ได้จริง.

คำถาม interview ที่เจอบ่อย + แนวคำตอบ

"เล่า incident ที่เคยเจอและวิธีจัดการ" (มัก follow ด้วย STAR) → เล่าเป็นโครง: detect ยังไง → triage severity → mitigate (rollback/failover) → RCA → postmortem + action item. เน้นผลลัพธ์และสิ่งที่ปรับปรุงหลังจากนั้น.
"เจอ alert ตอนตี 3 ว่า latency พุ่ง จะทำอะไรก่อน?" → ยืนยันจาก dashboard ว่าเป็นจริงและกระทบผู้ใช้ (symptom) → เช็ก "อะไรเปลี่ยนล่าสุด" (deploy/config) → mitigate ก่อน (rollback/scale) → แล้วค่อยขุด root cause.
"postmortem ที่ดีมีอะไรบ้าง? blameless คืออะไร?" → timeline, impact, root cause, action items มี owner/due; blameless = โฟกัสระบบ/process ไม่โทษบุคคล เพื่อให้คนกล้ารายงานความจริง.
"MTTR กับ MTTD ต่างกันยังไง ลดแต่ละอันด้วยอะไร?" → MTTD ลดด้วย monitoring/alert ที่ดี; MTTR ลดด้วย runbook, automation, rollback ที่เร็ว และการซ้อม (game day).
"ใช้ 5 Whys ยังไง มีข้อควรระวังไหม?" → ถาม "ทำไม" ต่อเนื่องจนถึง cause เชิงระบบ; ระวังอย่าหยุดที่ "human error" — ให้ถามต่อ ว่าทำไมระบบถึงยอมให้ human error นั้นเกิดผลกระทบได้.

Pitfalls — จุดที่ผู้สมัครมักพลาด

ระวังกับดักเหล่านี้

หา root cause ก่อน mitigate → outage ยาวขึ้นโดยไม่จำเป็น.
ไม่มี IC ชัดเจนใน SEV1 → ทุกคนแก้มั่ว ไม่มีใครคุมภาพรวม/สื่อสาร.
โทษบุคคลใน postmortem → คนปิดบังปัญหา วัฒนธรรมพัง.
หยุดที่ "human error" เป็น root cause → ไม่แก้ระบบที่ยอมให้พลาดได้.
action items ไม่มี owner/due → เขียน postmortem แล้วไม่มีอะไรเปลี่ยน.
สุ่มแก้หลายอย่างพร้อมกัน → พังเพิ่มและแยกไม่ออกว่าอะไรช่วย.

Quiz ท้ายบท

ตอบแล้ว 0/7

1.ระหว่าง incident ที่กำลังกระทบผู้ใช้ ควรทำสิ่งใดก่อน?
2.'blameless postmortem' หมายถึงอะไร?
3.MTTD ต่างจาก MTTR อย่างไร?
4.บทบาทของ Incident Commander (IC) ใน SEV1 คืออะไร?
5.การใช้ 5 Whys แล้วสรุป root cause ว่า 'engineer กด deploy ผิด' มีปัญหาอย่างไร?
6.ข้อใดคือแนวทาง troubleshooting ที่เป็นระบบที่สุด?
7.action items ใน postmortem ที่ดีควรมีลักษณะใด?

Cheat Sheet — อ่านก่อนเข้าห้องสัมภาษณ์

สรุปเร็ว 30 วินาที

Lifecycle: Detect → Triage → Mitigate → Resolve → Postmortem
Mitigate ก่อน RCA — เป้าคือลด MTTR ไม่ใช่หา cause เดี๋ยวนั้น
MTTD ลดด้วย monitoring · MTTR ลดด้วย runbook/automation/rollback
SEV1 ต้องมี IC (คุมทิศทาง) + comms lead + ops แยกบทบาท
Troubleshoot: hypothesis-driven, "อะไรเปลี่ยนล่าสุด", bisection, USE method, 5 Whys
Blameless = แก้ระบบ ไม่โทษคน; action item ต้องมี owner + due date
AWS: CloudWatch Alarm → SNS → PagerDuty · SSM Incident Manager/Runbooks · CodeDeploy rollback