15.3 · Scorecard — Infrastructure debt
รายการนี้ tag INFRA — ใช้ prefix LEG- สำหรับ EOL runtime/dependency และ OBS- สำหรับ missing health check/monitoring เป็นหลัก ตาม scope ที่กำหนด
Severity: Critical
LEG-INFRA-01 · Node runtime EOL ที่ยัง build เป็น production image — 5 repo
ที่ — cu-central-api (node:12.18.3, EOL เมษายน 2022, cu-central-api/01-repository-map-bootstrap), 2way-api build stage (node:16-alpine, EOL เมษายน 2024, 2way-api/index), 2way-batch (node:16-alpine, 2way-batch/index), job-scheduler-api (node:16-alpine, job-scheduler-api/index), ai-recruitment-api (node:18-alpine, EOL เมษายน 2025 — ใกล้ EOL ที่สุดในกลุ่มนี้แต่ยังไม่ EOL ณ วันที่เขียนเอกสาร)
ผลกระทบ — image ที่ build จาก base ที่ EOL แล้วไม่ได้รับ security patch จาก upstream อีกต่อไป — cu-central-api (node 12) รันโค้ดที่เข้าถึง LDAP/AD และ HRMI database โดยตรง เป็น attack surface ที่สำคัญที่สุดในกลุ่มนี้เพราะยังไม่มี patch ให้ CVE ที่ค้นพบใหม่ในปีนี้เลย
Severity: High
OBS-INFRA-01 · ไม่มี health check endpoint ที่ยืนยันได้ใน 15+ repo
ที่ — benefit-api (@nestjs/terminus import แต่ไม่พบ HealthController ที่ใช้จริง, benefit-api/06-scorecard OBS-BENEFIT-02) — pattern เดียวกันไม่ได้ยืนยันแยกทุก repo ในรอบสำรวจนี้ แต่ไม่มี repo ใดใน Domain Microservices/2way Platform ที่ยืนยัน dedicated health-check endpoint ที่ผูกกับ dependency จริง (DB connection, external API)
ผลกระทบ — container orchestration (Docker Compose restart policy, หรือ manual monitoring) ไม่มีทางรู้ว่า service "ตายจริง" (DB connection หลุด, dependency ล่ม) หรือแค่ process ยังรันอยู่แต่ตอบ error ทุก request — ต้องพึ่งการสังเกตจาก log หรือผู้ใช้ report เท่านั้น
OBS-INFRA-02 · Docker Compose ที่ join network ภายนอกแบบ implicit dependency
ที่ — job-scheduler-api/docker-compose.yml:18-22 join network ชื่อ vtrc-api_default ที่ประกาศเป็น external: true (job-scheduler-api/index)
ผลกระทบ — job-scheduler-api จะ deploy ไม่ได้เลยถ้า vtrc-api's docker-compose stack ไม่ได้ up มาก่อนบน host เดียวกัน (สร้าง network ชื่อนี้ไว้) — เป็น implicit dependency ที่ไม่ปรากฏชัดถ้าดูแค่ job-scheduler-api repo ตัวเดียว ทีมใหม่ที่พยายาม deploy repo นี้แยกจะเจอ error ที่ไม่ชัดเจนว่าต้องแก้ที่ repo อื่น
LEG-INFRA-02 · pms-api build ไม่ pin lockfile — เสี่ยง version drift ระหว่าง build
ที่ — pms-api/Dockerfile (branch: uat):19 ใช้ yarn install โดยไม่มี --frozen-lockfile ต่างจาก benefit-api/recruitment-api ที่ pin (pms-api/index)
ผลกระทบ — ถ้า yarn.lock ไม่ sync กับ package.json (เช่น มีคน edit package.json มือแล้วลืมรัน yarn install ในเครื่อง dev) การ build image ครั้งถัดไปจะได้ dependency version ที่ต่างจากที่ test ไว้ — ความเสี่ยงเพิ่มขึ้นเพราะ pms-api เป็น repo ที่ active ที่สุด (33 module, 1909 commits)
Severity: Medium
QUAL-INFRA-01 · Deploy artifact ไม่มีอยู่จริงใน 3 repo ที่อาจ active ในการใช้งาน
ที่ — sso-api (ไม่มี Dockerfile/compose/.env เลย, sso-api/index), vtrc-ocr-api (ไม่มี deploy artifact ใด, repo อยู่สถานะ scaffold, vtrc-ocr-api/index), meeting-vtrc-api (ไม่มี Dockerfile แยก มีแค่ docker-compose build จาก context ตรง, meeting-vtrc-api/index)
ผลกระทบ — ไม่กระทบ vtrc-ocr-api เพราะยืนยันแล้วว่ายังไม่มี business logic จริง (OCR endpoint คืนค่า mock เสมอ) แต่ sso-api และ meeting-vtrc-api เป็น service ที่ดูมีความตั้งใจ deploy จริง — การไม่มี Dockerfile ที่ตรวจสอบได้ทำให้ประเมินความปลอดภัย/reproducibility ของ deploy pipeline ไม่ได้เต็มที่
QUAL-INFRA-02 · ไม่มี infra-as-code (Terraform/Helm/K8s manifest) ในทั้งแพลตฟอร์ม
ที่ — ตรวจสอบทั้ง 25 repo แล้วไม่พบไฟล์ Kubernetes manifest, Helm chart, หรือ Terraform configuration ใดเลย (15.1 Deployment inventory)
ผลกระทบ — infrastructure provisioning ทั้งหมด (VM, network, DNS) ไม่มีหลักฐานว่า reproducible จาก code — ถ้าต้อง disaster-recovery หรือ spin up environment ใหม่ ต้องพึ่งความรู้ tacit ของทีม infra ที่ไม่ได้ document เป็นโค้ด
QUAL-INFRA-03 · Base image ไม่สอดคล้องกันในกลุ่มเดียวกัน
ที่ — Domain Microservices group ใช้ base image ต่างกันถึง 4 เวอร์ชัน: node:16-alpine (job-scheduler-api), node:18-alpine (ai-recruitment-api, chat-center-api, vtrc-common), node:20-alpine (benefit-api, recruitment-api, pms-api), node:22-alpine (workflow-api) — ดู 15.1.4
ผลกระทบ — ไม่มี base image policy กลางที่บังคับใช้ทุก repo ในกลุ่มเดียวกัน แต่ละทีมเลือกเวอร์ชันตอนที่ scaffold repo แล้วไม่มี upgrade cadence ที่ sync กัน — เพิ่ม maintenance surface (ต้อง patch/test แต่ละเวอร์ชันแยกกัน)
สรุป — คะแนนรวม
| Severity | จำนวน |
|---|---|
| Critical | 1 |
| High | 3 |
| Medium | 3 |
Modernization — ลำดับ ROI
- Upgrade
cu-central-apiออกจากnode:12.18.3(LEG-INFRA-01) — ทำก่อนอย่างอื่นเพราะกระทบ LDAP/HRMI access โดยตรง และ EOL มานานที่สุด (4+ ปี) - Upgrade
2way-api/2way-batch/job-scheduler-apiออกจากnode:16-alpine(LEG-INFRA-01) — ทำต่อเนื่องเพราะ EOL แล้วเช่นกัน - เพิ่ม
--frozen-lockfileให้pms-apiDockerfile (LEG-INFRA-02) — quick win 1 บรรทัด - เพิ่ม dedicated health-check endpoint ที่เช็ค dependency จริง (
OBS-INFRA-01) — เริ่มจาก service ที่มี@nestjs/terminusอยู่แล้วแค่ไม่ได้ wire (benefit-api) - ย้าย implicit network dependency ของ
job-scheduler-apiให้ explicit ใน documentation (OBS-INFRA-02) — งาน documentation ล้วน ไม่กระทบโค้ด - สร้าง Dockerfile ให้
sso-api/meeting-vtrc-apiที่ยืนยันได้ (QUAL-INFRA-01) — ต้องคุยกับทีมที่ดูแลจริงก่อนว่า deploy ปัจจุบันทำอย่างไร - ตั้ง base image policy กลาง + evaluate infra-as-code (
QUAL-INFRA-02,QUAL-INFRA-03) — งานระยะยาวที่ต้อง buy-in จากทุกทีม
ไป กลับสู่ Volume 15 index หรือ Volume 16 · Operational Runbooks