14.11 Known recurring issues + scorecard

บทนี้รวบรวมปัญหาที่เกิดซ้ำในระบบ VTRC, แนวทางการป้องกัน, และ scorecard สรุปความพร้อมของทีมปฏิบัติการ

ปัญหาที่เกิดซ้ำ (recurring issues)

ตารางนี้เก็บปัญหาที่พบบ่อยจนเป็น pattern — ควรอัปเดตทุกครั้งที่เกิด incident ใหม่

#	ปัญหา	ความถี่	root cause	mitigation ระยะสั้น	prevention ระยะยาว
R-1	LDAP bind ล้มเหลวเป็นบางครั้ง	สัปดาห์ละครั้ง	network ระหว่าง GCP กับ on-prem ไม่เสถียร	restart cu-central-api	VPN ที่เสถียรกว่า, retry logic
R-2	PDF payslip ไม่ออก	เดือนละครั้ง (ตอนออกเงินเดือน)	qpdf + อักขระพิเศษใน password	restart replica	escape shell arg ที่ถูกต้อง
R-3	Service OOM บาง replica	ไม่แน่นอน	memory leak ใน Node	restart	profile memory, แก้ leak
R-4	disk ใกล้เต็ม	เดือนละครั้ง	log ไม่ rotate	ลบ log เก่า	logrotate + alert
R-5	SSL cert ใกล้หมดอายุ	ปีละครั้งต่อ cert	ไม่มี auto-renew	ต่ออายุ manual	Let's Encrypt + certbot
R-6	deploy แล้ว service crash	ทุกครั้งที่ deploy	env var ขาด, image tag ผิด	rollback	automated test ก่อน deploy
R-7	fund-rate / cu-central cron ไม่รัน	เดือนละครั้ง	APP_NO=1 ตาย (gate เฉพาะ job เหล่านี้; delegate/stat รันทุก replica)	restart APP_NO=1	distributed lock, monitoring
R-8	Database connection pool เต็ม	ไม่แน่นอน	query ค้างนาน	kill process	เพิ่ม index, ลด pool size
R-9	GraphQL query ช้า	สัปดาห์ละครั้ง	N+1 query, ไม่มี index	restart	แก้ query, เพิ่ม index
R-10	ผู้ใช้ไม่ได้รับ OTP	สัปดาห์ละครั้ง	SMS gateway เงียบ	trigger OTP manual	เปลี่ยน gateway, retry

ปัญหาด้านการดำเนินงาน

OPS-1 · ไม่มี monitoring

ปัจจุบันไม่มี tool ตรวจสอบสถานะระบบอัตโนมัติ — ทุกอย่างตรวจด้วยมือ

ผลกระทบ: ตรวจพบปัญหาช้า, ผู้ใช้แจ้งก่อนทีมงานรู้

ผลกระทบต่อ operations: ทีมต้องนั่ง monitor manual, ตอบ react แทน proactive

OPS-2 · ไม่มี alerting

ไม่มีระบบแจ้งเตือนเมื่อ service down, disk เต็ม, cert จะหมดอายุ

ผลกระทบ: ปัญหาเล็กกลายเป็นใหญ่ก่อนจะสังเกตเห็น

OPS-3 · deploy manual

deploy ทุก service ทำด้วยมือ — ความเสี่ยง human error สูง

OPS-4 · ไม่มี staging ที่เท่า production

UAT ใช้ dataset ที่ต่างจาก production — บางบักตรวจไม่เจอใน UAT

OPS-5 · runbook ไม่สมบูรณ์

Volume นี้พยายามเติมช่องว่าง แต่ยังต้องการ:

• ชื่อและช่องทางติดต่อผู้ประสานงานจริง
• host path และ IP ที่แท้จริง
• credentials ที่จัดการในตัวจัดการรหัสผ่าน (ไม่ใช่ในเอกสาร)

OPS-6 · ทีมปฏิบัติการเล็ก

จากการสังเกตจาก structure ของระบบ ทีมปฏิบัติการดูเล็ก — การ on-call อาจตกอยู่กับคนไม่กี่คน

สิ่งที่ทีมควรลงทุนทำ (ranked by ROI)

ลำดับ	สิ่งที่ต้องทำ	ROI	effort
1	ตั้ง uptime monitoring (UptimeRobot, Pingdom)	สูงมาก	ต่ำ — 1 ชม.
2	ตั้ง alert เมื่อ disk เต็ม	สูงมาก	ต่ำ — 1 ชม.
3	ตั้ง alert เมื่อ cert จะหมดอายุ	สูงมาก	ต่ำ — 2 ชม.
4	ทำ logrotate ทุก host	สูง	ต่ำ — 2 ชม.
5	สร้าง backup script อัตโนมัติ	สูงมาก	ปานกลาง — 1 วัน
6	ทดสอบ restore เดือนละครั้ง	สูงมาก	ปานกลาง — 4 ชม./เดือน
7	เพิ่ม health endpoint ในทุก service	สูง	ปานกลาง — 1 วัน
8	สร้าง deploy script แทน manual	สูง	ปานกลาง — 2 วัน
9	ตั้ง centralized logging (Loki, ELK)	สูง	สูง — 1 สัปดาห์
10	เปลี่ยนไป Let's Encrypt + certbot	สูง	ปานกลาง — 1 วัน
11	สร้าง CI/CD สำหรับทุก repo	สูง	สูง — 1 สัปดาห์
12	สร้าง DR site	สูงมาก	สูงมาก — 1 เดือน

Scorecard — ความพร้อมของทีมปฏิบัติการ

หมวด	เกณฑ์	สถานะ VTRC	คะแนน
Monitoring	มี uptime monitor 24/7	ไม่มี	0/10
	มี error rate alert	ไม่มี	0/10
	มี disk/cpu/memory alert	ไม่มี	0/10
	มี slow query alert	ไม่มี	0/10
Backup	ทำ backup อัตโนมัติทุกวัน	ไม่แน่ใจ	3/10
	เก็บ off-site	ไม่แน่ใจ	2/10
	ทดสอบ restore เดือนละครั้ง	ไม่มี	0/10
	มี RTO/RPO ที่กำหนด	ไม่มี	0/10
Deploy	deploy อัตโนมัติผ่าน CI/CD	2/5 repos	4/10
	มี staging ที่เท่า production	ไม่มี	2/10
	มี rollback ที่ทดสอบแล้ว	ไม่แน่ใจ	3/10
	มี deploy runbook	Volume นี้	6/10
Logging	มี centralized logging	ไม่มี	0/10
	log เก็บอย่างน้อย 90 วัน	ไม่แน่ใจ	3/10
	ไม่มี PII ใน log	มี PII	2/10
	log format consistent	ไม่ consistent	3/10
Security	cert ไม่เคยหมดอายุโดยไม่รู้	ต้อง monitor manual	4/10
	ไม่มี default password	มี JWT_SECRET='secret'	3/10
	port management	phpMyAdmin เปิดสาธารณะ	3/10
DR	มี DR runbook	Volume นี้เริ่มต้น	5/10
	มี DR site	ไม่มี	0/10
	ทดสอบ DR ปีละครั้ง	ไม่เคย	0/10
Documentation	runbook สมบูรณ์	Volume นี้	6/10
	architecture doc	Volume 2	8/10
	inventory ปัจจุบัน	Volume 13.1	6/10

คะแนนรวม: 67/170 (39%) — ต่ำกว่ามาตรฐานอุตสาหกรรม (ควร ≥ 80%)

แผนปรับปรุง 30 วัน

สิ่งที่ทำได้ใน 30 วันแรก โดยใช้ทรัพยากรน้อย:

สัปดาห์ที่ 1 — มองเห็นระบบ

• [ ] ตั้ง UptimeRobot หรือ Pingdom สำหรับทุก domain
• [ ] ตั้ง disk alert ที่ 80% บนทุก host
• [ ] ตรวจ SSL cert expiry ของทุก domain และบันทึก
• [ ] เขียน inventory ของ host และ IP จริง

สัปดาห์ที่ 2 — สำรองข้อมูล

• [ ] สร้าง backup script ตามบท 13.10
• [ ] ตั้ง cron ให้รันทุกคืน
• [ ] เก็บ backup ลง GCS bucket
• [ ] ทดสอบ restore database

สัปดาห์ที่ 3 — ลดความเสี่ยงด่วน

• [ ] เปลี่ยน JWT_SECRET จาก 'secret' เป็นค่าจริง
• [ ] จำกัด phpMyAdmin ให้เข้าได้เฉพาะบาง IP
• [ ] ตั้ง logrotate ทุก host
• [ ] ตั้ง cert expiry alert (30 วันล่วงหน้า)

สัปดาห์ที่ 4 — ทำให้ deploy ปลอดภัยขึ้น

• [ ] เขียน deploy script สำหรับ vtrc-api
• [ ] ทดสอบ rollback ใน UAT
• [ ] เอกสาร commit + tag ก่อน deploy
• [ ] เริ่มวางแผน CI/CD สำหรับ repo อื่น

แผนระยะยาว (90 วัน)

• [ ] สร้าง centralized logging (Loki + Grafana)
• [ ] สร้าง APM (Jaeger หรือ Datadog)
• [ ] เพิ่ม health endpoint ในทุก service
• [ ] ย้ายไป Let's Encrypt สำหรับ domain ที่เป็น public
• [ ] สร้าง CI/CD pipeline สำหรับทุก repo
• [ ] เลือกและทดสอบ DR site

รายละเอียดเพิ่มเติมอยู่ใน Volume 15 (Modernization Plan)

สรุป Volume 14

Volume นี้เป็นจุดเริ่มต้นของการจัดระเบียบ operations — ไม่ใช่จุดสิ้นสุด

สิ่งที่ผู้อ่านควรนำไปใช้:

1. bookmark บท 13.1 สำหรับ quick reference
2. ทดสอบ runbook ใน UAT ก่อนใช้จริงใน production
3. ปรับปรุง runbook ตามสภาพจริงของทีมและ infrastructure
4. เริ่มจากสิ่งที่ ROI สูงและ effort ต่ำ — ตามตารางด้านบน
5. บันทึก incident ทุกครั้งเพื่อเรียนรู้

Volume ถัดไป (Volume 14 · Tech Debt Register) จะลงรายละเอียดของหนี้เทคนิคที่ส่งผลต่อ operations ในระยะยาว