ทำไม 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 หน้าที่หลัก:

1. Monitor — เก็บ metric ของ resource (CPU, memory, disk, network bandwidth, database connection)
2. Threshold + Alert — ตั้งค่า threshold ที่ alert ก่อนถึงจุดวิกฤต
3. 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#

Incident = restore service ASAP#

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

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

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

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

Workflow มาตรฐาน#

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 คนเดียว เปิด-แก้-ปิด ตัวเอง = เปิดประตูให้ silent close: incident ที่ไม่ได้แก้จริง แต่ปิด ticket ไปแล้ว

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

Help Desk Structure: 3 Tier + Escalation Matrix#

incident management จะ work ก็ต้องมี structure ของคนรับ ไม่ใช่ทุก issue ส่งให้ engineer ระดับสูงทันที

CRM 4.7.2A อธิบาย structure แบบ tiered ที่ ITIL community ใช้กันทั่วไป:

Escalation matrix = กฎที่บอกว่าเมื่อไหร่ ticket ต้องขยับ tier:

• Time-based — Tier 1 แก้ไม่จบใน 30 นาที → escalate Tier 2
• Severity-based — incident priority 1 → ขึ้น Tier 2 ทันที
• Knowledge-based — Tier 1 ไม่มี runbook สำหรับ issue นั้น → escalate

กับดักของ exam: “ทุก ticket ขึ้น Tier 3” ผิด เพราะ Tier 3 คนน้อย ราคาแพง ต้องใช้กับ issue ที่จำเป็นจริงๆ การ over-escalate = waste resource แล้วยังทำให้ Tier 3 ตอบ critical issue ไม่ทัน

มุม IS Auditor ของ help desk#

3 จุดที่ตรวจ:

• First call resolution rate — % ของ ticket ที่ Tier 1 ปิดได้เอง (สูง = runbook + training ดี)
• Escalation timing — Tier 1 escalate ภายใน SLA หรือเปล่า (escalate ช้า = user รอนาน)
• Knowledge base maintenance — ที่แก้ใน Tier 2/3 ถูก document กลับมาเป็น Tier 1 runbook ไหม (ถ้าไม่ — issue เดียวกัน escalate ซ้ำตลอดไป)

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

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

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 = ความเสี่ยงที่ใหญ่ที่สุด#

อีกอย่างที่เป็น pattern คลาสสิคของวงการ — workaround ที่ไม่ได้เขียนลง

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

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

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

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

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