| ณ วันที่ มีปัญหาโปรแกรม การตัดเครดิตใช้งานไม่ได้ แผนก IT ได้ทำการเลือกวิธีการใช้ fallback โดยการ ignored การตรวจสอบการตัด CID เพื่อให้กระบวนการขายเงินเชื่อ สามารถทำงานต่อ ณ ช่วงเวลานั้นได้ และไม่ได้มีการปรับคืนการตรวจสอบ CID และยอดเงิน ณ สิ้นวัน (หลังจากแก้ไขปัญหาแล้ว)
มีผลทำให้ user ที่ ignored ไว้ไม่ได้มีการปรับสถานะคืนจึงสามารถ บันทึกขายเงินเชื่อโดยไม่ได้ตรวจสอบยอดเงินใน CID จึงเกิดปัญหาไม่มีการแจ้งเตือน ดังที่กล่าวมา
| ##### **แก้ไขเบื้องต้น**
\- ปรับ status ให้กลับมาเช็ค CID และยอดเงิน กับ user ทุกคน
... แก้ไขเรียบร้อยแล้ว
#####
การป้องกัน
- ตรวจสอบสาเหตุ ปัญหาการตัด CID
- (api merchant error)
- แก้ไขและเพิ่ม test case พร้อมสร้าง unit test
- ทำ JOB Schedule ในการปรับให้กับพนักงานที่โดนปลดล๊อก และพนักงานใหม่ที่เข้ามา
##### สถานะการป้องกัน
จัดทำ JOB Schedule ตรวจสอบเรียบร้อยแล้ว
[](https://km.nopadol.com/uploads/images/gallery/2025-12/Szj3deqduhA4saUV-image.png)
|
| ##### วิเคราะห์
กรณีนี้เป็น **เคสคลาสสิกของ Distributed System + Human Override + Missing Guardrail**
ผมขอสรุปและแนะนำเป็น **เชิงสถาปัตยกรรม + เชิงกระบวนการ (Process/QA)** แบบจับต้องได้นะครับ
---
##### สรุปปัญหา (Root Cause แบบตรงประเด็น)
**ไม่ใช่ bug ธรรมดา แต่เป็น System Design Gap**
1. ERP *สามารถ bypass credit validation ได้*
2. credit9 down → มีการทำ **manual ignore / exception**
3. **ไม่มีระบบบังคับ revert / auto-heal**
4. การ override ผูกกับ **user-level** → ลืมเปิดกลับ
5. ไม่มี **ระบบตรวจจับความผิดปกติ (Mismatch Detection)**
6. QA ตรวจ feature แต่ **ไม่ได้ test “Failure Mode”**
> 👉 ผลลัพธ์:
>
> - ERP ออกบิลเงินเชื่อ
> - credit9 ไม่ถูกตัด
> - ยอดไม่ตรง → CAR
| ##### แนวคิดหลักที่ควรใช้แก้ (Key Principles)
ผมขอวางกรอบก่อน 5 ข้อนี้ แล้วค่อยลงวิธีปฏิบัติ
1. **Credit validation ต้องเป็น “Hard Gate” ไม่ใช่ Optional**
2. **Override ต้องมีอายุ (TTL) และ Audit**
3. **Failure ต้อง fail-safe (หยุด) ไม่ใช่ fail-open**
4. **ระบบต้อง detect inconsistency เอง**
5. **Human error ต้องถูกกันด้วยระบบ ไม่ใช่ความจำ**
|