ARISK — Architecture Risk Register & POC Plan —
|
|
| Version |
1.0 |
| Date |
YYYY-MM-DD |
| Author |
(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ì |
