16.12 Success criteria + rollback plan

บทสุดท้ายของ Volume 16 สรุป success criteria ระดับ Wave และระดับ modernization ทั้งหมด พร้อม rollback plan

Success criteria ระดับ Wave

Wave 0 · Stop-the-bleed

KPI	เป้าหมาย
Critical debt	13 → ≤ 3 รายการ
Production downtime จาก Wave 0 task	0 ครั้ง
Pen-test ใหม่	ไม่พบ Critical
Uptime monitor + alert	ติดตั้งครบทุก domain
Runbook อัปเดต	ครบทุก task

ถ้าไม่ผ่าน: ห้ามเริ่ม Wave 1 จนกว่าจะผ่าน หรือปรับ scope ของ Wave 0

Wave 1 · Stabilize

KPI	เป้าหมาย
Node runtime	ทุก service ใช้ LTS 20+
Health endpoint	ครบ 5/5 service
CI/CD	ครบ 5/5 repo
Centralized logging	ครอบคลุมทุก service
Monitoring + alerting	ครอบคลุม
High debt	ลด ≥ 15 รายการ
MTTR	< 1 ชั่วโมง
esm shim	ลบออก
_bk files	0 รายการ
Dependency EOL	ทุกตัวเป็น version ที่ยังไม่ EOL

ถ้าไม่ผ่าน: pause Wave 2 จนกว่าจะแก้

Wave 2 · Backend extraction to Go

KPI	เป้าหมาย
Bounded context ที่แยก	≥ 3 ตัว
vtrc-api LOC	ลด ≥ 30%
Cross-schema write debt	หมดไป
In-process cron	แทนด้วย distributed scheduler
MTTR	< 30 นาที
Service ใหม่	มี metric, log, health endpoint
Contract test coverage	≥ 90% ของ operation

Wave 3 · Frontend migration to Nuxt 3

KPI	เป้าหมาย
Frontend บน Nuxt 3	ครบ 2/2
Visual regression test	ครอบคลุมทุกหน้าหลัก
Lighthouse Performance	≥ 80
Lighthouse Accessibility	≥ 80
Bundle size	ลด ≥ 30%
React/AntD v3 ใน codebase	ไม่มี

Success criteria ระดับ modernization ทั้งหมด

ทางเทคนิค

KPI	ปัจจุบัน	เป้าหมาย
Critical debt	13	0
High debt	15+	≤ 3
Node runtime	12 (EOL)	20 LTS
Service ที่มี health	0/5	5/5+
CI/CD	2/5	5/5
Observability	ไม่มี	ครบ
Bounded context แยก	0	≥ 3
Frontend ทันสมัย	0/2	2/2

ทางปฏิบัติการ

KPI	ปัจจุบัน	เป้าหมาย
Deploy frequency	หลายสัปดาห์/ครั้ง	ทุกวัน (ถ้าต้องการ)
Lead time	หลายชั่วโมง	< 30 นาที
MTTR	หลายชั่วโมง	< 15 นาที
Change failure rate	unknown	< 5%
Manual deployment step	หลายขั้น	0 (push-button)

ทางธุรกิจ

KPI	เป้าหมาย
Uptime	≥ 99.9%
User complaint เรื่อง performance	ลดลง ≥ 50%
Time-to-market ของ feature ใหม่	ลดลง ≥ 30%
Security incident	0

Definition of Done ระดับ modernization

Modernization "เสร็จ" เมื่อ:

• [ ] Critical + High debt = 0
• [ ] ทุก service บน runtime/modern framework
• [ ] observability ครบ (log + metric + trace + alert)
• [ ] CI/CD ครบทุก repo
• [ ] bounded context ≥ 3 ตัวแยกออกจาก monolith
• [ ] frontend ทั้งคู่ migrate แล้ว
• [ ] team retrospective ยืนยันว่า sustainable

Rollback strategy ระดับ modernization

หลักการ

Modernization แต่ละขั้นต้อง rollback ได้ — ไม่มีขั้นใดที่เป็นจุด "ไม่กลับ"

Rollback ระดับ Wave

Wave	Rollback
Wave 0	คืน git commit (ส่วนใหญ่) + คืน env var
Wave 1	คืน version ก่อน upgrade + deploy image เก่า
Wave 2	ปิด feature flag → traffic กลับ vtrc-api legacy
Wave 3	ปิด Nginx route → traffic กลับ React app

Rollback playbook template

สำหรับทุกการเปลี่ยนแปลงที่ deploy:

## Rollback Plan: [task name]

### Trigger
- error rate > 1% ภายใน 15 นาที
- complaint จากผู้ใช้ > X รายการ
- monitoring พบ anomaly

### Step
1. (ถ้ามี feature flag) ปิด flag ใน config
2. deploy version ก่อนหน้า: `docker pull <old-image>:<old-tag>`
3. restart service: `docker-compose up -d <service>`
4. ตรวจสอบ error rate, latency
5. แจ้งทีม + document incident

### Time budget
- rollback ต้องเสร็จภายใน 30 นาที
- ถ้า rollback ใช้เวลา > 30 นาที → เรียก escalation

Rollback ระดับ architecture

ถ้าทั้ง Wave ล้มเหลว (เช่น service ใหม่ไม่ stable):

1. freeze traffic ไป service ใหม่ — ปิด feature flag
2. ให้ legacy รับ traffic 100% อีกครั้ง
3. เก็บ service ใหม่ไว้ (ไม่ delete) — debug แล้วลองอีกครั้ง
4. decommission decision — ถ้ามากกว่า 2 เดือนแล้วยังไม่ stable → ลบทิ้ง ทำ context อื่นก่อน

Decision gate หลังแต่ละ Wave

หลัง Wave เสร็จ ประชุม stakeholder เพื่อตัดสินใจ:

คำถาม	ถ้า "ใช่"	ถ้า "ไม่"
KPI ผ่านเกณฑ์?	ไป Wave ถัดไป	pause และแก้
Risk score รวมลดลง?	ไป Wave ถัดไป	review mitigation
ทีมพร้อม?	ไป Wave ถัดไป	pause + training
งบเพียงพอ?	ไป Wave ถัดไป	ขอเพิ่ม หรือลด scope
ROI ยังคุ้ม?	ไป Wave ถัดไป	re-evaluate

"Stop modernization" trigger

บางกรณีควรหยุด modernization ก่อนเสร็จ:

Trigger	Action
Security incident ที่ต้อง all-hand	pause modernization, focus incident
Business pivot	re-evaluate scope
ทีมหมดแรง (happiness < 6/10)	pause 1-2 sprint
งบบาน > 150%	re-evaluate กับผู้บริหาร
ROI ไม่คุ้มแล้ว	stop, accept partial

Post-modernization

หลัง Wave 3 เสร็จ:

1. Retrospective ระดับองค์กร

• สิ่งที่ทำได้ดี
• สิ่งที่ผิดพลาด
• lesson learned สำหรับโครงการถัดไป

2. อัปเดตเอกสาร

• ทุก Volume ใน manual นี้ → อัปเดตให้ตรงสถานะใหม่
• ลบ debt ที่แก้แล้วจาก Volume 14
• เพิ่ม architecture ใหม่ใน Volume 2

3. สร้าง "modernization debt" register ใหม่

modernization เองก็สร้าง debt ใหม่ — track ไว้ใน Volume 14 (เพิ่ม section "debt ที่เกิดหลัง modernization")

4. ตั้ง team ถาวรสำหรับ platform

• SRE team
• Platform team (ดูแล shared library, contract test)
• Domain team ตาม bounded context

5. Continuous modernization

Modernization ไม่เคย "เสร็จจริง" — ต้องมีกระบวนการ:

• ทบทวน debt register ทุกไตรมาส
• ลด debt ต่อเนื่อง (ไม่ใช่รอ modernization ครั้งใหญ่อีก)
• อัปเดต dependency ทุกเดือน
• ทำ penetration test ปีละครั้ง

สรุป Volume 16

Volume นี้แปลง debt register (Volume 14) ให้เป็นแผนงานที่ทีมทำได้จริง

สาระสำคัญ:

1. แบ่งเป็น 4 Wave — Wave 0 (stop-the-bleed), Wave 1 (stabilize), Wave 2 (backend extraction), Wave 3 (frontend migration)
2. ใช้ strangler pattern — migrate ทีละส่วน, ไม่ใช่ big-bang
3. ทุกขั้นต้อง reversible + มี rollback plan
4. ลงทุนใน training และ observability
5. KPI + decision gate ทุก Wave
6. ไม่จำเป็นต้องทำครบ — Wave 0 + 1 ได้ ROI ส่วนใหญ่

ระยะเวลาและงบ:

• ทางเลือก A (Wave 0 + 1): 4 เดือน, 3 ล้านบาท
• ทางเลือก B (Wave 0-2): 18 เดือน, 12 ล้านบาท
• ทางเลือก C (ครบ 4 Wave): 18-24 เดือน, 19 ล้านบาท

คำแนะนำ: เริ่มจาก Wave 0 + Wave 1 เสมอ แล้วประเมินใหม่หลังเสร็จ — อย่าล็อคแผนระยะยาวตั้งแต่ต้น

---

Volume 16 (Appendices) จะรวบรวม reference material, glossary, และ index