# ARISK — Architecture Risk Register & POC Plan — <PROJECT>

| | |
|---|---|
| **Version** | 1.0 |
| **Date** | YYYY-MM-DD |
| **Author** | <SA> (skill sa-1-context) |
| **Status** | 🟡 Draft |
| **Approved by** | Tech Lead: — · PM: — |
| **Source** | CTX_… v1.0 · OPT_… v1.0 |
| **Scope** | |
| **Confidence** | 🟡 |

## Change Log

| Version | Date | Người sửa | Thay đổi |
|---|---|---|---|
| 1.0 | | | Bản đầu |

> 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, không
> đóng vì hết hạn.

---

## 1. Tóm tắt

| Mức | Số lượng | Đã có biện pháp cụ thể | Quá hạn |
|---|---|---|---|
| 🔴 Cao | | | |
| 🟠 Trung bình | | | |
| 🟡 Thấp | | | |

**Ba rủi ro cần chú ý nhất tuần này:** `ARISK-…`, `ARISK-…`, `ARISK-…`

## 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` | | công nghệ mới | | | 🔴 | POC-01 | | | Mở |
| `ARISK-02` | | phụ thuộc ngoài | | | | | | | |

**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)

🔴 **Biện pháp "sẽ theo dõi" không phải biện pháp.** Biện pháp hợp lệ là: POC, spike, đàm phán
hợp đồng, đổi phương án, mua bảo hiểm kỹ thuật (fallback), hoặc **chấp nhận có người ký**.

## 4. Rà sáu nguồn rủi ro *(checklist — mỗi dòng phải trả lời)*

| 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? | | |
| Phụ thuộc ngoài | Bên kia có SLA không? Ta làm gì khi họ hỏng/đổi/ngừng? | | |
| Dữ liệu | Migration có rollback được không? Dữ liệu bẩn tới mức nào? | | |
| Hiệu năng | Con số throughput/latency lấy từ bài đo hay từ suy đoán? | | |
| Con người | Người duy nhất biết hệ thống cũ có còn ở công ty không? | | |
| Chi phí | Khoản nào tăng phi tuyến theo tải? | | |

## 5. Rủi ro đã chấp nhận

*Rủi ro không hạ được và có người ký chấp nhận. Ghi lại để sau này không ai ngạc nhiên.*

| 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 |
|---|---|---|---|---|---|

## 6. Kế hoạch POC

*Mọi `ARISK` 🔴 chưa chứng minh được phải có POC. Tiêu chí pass/fail viết **trước** khi làm —
POC không có tiêu chí trước là POC luôn "thành công".*

### POC-01 — <tên>

| | |
|---|---|
| **Hạ rủi ro** | `ARISK-01` |
| **Câu hỏi cần trả lời** | *(đúng một câu, có thể trả lời bằng số)* |
| **Tiêu chí PASS** | *(số cụ thể, ví dụ: ≥ 500 msg/s với payload 2KB, p99 ≤ 200ms, chạy 30 phút không mất message)* |
| **Tiêu chí FAIL** | *(và khi fail thì làm gì — chuyển sang phương án nào)* |
| **Phạm vi** | *(cái gì KHÔNG làm trong POC — POC không có giới hạn sẽ thành dự án nhỏ)* |
| **Thời lượng tối đa** | … ngày · **dừng khi hết thời lượng dù chưa xong** |
| **Ai làm** | |
| **Môi trường** | *(phải gần production ở điểm nào — cấu hình máy, kích thước dữ liệu, độ trễ mạng)* |

**Kết quả** *(điền sau khi chạy)*

| | |
|---|---|
| **Ngày chạy** | |
| **Kết quả đo** | |
| **PASS / FAIL** | |
| **Điều bất ngờ phát hiện được** | *(thường có giá trị hơn cả kết quả chính)* |
| **Quyết định rút ra** | ⟶ `ADR-nnn` |

🔴 **POC fail vẫn phải ghi lại đầy đủ.** Nó là bằng chứng cho một phương án bị loại ở `OPT` §5,
và nó ngăn người khác đề xuất lại đúng phương án đó sau sáu tháng.

### POC-02 — <tên>

*(cùng cấu trúc)*

## 7. Rủi ro đã đóng

| ID | Rủi ro | Đóng ngày | Bằng chứng |
|---|---|---|---|

## 8. Open Questions

| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|---|---|---|---|---|