CISA Series ตอนที่ 34 : D4 - เมื่อระบบทำงานช้า/ล่ม — Capacity, Incident, Problem Management

ตอนนี้ผมขอเล่าเรื่องที่เป็น “ชีวิตจริงของ IT operations” — เมื่อระบบเริ่มช้า / เริ่มเพี้ยน / เริ่มล่ม — ใครทำอะไร?

CRM แบ่งเรื่องนี้เป็น 3 ขั้นที่ต่อกัน:

Capacity Management (Section 4.6) — รู้ก่อนล่ม
Incident Management (Section 4.7) — กู้คืนเมื่อล่ม
Problem Management (Section 4.7) — เลิกล่มซ้ำ

ทั้ง 3 ขั้นเป็น lifecycle เดียวกัน — แต่ exam ชอบหลอกว่า incident กับ problem เป็นเรื่องเดียวกัน

มันไม่ใช่ครับ และผมขออธิบายเรื่องนี้ให้ชัดเจนในตอนนี้

ขั้นที่ 1 — Capacity Management: รู้ก่อนล่ม#

ทำไม outage ส่วนใหญ่ “ค่อยๆ มา” ก่อนล่มจริง#

ความเข้าใจผิดที่ผมเคยมี: ระบบล่ม = อยู่ดีๆ ก็ล่ม

จริงๆ แล้วสำหรับ outage เกือบทุกแบบ — มี signal มาก่อน เป็นวันๆ หรือเป็นสัปดาห์ก่อนระบบล่มจริง:

Disk usage ค่อยๆ ขึ้นจาก 70% → 80% → 90% → 99% (ใช้เวลาเป็นเดือน)
Response time ค่อยๆ ช้าจาก 200ms → 500ms → 2s → timeout
CPU spike เกิดบ่อยขึ้นทีละน้อยๆ
Database connection pool ค่อยๆ ถูกใช้จนเต็ม

Capacity Management = ระบบที่จับ signal เหล่านี้ ก่อนที่จะกลายเป็น outage

ลองเปรียบกับทางหลวง — ก่อนรถจะติดสนิท จะมีช่วงเวลาที่ความเร็วช้าลงก่อน ถ้าจับ signal ช่วงนี้ได้ — มีเวลาเปิดเลนเพิ่ม / route ใหม่ / แจ้งเตือน

Capacity Management ทำอะไรบ้าง#

3 หน้าที่หลัก:

Monitor — เก็บ metric ของ resource (CPU, memory, disk, network bandwidth, database connection)
Threshold + Alert — ตั้งค่า threshold ที่ alert ก่อนถึงจุดวิกฤต
Forecast + Plan — ประมาณการความต้องการในอนาคต และวาง capacity ล่วงหน้า

ความผิดพลาดที่บ่อยคือ — มี monitor แต่ไม่มี alert ที่ actionable หรือมี alert แต่ไม่มี forecast

ตัวอย่างจริง: TV commercial vs server capacity#

ลองนึกถึง e-commerce platform ของไทย — server รับ load ปกติได้สบาย

วันหนึ่งฝ่าย Marketing ออก TV commercial ระดับชาติ — traffic พุ่ง 10 เท่าตัวภายใน 30 นาที

server ล่มภายใน 30 นาที ลูกค้าซื้อไม่ได้ 4 ชั่วโมงในช่วงที่ commercial ออกอากาศ

root cause: Capacity planning ไม่ครอบคลุม “demand spike จาก marketing campaign” และไม่มี auto-scaling policy

ที่ผมว่าน่าสนใจที่สุดคือ — นี่ไม่ใช่ปัญหา IT ล้วน มันคือปัญหาการสื่อสารระหว่าง business กับ IT

ถ้า Marketing บอก IT ล่วงหน้า 1 สัปดาห์ → IT มีเวลา scale up ระบบ → server รับ load ได้

แต่ถ้า Marketing บอก IT แค่ “วัน launch” → ไม่ทัน

มุมผู้บริหารที่ผมว่าควรเก็บ: Capacity planning เป็น business decision ที่ต้องการ input จากทุกฝ่าย ไม่ใช่งาน IT คนเดียว

Trap ของ exam เรื่อง capacity#

หลุมพราง	คำตอบที่ถูก
”uptime 99.9% = พอ”	ต้องดูด้วยว่า downtime ที่ 0.1% เกิดเมื่อไหร่ — peak hour vs off-hour ส่งผลต่างกันมาก
”capacity = IT’s problem”	demand growth (marketing, expansion) มาจาก business — IT ทำเองคนเดียวไม่ได้
”virtualization = ปลอดภัย”	hypervisor compromise = ทุก VM ถูก compromise พร้อมกัน

ขั้นที่ 2 — Incident Management: กู้คืนเมื่อล่มจริง#

Incident = restore service ASAP#

Incident Management คำถามเดียว: “ทำยังไงให้ user กลับมาใช้งานได้เร็วที่สุด”

ไม่ใช่ “ทำไมมันล่ม” ไม่ใช่ “ป้องกันไม่ให้เกิดอีกยังไง”

ลองเปรียบกับ ER ของโรงพยาบาล — เมื่อคนไข้มา หมอไม่ได้นั่งวินิจฉัยโรคก่อน, ไม่ได้สอบสวนวิถีชีวิต — หมอ stabilize ก่อน ทำให้ vital sign กลับมาดี ทำให้คนไข้ปลอดภัยจากภาวะวิกฤต

หา root cause = ขั้นตอนถัดไป (= Problem Management)

Workflow มาตรฐาน#

ขั้น	สิ่งที่ทำ	คนรับผิดชอบ
Detection	จับสัญญาณว่าเกิด incident	Monitor / user report
Logging	สร้าง ticket บันทึก incident	Helpdesk / NOC
Classification + Priority	จัดประเภท + กำหนด priority	Incident manager
Initial response	ลงมือ stabilize	Tech team
Resolution	กลับมาให้บริการได้	Tech team
Closure	ปิด ticket + ส่งต่อ Problem	Incident manager

Priority ที่ exam ชอบหลอก#

priority ของ incident ไม่ได้ขึ้นกับ — “ใครร้องเรียน”

CIO printer พัง — priority ต่ำ Payment processing ล่ม — priority สูง

priority = impact × urgency ที่กระทบ business

หลายองค์กรพลาดตรงนี้ — staff คนหนึ่งดังกว่า บ่นเก่งกว่า ก็ได้ priority สูงกว่า ทั้งที่ business impact ต่ำกว่ามาก

Trap ของข้อสอบ: “CIO request = high priority” — ผิด เพราะ priority ต้องตัดสินจาก business impact ไม่ใช่ requester seniority

SoD ในการ logging#

ที่หลายคนมองข้าม — คนที่เปิด ticket ไม่ควรเป็นคนเดียวกับคนที่ปิด ticket

ถ้า operator คนเดียว เปิด-แก้-ปิด ตัวเอง — เปิด door สำหรับ silent close: incident ที่ไม่ได้แก้จริง แต่ปิด ticket ไปแล้ว

control: ต้องแยก role ระหว่าง logging กับ resolving

ขั้นที่ 3 — Problem Management: เลิกล่มซ้ำ#

Incident ≠ Problem (สำคัญที่สุดของบทนี้)#

ถ้าจำได้แค่อย่างเดียวจากบทนี้ ขอให้จำ:

มิติ	Incident	Problem
เป้าหมาย	restore service	eliminate root cause
ความเร็วที่ต้องการ	เร็วที่สุด	ละเอียดที่สุด
ผลลัพธ์	ระบบกลับมาใช้ได้	ปัญหาไม่กลับมาอีก
เครื่องมือ	runbook, escalation	RCA (5 Whys, Fishbone)
ตัวอย่าง	”Reboot switch แล้ว line กลับมา"	"switch firmware bug — patch แล้วเลิกซ้ำ”

Hospital readmission analogy#

ลองนึกถึงโรงพยาบาล — คนไข้คนหนึ่งมา ER 3 ครั้งในเดือนเดียว ทุกครั้งหายใจไม่ออก ทุกครั้งให้ออกซิเจน + ส่งกลับบ้าน

Incident management = ให้ออกซิเจน ส่งกลับบ้าน (รักษาอาการ)
Problem management = ทำไมคนไข้กลับมาเรื่อยๆ → ตรวจปอด → เจอ asthma → จ่ายยา + แนะนำ environment → ปัญหาไม่กลับมาอีก

โรงพยาบาลที่ดี = stabilize ได้เร็ว โรงพยาบาลที่เก่ง = stabilize ได้เร็ว + วินิจฉัยต้นเหตุ + รักษาไม่ให้กลับ

ตัวอย่างจริง: factory switch ที่ล่มเดือนละ 3 ครั้ง#

โรงงานแห่งหนึ่งที่ระยอง — production line shutdown 3 ครั้งในเดือน เพราะ “network timeout error”

ทุกครั้ง — IT reboot switch, line กลับมาใน 30 นาที (incident management ทำได้ดี)

แต่ไม่มีใครถาม — “ทำไม switch มัน fail ซ้ำ?”

ครั้งที่ 4 — fail ตอนกำลังจะ ship ของส่งออก ส่งของไม่ทัน → ค่าปรับตามสัญญา

ตอนนั้นถึงเริ่ม investigate — เจอว่า switch มี firmware bug ที่ trigger ตอน temperature สูง vendor ออก patch มา 6 เดือนแล้ว แต่ไม่มีใคร apply

problem management failure: incident เกิดซ้ำ ไม่มีใครยกขึ้นเป็น problem

Workaround vs Fix#

อีกหลุมพรางที่ exam ออก — “workaround = fix”

ไม่ใช่ครับ:

Workaround = วิธีแก้เฉพาะหน้า ทำให้ระบบทำงานต่อได้ ทั้งที่ root cause ยังอยู่
Fix = แก้ root cause permanent

ตัวอย่าง: switch fail → reboot = workaround (ปัญหา firmware bug ยังอยู่) → patch firmware = fix

มาตรฐานที่ดี — workaround มีไว้ให้ helpdesk ใช้ระหว่างที่ permanent fix กำลัง develop แต่ห้ามให้ workaround กลายเป็น “fix ถาวร”

ในระบบ ITIL จะเรียกตัว known issue ที่มี workaround ชั่วคราว = Known Error ต้องเก็บใน Known Error Database พร้อม timeline ของ permanent fix

Undocumented workaround = ความเสี่ยงที่ใหญ่ที่สุด#

อีกอย่างที่ผมเจอบ่อย — workaround ที่ไม่ได้เขียนลง

ตัวอย่าง: POS terminal ที่กรุงเทพ ทุกร้านเจอปัญหา freeze ช่วง 5-8 โมงเย็น staff ทุกคนรู้ว่า “reboot terminal แล้วใช้ได้”

ไม่มีใครจดบันทึก — ส่งต่อกันด้วยปากเปล่า

วันที่ auditor ขอดู incident log — ไม่มี record ของปัญหา freeze เลย

problem ลึกซ่อน 9 เดือนโดย management ไม่รู้

ความรู้ที่ไม่ได้ document = พนักงานลาออกเมื่อไหร่ ความรู้ตามไปด้วย

flow รวม: 3 ขั้นที่ต่อกัน#

1
Capacity Monitoring  →  จับ signal ก่อนเหตุ
2
       ↓
3
ระบบล่ม
4
       ↓
5
Incident Management  →  restore ASAP
6
       ↓
7
RCA + Problem Mgmt  →  หา root cause + fix permanent
8
       ↓
9
Capacity Adjustment  →  update threshold ตามที่เรียนรู้
10
       ↓
11
loop ใหม่

3 ขั้นนี้ไม่ใช่ลำดับครั้งเดียว — มันเป็น loop ที่หมุนตลอดเวลา

ทุกรอบที่ผ่าน — ระบบควรฉลาดขึ้น capacity monitoring ละเอียดขึ้น, incident response เร็วขึ้น, root cause ถูกเก็บใน knowledge base

ถ้าระบบไม่ฉลาดขึ้น = ไม่มี learning loop = problem management ไม่ทำงาน

ส่วนที่ auditor ต้องตรวจ#

ถ้าเป็น auditor ที่ตรวจ operations ของ organization ผมจะถาม 3 คำถาม:

“Capacity dashboard ของเรามีอะไรบ้าง? threshold ตั้งที่ไหน?” — ถ้าไม่มี dashboard, finding ทันที
“Last 6 เดือน incident ที่ priority 1-2 มีกี่ ticket — และมี problem ticket ที่ link กลับกี่ตัว?” — ถ้าตัวเลขห่างกันมาก = problem management ไม่ทำงาน
“Known Error Database มีรึเปล่า? มีกี่รายการที่อยู่นานกว่า 90 วัน?” — Known Error ที่ค้างนาน = sign ว่า permanent fix ไม่ progressing

ปิดบท: คุณภาพ IT ไม่ได้วัดที่จำนวน incident#

มีคนชอบบอกว่า — IT ที่ดี = IT ที่ไม่มี incident

ผมว่าไม่ใช่ เพราะ incident เกิดได้เสมอ ใน scale ที่ใหญ่พอ

IT ที่ดีจริงๆ วัดที่:

Mean time to detect สั้น — รู้ตัวเร็ว
Mean time to recover สั้น — restore เร็ว
Recurrence rate ต่ำ — ไม่ล่มซ้ำเรื่องเดิม

IT ที่ตัวเลขสูงในข้อ 1-2 แต่สูงในข้อ 3 ด้วย = firefighting ดี แต่ prevention ห่วย

ตอนถัดไปเราจะลงเรื่องที่เป็นต้นเหตุ outageอันดับ 1 ของ IT ทั่วโลก — ไม่ใช่ hacker ไม่ใช่ hardware fail แต่คือ — change ที่เราทำเอง Change Management + Patch Management

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.6 Systems Availability and Capacity Management + Section 4.7 Problem and Incident Management