Sự cố

Triage và playbook cố định cho các outage thường gặp. Mỗi playbook là triệu chứng → chẩn đoán → giảm thiểu → escalate. Mức độ ở tổng quan runbook.

Luồng triage

1. Xác định phạm vi - một merchant, một service, hay tất cả? Xem dashboard và alert đã bắn.
2. Đặt mức (S0-S3) và, với S0/S1, khai báo sự cố + page Incident Commander.
3. Giảm thiểu trước, root-cause sau - khôi phục service (rollback, restart, scale) trước khi debug.
4. Communicate - cập nhật kênh sự cố mỗi 30 phút tới khi xong.
5. Sau đó - viết post-mortem cho mọi S0/S1.

Playbook

S0 · API chết (service trả 5xx / không truy cập được)

1. Chẩn đoán: kubectl get pods -n nx-backend - pod CrashLooping / không Ready? Xem log (Vận hành).
2. Giảm thiểu: nếu do deploy mới → rollback; nếu không, restart deployment (kubectl rollout restart deploy/<svc>).
3. Kiểm tra deps: xác nhận DB, Redis, gateway khỏe (lỗi downstream trông như outage API).
4. Escalate chủ service nếu 15 phút chưa phục hồi.

S0 · Mất kết nối DB / Postgres chết

1. Chẩn đoán: service tới được Postgres? Kiểm tra pooler (data-layer) và pod DB.
2. Giảm thiểu: restart pooler (PgBouncer / PgCat) trước - nhiều alert "DB chết" là do cạn pooler. Nếu DB thật sự chết, fail over / restore từ backup.
3. Mất dữ liệu? nếu cần restore, theo SOP restore (Vận hành); mục tiêu RPO ≤ 15 phút.
4. Escalate Eng lead ngay (S0).

S0/S1 · Redis chết

1. Ảnh hưởng: cache miss (chậm nhưng vẫn chạy) + worker BullMQ đứng + WebSocket pub/sub rớt.
2. Giảm thiểu: restart Redis; worker tự kết nối lại. Theo dõi backlog queue rút sau đó.
3. Verify: xác nhận job confirmation thanh toán chạy lại (chạy trên Redis) - xem Lỗi thanh toán dưới.

S1 · Lỗi thanh toán (MQ-Pay / VNPAY)

1. Chẩn đoán: IPN có về không? Xem log service payment ở endpoint /payments/vnpay/{provider}/ipn và lỗi verify checksum (Hợp đồng IPN VNPAY).
2. Nguyên nhân thường gặp: Redis chết (job confirmation đứng) · credential merchant sai / đã xoay · không tới được /webhooks/payment nội bộ.
3. Giảm thiểu: confirmation đứng do Redis → fix Redis; credential sai → xoay lại; giao dịch không mất (IPN có thể gửi lại / query lại).
4. Không bao giờ đánh dấu đơn đã thanh toán thủ công khi chưa có IPN verify.

S1 · Lỗi hóa đơn (T-VAN / IIAPI)

1. Chẩn đoán: lỗi ở nhà cung cấp hay ở khâu ký? Xem log service invoice (invoice/integration).
2. Giảm thiểu: phát hành lỗi nhìn thấy và thử lại được - retry từ màn hóa đơn. Không phát lại hóa đơn đã phát thành công (trùng với cơ quan thuế).
3. Escalate chủ thuế / tuân thủ nếu nhà cung cấp / CQT từ chối hóa đơn hợp lệ.

Mẫu post-mortem

# Post-mortem - <sự cố> (<ngày>)
- Mức / thời lượng:
- Ảnh hưởng (ai, bao nhiêu):
- Timeline (phát hiện → giảm thiểu → giải quyết):
- Nguyên nhân gốc:
- Điều tốt / chưa tốt:
- Action item (owner, hạn):

Blameless. Mọi S0/S1 có một bản trong 48 giờ.