235 lines
26 KiB
Markdown
235 lines
26 KiB
Markdown
# 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.
|