ARISK — Architecture Risk Register & POC Plan — e-commerce
|
|
| Version |
1.0 |
| Date |
2026-09-12 |
| Author |
SA (skill sa-1-context, chế độ go, hoạt động cost-risk) |
| Status |
🟡 Draft (duyệt từng phần — xem Approved by; chấp nhận 10 rủi ro ARISK-01…10 (mức, chủ, biện pháp) và 2 kế hoạch POC-01/POC-02 với tiêu chí PASS/FAIL viết trước ở §6; POC chưa chạy — phải xong trước ADR message backbone GĐ2; đây chưa phải AG1 toàn phần, Tech Lead/PM chưa ký thật, OQ-004 còn mở; xem "Tự chấm" §①) |
| Approved by |
PO (uỷ quyền, chế độ chạy thử): Điều phối dự án — duyệt từng phần bản v1.0 · 2026-09-12: chấp nhận 10 rủi ro ARISK-01…10, chủ sở hữu và biện pháp hạ rủi ro tương ứng (§3), và kế hoạch POC-01 (throughput SQS/EventBridge) + POC-02 (RDS gộp tải) với tiêu chí PASS/FAIL viết trước (§6). POC chưa chạy — bắt buộc chạy xong trước khi chốt ADR message backbone GĐ2. Ký thay PO theo ngoại lệ DEC-01 (SA), ghi thêm DEC-10; không phải chữ ký PO/Tech Lead thật — OQ-004 giữ mở. Confidence giữ 🔴; Status giữ 🟡 Draft — AG1 toàn phần vẫn chưa đủ điều kiện. · Tech Lead: — (chưa ký) · PM: — (chưa ký) |
| Source |
01-context/CTX_e-commerce_v1.0.md (v1.2 trong header) §3, §4.2, §4.4, §5 ASM-01…06 · 01-context/OPT_e-commerce_v1.0.md §1, §4, §5, §8 ASM-07…09 · 01-context/TCO_e-commerce_v1.0.md §2, §8 ASM-10…15 · ba-output/e-commerce/01-discovery/RISK_CartCheckout_v1.0.md RISK-01…04, ASM-01…06 (BA — tham chiếu ID, không copy) |
| Scope |
Toàn sàn e-commerce (marketplace đa seller), trọng tâm rủi ro kiến trúc gắn với phương án đã chọn tạm thời P2 (DEC-06) và các rủi ro độc lập với lựa chọn kiến trúc nội bộ (đối tác bên ngoài, pháp lý, ngân sách, năng lực team) |
| Confidence |
🔴 Giả định chưa xác minh — kế thừa nguyên nhân của CTX/OPT/TCO (BA chưa ký G1, AG1 GĐ1 SA chưa từng chạy, ngoại lệ gate DEC-01/03/04/05/07 tiếp tục ở DEC-08). Riêng mức độ (XS/TĐ) của từng ARISK là đánh giá kỹ thuật của SA dựa trên nguồn hiện có — sẽ điều chỉnh khi có xác nhận thật từ Tech Lead/PM/Security |
Change Log
| Version |
Date |
Người sửa |
Thay đổi |
ADR/DEC |
| 1.0 |
2026-09-12 |
SA (qua skill sa-1-context, chế độ go, hoạt động cost-risk) |
Bản đầu — Bước 5 (phần ARISK) của sa-1-context. Lập sổ 10 rủi ro kiến trúc (ARISK-01…10), kế thừa ứng viên từ CTX §4.2/§4.4, OPT ASM-07/08/09, TCO ASM-14, và tham chiếu RISK-01…04/ASM-01…06 của BA bằng ID (không copy nội dung). Lập 2 kế hoạch POC bắt buộc (POC-01 SQS/EventBridge throughput, POC-02 RDS gộp tải) có tiêu chí pass/fail suy từ DRV-04, phải chạy xong trước khi chốt ADR message backbone ở GĐ2 (theo cam kết OQ-012/DEC-06). Tiếp tục ngoại lệ gate DEC-01/03/04/05/07, ghi thêm DEC-08. Confidence 🔴 toàn tài liệu. |
DEC-08 |
| 1.0 |
2026-09-12 |
PO (uỷ quyền, Điều phối dự án) — tác vụ sign/approve |
Duyệt từng phần bản v1.0: chấp nhận 10 rủi ro ARISK-01…10, chủ và biện pháp (§3), và kế hoạch POC-01/POC-02 với tiêu chí PASS/FAIL viết trước (§6). Không đổi nội dung chuyên môn. POC chưa chạy — phải chạy xong trước ADR message backbone GĐ2. Ký thay PO theo ngoại lệ DEC-01 (SA), ghi thêm DEC-10; không phải chữ ký PO/Tech Lead thật — OQ-004 giữ mở, Tech Lead/PM chưa ký. Confidence giữ 🔴. Status giữ 🟡 Draft — AG1 toàn phần chưa đủ điều kiện (xem "Tự chấm" §①). |
DEC-10 |
Sổ này sống suốt dự án, không đóng ở AG1. Mỗi rủi ro chỉ đóng khi có bằng chứng (kết quả
POC, xác nhận hợp đồng, xác nhận bằng văn bản), không đóng vì hết hạn.
0. Ghi chú Preflight & ngoại lệ gate — tiếp nối CTX/OPT/TCO
DEC-08 (SA) — Tiếp tục chạy sa-1-context Bước 5 (phần ARISK) cho e-commerce trong khi
BA vẫn chưa qua G1 và AG1 vẫn chưa từng chạy — tiếp nối DEC-01/03/04/05/07. Người dùng tái
khẳng định muốn tiếp tục.
Quyết định: Tiếp tục, lập sổ ARISK và kế hoạch POC với Confidence 🔴 cho mức độ đánh giá
(xác suất/tác động), cho tới khi Tech Lead/PM xác nhận lại từng dòng.
Người quyết: Điều phối dự án (đại diện PO, dự án chạy thử).
Radar (ước lượng): ~3–4 — cùng lý lẽ như DEC-07.
Hệ quả nếu không chấp nhận ngoại lệ: GĐ1 SA không đủ 4 artifact (CTX/OPT/TCO/ARISK)
để audit AG1 theo đúng yêu cầu "sau lượt này GĐ1 đủ 4 artifact" của ghi chú người duyệt.
1. Tóm tắt
| Mức |
Số lượng |
Đã có biện pháp cụ thể |
Quá hạn |
| 🔴 Cao |
6 (ARISK-01,02,03,05,06,07) |
5/6 (trừ ARISK-07 — chờ OQ-005) |
0 (sổ mới lập) |
| 🟠 Trung bình |
3 (ARISK-04,08,09) |
3/3 |
0 |
| 🟡 Thấp |
1 (ARISK-10) |
1/1 |
0 |
Ba rủi ro cần chú ý nhất tuần này: ARISK-01 (throughput SQS/EventBridge — chặn ADR message
backbone GĐ2 theo OQ-012), ARISK-02 (RDS gộp tải — chặn DAT GĐ2), ARISK-06 (residency
NĐ13/2023 — chặn DAT/INF GĐ2, người phủ quyết muộn nhất theo GUIDE.md).
2. Cách chấm mức
|
Tác động thấp |
Tác động vừa |
Tác động lớn (lệch tiến độ >4 tuần, vượt ngân sách, không đáp ứng DRV Must) |
| Xác suất cao |
🟠 |
🔴 |
🔴 |
| Xác suất vừa |
🟡 |
🟠 |
🔴 |
| Xác suất thấp |
🟡 |
🟡 |
🟠 |
3. Sổ rủi ro
| ID |
Rủi ro |
Nguồn |
XS |
TĐ |
Mức |
Biện pháp hạ rủi ro |
Chủ |
Hạn |
Trạng thái |
ARISK-01 |
SQS/EventBridge (P2, thay Kafka/MSK) chưa được đo throughput thật cho luồng OrderPlaced/PaymentConfirmed ở tải đỉnh flash sale — nếu không đủ, luồng đặt hàng nghẽn đúng lúc doanh thu cao nhất |
Hiệu năng — kế thừa ASM-07 (OPT §8) |
Vừa |
Lớn |
🔴 |
POC-01 (§6) — đo throughput thật trước khi chốt ADR message backbone GĐ2 |
Tech Lead |
Trước ADR message backbone GĐ2 (OQ-012) |
Mở |
ARISK-02 |
1 cụm RDS PostgreSQL chính (schema-per-module, P2) chưa đo tải ghi/đọc gộp cho toàn bộ module ngoại trừ Payment — nếu quá tải, mọi module (Catalog/Cart/Seller/Commission…) cùng bị ảnh hưởng vì chung 1 instance |
Hiệu năng — kế thừa ASM-08 (OPT §8) |
Vừa |
Lớn |
🔴 |
POC-02 (§6) — load test trước khi chốt DAT GĐ2 |
Tech Lead/DBA |
Trước DAT GĐ2 |
Mở |
ARISK-03 |
VNPay/Momo chưa có sandbox/hợp đồng thật; xác nhận thanh toán qua webhook chưa xác minh khả thi gần thời gian thực — đơn hàng có thể kẹt "chờ thanh toán" dù tiền đã thu |
Phụ thuộc ngoài — kế thừa CTX §4.2, RISK-02 (BA), ASM-01 (BA) |
Vừa |
Lớn |
🔴 |
Đàm phán sandbox VNPay/Momo sớm (trước GĐ2 ICD); thiết kế job đối soát bù (reconciliation) — đã có trong SAD.md §3.4, kế thừa nguyên trạng, xác minh lại khi có sandbox thật |
Tech Lead (đàm phán) + PO (ưu tiên lịch) |
Trước GĐ2 kết thúc (ICD) |
Mở |
ARISK-04 |
GHN/GHTK chưa có sandbox/hợp đồng thật; cơ chế fallback chéo (GHN→GHTK) chưa kiểm chứng hoạt động đúng giữa hai API khác nhau |
Phụ thuộc ngoài — kế thừa CTX §4.2, phần liên quan RISK-04 (BA), ASM-02 (BA) |
Vừa |
Vừa |
🟠 |
Xin tài liệu API + sandbox trước GĐ2 ICD; viết integration test riêng cho luồng fallback (đã định hướng ở docs/sections/09-van-hanh-kiem-thu.md §9.1.2 "trọng tâm rủi ro cao") |
Tech Lead |
Trước GĐ2 ICD |
Mở |
ARISK-05 |
Đội thi công thật chưa xác nhận kinh nghiệm production với Kafka/MSK/OpenSearch/EKS (OQ-010) — ảnh hưởng trực tiếp nếu POC-01 fail và phải bổ sung Kafka/MSK cho hot-path (kiến trúc lai theo OPT §1) |
Con người — kế thừa CTX §4.4 |
Cao |
Vừa |
🔴 |
Tech Lead xác nhận năng lực đội thật (OQ-010); nếu thiếu kinh nghiệm — thuê chuyên gia tư vấn ngắn hạn cho riêng giai đoạn triển khai Kafka/MSK nếu POC-01 fail (không phải "sẽ theo dõi") |
Tech Lead |
Trước khi chốt ADR message backbone GĐ2 |
Mở |
ARISK-06 |
Chia sẻ PII (địa chỉ, SĐT người nhận) cho seller khi tách đơn chưa được rà soát theo NĐ13/2023; residency dữ liệu (ap-southeast-1) chưa được đại diện Pháp chế xác nhận |
Tuân thủ — kế thừa CTX ASM-04, RISK-03 (BA), OQ-007 |
Vừa |
Lớn |
🔴 |
PO chỉ định đại diện Pháp chế/Bảo mật (OQ-007); SA chuẩn bị danh sách trường PII chia sẻ cho seller để người đó rà soát trước khi chốt DAT/INF GĐ2 |
PO (chỉ định người) → Legal/Security (rà soát) |
Trước GĐ2 (DAT/INF), chậm nhất trước go-live |
Mở |
ARISK-07 |
Ngân sách vận hành 3 năm thật (TCO §1: 11,2–19,1 tỷ VND tuỳ phương án/kịch bản) chưa được PO/tài chính xác nhận có đủ khả năng chi trả hay không — con số duy nhất PO từng thấy (~3,76 tỷ) chỉ là chi phí xây dựng |
Chi phí — kế thừa CON-01, OQ-005, TCO §1 |
Cao |
Lớn |
🔴 |
Trình TCO đầy đủ (đã lập) cho PO/tài chính; nếu ngân sách thật thấp hơn nhiều, loại bớt cấu phần hạ tầng nặng (đã có phương án P2 rẻ hơn P1 làm phương án dự phòng "cắt giảm") |
PO/tài chính |
Trước khi ký AG1 |
Mở (biện pháp = trình số liệu; chưa có xác nhận ngân sách nên chưa "đã hạ") |
ARISK-08 |
Đội vận hành (Ops/SRE) sau go-live chưa xác nhận nội bộ hay thuê ngoài, quy mô bao nhiêu người (OQ-008) — ảnh hưởng cả khả năng đạt DRV-05 (99.9% uptime) lẫn chi phí TCO (ASM-14, dòng nhạy cảm nhất) |
Con người — kế thừa CON-05/08 |
Vừa |
Vừa |
🟠 |
PM/SRE xác nhận số người thật trước GĐ2 (OQ-008); tạm dùng giả định 2 FTE (ASM-14) làm mốc thiết kế INF/on-call ban đầu, sẽ điều chỉnh khi có số thật |
PM/SRE |
Trước khi chốt INF GĐ2 |
Mở |
ARISK-09 |
Cảnh báo tự động estimate.computed.json.crosscheck: effort WBS (42,48 MM) lệch 54,47% so với UCP (27,5 MM), vượt ngưỡng 25% — dấu hiệu ước lượng effort xây dựng chưa ổn định, có thể ảnh hưởng cả tiến độ lẫn TCO §6 |
Chi phí/ước lượng |
Vừa |
Vừa |
🟠 |
Nhà thầu/PM giải thích chênh lệch tại mục C1 hồ sơ thầu (đã có lý giải sơ bộ: mật độ hạng mục kỹ thuật xuyên suốt cao hơn UCP phản ánh được); Tech Lead xác nhận lại effort WBS-03/05/06 (3 hạng mục XL/high risk) độc lập trước khi ký hợp đồng |
PM/Tech Lead |
Trước khi chốt hợp đồng thi công |
Mở |
ARISK-10 |
Email/SMS Provider và ngân hàng đối tác payout chưa chốt cụ thể (SAD.md §3.4 tự ghi "chưa chốt") — ảnh hưởng cả ICD GĐ2 lẫn TCO §4 (OQ-016) |
Phụ thuộc ngoài |
Thấp |
Vừa |
🟡 |
PO/PM chọn nhà cung cấp cụ thể trước GĐ2 ICD; không chặn Bước 4/5 của GĐ1 vì đây không phải luồng giao dịch lõi (DRV-01) |
PM |
Trước GĐ2 ICD |
Mở |
Trạng thái: Mở · Đang hạ · Đã đóng (kèm bằng chứng) · Đã chấp nhận (kèm ai chấp nhận)
4. Rà sáu nguồn rủi ro (checklist)
| Nguồn |
Câu hỏi |
Trả lời |
Sinh ARISK nào |
| Công nghệ mới |
Có ai trong team từng chạy production cái này chưa? |
Chưa xác nhận cho Kafka/MSK/OpenSearch/EKS (OQ-010); SQS/EventBridge/ECS Fargate là công nghệ managed phổ biến hơn, rủi ro thấp hơn nhưng chưa đo throughput trong ngữ cảnh này |
ARISK-01, ARISK-05 |
| Phụ thuộc bên ngoài |
Bên kia có SLA không? Ta có phương án khi họ hỏng/đổi/ngừng? |
VNPay/Momo/GHN/GHTK: chưa sandbox/hợp đồng thật, chưa có SLA xác nhận; Email/SMS/ngân hàng: chưa chọn nhà cung cấp |
ARISK-03, ARISK-04, ARISK-10 |
| Dữ liệu |
Migration có rollback được không? Dữ liệu bẩn tới mức nào? |
Không áp dụng — greenfield (CTX §4.1), không có dữ liệu cũ để migrate |
(không sinh ARISK — ghi nhận N/A trong "Ngoài phạm vi") |
| Hiệu năng |
Con số throughput/latency lấy từ bài đo hay từ suy đoán? |
Suy đoán/giả định (ASM-07/08 của OPT) — chưa có bài đo thật |
ARISK-01, ARISK-02 |
| Con người |
Người duy nhất biết hệ thống cũ có còn ở công ty không? |
Không áp dụng (greenfield, không có hệ thống cũ); nhưng đội vận hành/thi công thật chưa xác nhận |
ARISK-05, ARISK-08 |
| Chi phí |
Khoản nào tăng phi tuyến theo tải? |
Egress CDN và RDS scale-up (§3 TCO) tăng theo tải nhưng đã mô hình hoá 2 kịch bản; ngân sách 3 năm thật chưa xác nhận đủ hay không |
ARISK-07, ARISK-09 |
5. Rủi ro đã chấp nhận
Chưa có rủi ro nào được chính thức chấp nhận (cần người có thẩm quyền ký) ở lượt chạy này.
ARISK-06 (residency NĐ13/2023) là ứng viên gần nhất nếu Legal/Security sau này xác nhận
ap-southeast-1 đủ đáp ứng — khi đó chuyển dòng này xuống bảng dưới kèm chữ ký thật, không tự
đóng bằng đánh giá của SA (D10).
| ID |
Rủi ro |
Vì sao chấp nhận |
Ai ký · ngày |
Dấu hiệu cảnh báo sớm |
Kế hoạch dự phòng |
| (trống) |
|
|
|
|
|
6. Kế hoạch POC
ARISK-01/ARISK-02 là rủi ro 🔴 chưa chứng minh được — bắt buộc POC theo decision-radar.md §6 (quyết định "kiểu kiến trúc tổng thể"/"đồng bộ hay bất đồng bộ" đạt radar ≥ 8 ở DEC-06
cần POC trước khi ADR GĐ2 chuyển Accepted). Tiêu chí pass/fail viết trước khi làm.
POC-01 — Throughput SQS/EventBridge cho luồng đặt hàng
|
|
| Hạ rủi ro |
ARISK-01 |
| Câu hỏi cần trả lời |
SQS FIFO (per-seller message group) + EventBridge có xử lý được ≥ 100 message/giây bền vững (payload ~2KB, giống OrderPlaced/PaymentConfirmed) mà không mất message và độ trễ chấp nhận được không? |
| Tiêu chí PASS |
Thông lượng sustained ≥ 100 msg/s trong 30 phút liên tục; p99 độ trễ publish→consume ≤ 2 giây; 0 message mất; EventBridge fan-out tới ≥ 5 consumer rule không lag quá 5 giây. (Cơ sở con số: DRV-04 đỉnh ~15.000 đơn/giờ × ~5 event/đơn ≈ 21 event/giây trung bình; thiết kế biên an toàn ×5 cho burst ⇒ ngưỡng 100 msg/s) |
| Tiêu chí FAIL |
Thông lượng sustained < 100 msg/s, hoặc p99 > 2 giây, hoặc có message mất, hoặc lag > 5 giây kéo dài > 5 phút liên tục |
| Phạm vi |
Chỉ đo throughput/latency/độ tin cậy message — không đo chi phí (đã có ở TCO), không đo tích hợp với Payment Service thật (dùng giả lập payload) |
| Thời lượng tối đa |
5 ngày làm việc — dừng khi hết thời lượng dù chưa xong, báo cáo kết quả dở dang |
| Ai làm |
Tech Lead + 1 DevOps |
| Môi trường |
AWS ap-southeast-1 (SQS FIFO + EventBridge thật, không giả lập), payload JSON ~2KB theo schema OrderPlaced dự kiến, load generator k6/artillery |
Kết quả (điền sau khi chạy)
|
|
| Ngày chạy |
(chưa chạy — theo OQ-012, POC phải xong trước ADR message backbone GĐ2) |
| Kết quả đo |
— |
| PASS / FAIL |
— |
| Điều bất ngờ phát hiện được |
— |
| Quyết định rút ra |
⟶ sẽ tham chiếu ADR message backbone GĐ2 (sa-2-architecture) |
POC-02 — RDS PostgreSQL gộp chịu tải ghi/đọc kết hợp (P2)
|
|
| Hạ rủi ro |
ARISK-02 |
| Câu hỏi cần trả lời |
1 cụm RDS chính (giả định db.r6g.xlarge Multi-AZ, TCO §3.2) có đáp ứng đủ tải ghi (checkout) + đọc (catalog) gộp cho các module ngoài Payment ở tải đỉnh flash sale không? |
| Tiêu chí PASS |
Đồng thời ~15.000 đơn/giờ (ghi) + ~150.000 truy vấn catalog/giờ (đọc, ước ×10 tải ghi) trong 30 phút liên tục: p95 write latency (checkout) ≤ 300ms, p95 read latency (catalog) ≤ 200ms (khớp NFR-01 của docs/sections/09 §9.1.4), CPU RDS < 75%, connection pool không bị exhaust |
| Tiêu chí FAIL |
Vượt một trong các ngưỡng trên, hoặc xuất hiện lỗi connection/timeout do exhaust pool |
| Phạm vi |
Chỉ đo tải DB gộp — không đo chịu lỗi/failover (đã có kịch bản chaos riêng ở docs/sections/09 §9.1.4 NFR-03, thuộc GĐ3) |
| Thời lượng tối đa |
5 ngày làm việc |
| Ai làm |
Tech Lead/DBA |
| Môi trường |
Staging cấu hình instance class thật (db.r6g.xlarge Multi-AZ), dataset synthetic quy mô tương đương Năm 1 (TCO §2 kịch bản A: ~50GB, 300.000 SKU) |
Kết quả (điền sau khi chạy)
|
|
| Ngày chạy |
(chưa chạy — cần trước khi chốt DAT GĐ2) |
| Kết quả đo |
— |
| PASS / FAIL |
— |
| Điều bất ngờ phát hiện được |
— |
| Quyết định rút ra |
⟶ sẽ tham chiếu DAT/ADR liên quan ở GĐ2 |
🔴 POC fail vẫn phải ghi lại đầy đủ — nếu POC-01 fail: bổ sung Kafka/MSK riêng cho hot-path
đặt hàng (kiến trúc lai, theo điều kiện đã nêu ở OPT §1), không chuyển hẳn sang P1. Nếu
POC-02 fail: tách read replica/DB riêng cho Catalog/Search sớm hơn dự kiến, cập nhật TCO
(chi phí hạ tầng P2 tăng, tiệm cận P1 cho phần đó — đã cảnh báo ở TCO §3.3 cuối).
7. Rủi ro đã đóng
| ID |
Rủi ro |
Đóng ngày |
Bằng chứng |
| (chưa có — sổ mới lập) |
|
|
|
8. Open Questions
| ID |
Câu hỏi |
Hỏi ai |
Từ ngày |
Chặn gì |
OQ-013 |
Xác nhận đơn giá AWS ap-southeast-1 ước tính ở TCO §3.1 (ASM-11) bằng AWS Pricing Calculator thật hoặc báo giá đại lý AWS tại VN — chênh lệch bao nhiêu so với ước tính? |
Tech Lead/DevOps + tài chính |
2026-09-12 |
Độ tin cậy TCO toàn bộ; ngân sách hạ tầng INF GĐ2 phải khớp (D9) |
OQ-014 |
Biểu phí giao dịch VNPay/Momo thật (theo % hay phí cố định) và GMV (tổng giá trị giao dịch) dự kiến năm 1 là bao nhiêu, để tính NL-03 trong TCO? |
PO/tài chính + đàm phán với VNPay/Momo |
2026-09-12 |
TCO §4 (hiện chưa tính được khoản này) |
OQ-015 |
Biểu phí API GHN/GHTK theo hợp đồng thật là bao nhiêu (NL-05)? |
PM (đàm phán hợp đồng vận chuyển) |
2026-09-12 |
TCO §4, ARISK-04 |
OQ-016 |
Nhà cung cấp Email/SMS cụ thể (SES/SNS hay SendGrid/Twilio hay nhà cung cấp nội địa) là gì, biểu phí bao nhiêu (NL-04)? |
PM/Tech Lead |
2026-09-12 |
TCO §4, ARISK-10, ICD GĐ2 |
OQ-017 |
Báo giá pentest ứng dụng hàng năm + ASV scan hàng quý (phạm vi PCI-DSS SAQ A) từ nhà cung cấp thật là bao nhiêu (NL-07)? |
PO/Security (khi có người) |
2026-09-12 |
TCO §4 |
Nhắc: cùng với OQ-005/006/007/008/010/011/012 (còn mở, xem 00-index/OQ_e-commerce.md),
năm câu hỏi mới ở trên hoàn thiện bức tranh input còn thiếu cho TCO/ARISK. Sau lượt này, GĐ1
SA đã đủ 4 artifact (CTX/OPT/TCO/ARISK) để audit AG1 — nhưng tự chấm cho thấy AG1
vẫn chưa đủ điều kiện ký chính thức (xem Tự chấm ở cuối mỗi artifact); cần PO + Tech Lead xử
lý các OQ chặn trước khi ký.
Tự chấm
① Bảng tự chấm Gate AG1 (workflow.md §2, cập nhật cuối cùng của GĐ1)
| # |
Tiêu chí |
☐/✅ |
Ghi chú |
| 1 |
CTX có DRV-nn |
✅ |
CTX §2 |
| 2 |
CTX có CON-nn |
✅ (với lưu ý) |
CTX §3 |
| 3 |
CTX mô tả hiện trạng as-is |
✅ (với lưu ý) |
CTX §4 |
| 4 |
OPT có ≥2 phương án, chấm điểm, nêu phương án bị loại |
✅ |
OPT §4/§5 |
| 5 |
TCO có chi phí 3 năm, ≥2 kịch bản tải |
✅ |
TCO_e-commerce_v1.0.md toàn bộ |
| 6 |
ARISK có rủi ro cao kèm chủ + biện pháp |
✅ |
§3 — ARISK-01,02,03,05,06,07 mức 🔴, mỗi cái có chủ + biện pháp cụ thể (POC, đàm phán sandbox, chỉ định người rà soát pháp lý) — không có biện pháp "sẽ theo dõi" |
| 7 |
Rủi ro cao chưa chứng minh được có kế hoạch POC |
✅ |
§6 — POC-01 (SQS/EventBridge), POC-02 (RDS gộp tải), mỗi cái có tiêu chí PASS/FAIL viết trước khi làm, thời lượng tối đa, ai làm, môi trường |
Kết luận tự chấm AG1 (toàn GĐ1): 7/7 tiêu chí đủ về cấu trúc — GĐ1 SA hoàn tất đủ 4
artifact bắt buộc (CTX, OPT, TCO, ARISK) theo đúng artifact-map.md. Vẫn chưa đủ điều
kiện để PO + Tech Lead ký AG1 chính thức vì: (a) BA chưa ký G1 thật cho BRIEF_CartCheckout
(OQ-001 còn mở); (b) nhiều con số nền (CON-01/02/05, đơn giá AWS, đội vận hành) vẫn ở mức
🔴 giả định/tham khảo, chưa được PO/PM/Tech Lead xác nhận bằng số thật; (c) hai POC bắt buộc
(POC-01, POC-02) chưa chạy — chỉ mới có kế hoạch. Khuyến nghị trình tự trước khi ký:
(1) PO/PM trả lời OQ-005 (ngân sách) và OQ-008 (đội vận hành) bằng số thật; (2) Tech Lead trả
lời OQ-010 (năng lực team); (3) chạy POC-01/POC-02, cập nhật kết quả vào ARISK §6; (4) khi
đó AG1 mới có đủ bằng chứng để ký thay vì "trông hợp lý" (đúng tinh thần workflow.md §2: "Gate
kiến trúc khác gate BA ở một điểm: không ký được bằng trông hợp lý").
② Checklist D1–D12 (design-rules.md)
| # |
Mục |
☐/✅ |
Ghi chú |
| D1 |
Một ADR một quyết định |
N/A |
Không có ADR trong tài liệu này |
| D2 |
Không NFR định tính |
N/A |
Không chứa QAS |
| D3 |
Nêu phương án bị loại + lý do |
N/A |
Không áp dụng cho sổ rủi ro (đã có ở OPT §5) |
| D4 |
Sơ đồ khai báo mức + legend |
N/A |
Không có sơ đồ mới |
| D5 |
Interface có chủ/contract |
N/A |
Chưa tới ICD |
| D6 |
Phụ thuộc ngoài process có timeout/retry |
🟡 Một phần |
§3 ARISK-03/04 kế thừa nguyên trạng timeout/retry đề xuất từ SAD.md §3.4 (VNPay/Momo 10s, GHN/GHTK 8s) — chưa kiểm chứng sandbox thật, ghi rõ trạng thái |
| D7 |
Một chủ sở hữu dữ liệu |
N/A |
Chưa tới DAT |
| D8 |
Ràng buộc có FIT hoặc nhãn khuyến nghị |
N/A |
Chưa tới AGD/FIT |
| D9 |
Con số hạ tầng quy ra tiền + nguồn |
N/A |
Đã xử lý ở TCO; ARISK không lặp lại con số |
| D10 |
Không quyết định thay người có thẩm quyền |
✅ |
Mọi rủi ro cần quyết định của PO/Security (ngân sách, chấp nhận rủi ro residency) đều ghi ở dạng ARISK + OQ kèm biện pháp đề xuất, không tự chấp nhận thay (§5 "Rủi ro đã chấp nhận" còn trống — đúng, vì chưa ai ký) |
| D11 |
Có mục "Ngoài phạm vi" + ASM-nn |
✅ (tham chiếu) |
Không tạo ASM mới riêng — tham chiếu ASM-04/07/08 (CTX/OPT) và ASM-10…15 (TCO) theo đúng nguyên tắc "không copy, chỉ tham chiếu ID" (artifact-map.md §7); mục dữ liệu/migration ghi rõ N/A ở §4 (greenfield) |
| D12 |
Câu quy định thẩm quyền sơ đồ vs văn bản |
☐ |
(Thiếu — sổ rủi ro dạng bảng, không có sơ đồ, nên không bắt buộc câu này; ghi nhận để nhất quán với các artifact khác nếu cần) |
③ Danh sách OQ mở kèm người phải trả lời, chặn gì
Xem bảng đầy đủ §8 (OQ-013…017, mới) cộng sổ 00-index/OQ_e-commerce.md (OQ-001, 003, 004, 005, 006, 007, 008, 010, 012 còn mở). Hai câu chặn trực tiếp việc chạy POC: OQ-010
(năng lực team — ảnh hưởng quyết định có cần POC-01 hay không nếu team đã có kinh nghiệm) và
OQ-012 (đã đóng có điều kiện — POC phải chạy trước ADR message backbone GĐ2, xem DEC-06).
Nhắc cuối GĐ1: AG1 cần PO + Tech Lead ký (điền Approved by vào header OPT, xem
workflow.md §2) trước khi chạy /sa-2-architecture. Bốn điều kiện ra khỏi GĐ1 theo GUIDE.md:
(1) bảng tự chấm AG1 toàn ✅ (đạt về cấu trúc, chưa đạt về nội dung đã xác nhận); (2) PO và
Tech Lead điền Approved by thật vào OPT (chưa — vẫn là ký thay theo ngoại lệ); (3) mọi
ARISK mức cao có chủ + biện pháp cụ thể (đạt); (4) POC-01/POC-02 đã chạy xong, kết quả
ghi vào ARISK (chưa — mới có kế hoạch). Còn thiếu (2) và (4) trước khi coi AG1 là qua thật.
