Files
Leonard-ThindPad-P50 c81f249920 init git
2026-09-08 10:26:21 +07:00

117 lines
4.5 KiB
Markdown

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