174 lines
6.5 KiB
Markdown
174 lines
6.5 KiB
Markdown
# PMR — Architecture Review / Post-mortem — <PROJECT>
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Loại** | 🔄 Đánh giá định kỳ *(ATAM rút gọn)* / 🚨 Post-mortem sau sự cố |
|
|
| **Version** | 1.0 |
|
|
| **Date** | YYYY-MM-DD |
|
|
| **Author** | <SA> (skill sa-4-evolution) |
|
|
| **Status** | 🟡 Draft |
|
|
| **Approved by** | Tech Lead: — · EA: — |
|
|
| **Source** | CONF_… · QAS_… · ADR-… · log sự cố … |
|
|
| **Scope** | Kỳ … / Sự cố `INC-…` |
|
|
| **Confidence** | 🟢 |
|
|
|
|
## Change Log
|
|
|
|
| Version | Date | Người sửa | Thay đổi |
|
|
|---|---|---|---|
|
|
| 1.0 | | | Bản đầu |
|
|
|
|
---
|
|
|
|
# CHẾ ĐỘ A — Đánh giá định kỳ (ATAM rút gọn)
|
|
|
|
*Dùng mỗi quý. Xoá phần B nếu dùng chế độ này.*
|
|
|
|
## A1. `QAS` còn đúng không
|
|
|
|
*Nhu cầu đổi thì thuộc tính chất lượng cũng đổi. `QAS` viết một năm trước có thể đang bảo vệ
|
|
thứ không ai cần nữa.*
|
|
|
|
| `QAS` | Còn đúng | Lý do | Hành động |
|
|
|---|---|---|---|
|
|
| `QAS-001` | ✅ | | |
|
|
| `QAS-006` | ❌ thừa | Tính năng đã bỏ | Đánh dấu `[DROPPED]`, giữ ID |
|
|
| — | ❌ thiếu | Nhu cầu mới: … | Thêm `QAS-nnn` |
|
|
|
|
## A2. Điểm nhạy cảm
|
|
|
|
*Chỗ một thay đổi nhỏ làm một thuộc tính chất lượng đổi nhiều. Đây là chỗ phải cẩn thận nhất
|
|
khi sửa, và là chỗ phải có `FIT` bảo vệ.*
|
|
|
|
| # | Điểm | Thuộc tính bị ảnh hưởng | Thay đổi nhỏ nào cũng gây tác động lớn | Có `FIT` bảo vệ |
|
|
|---|---|---|---|---|
|
|
| 1 | | `QAS-nnn` | | ☐ |
|
|
|
|
## A3. Điểm đánh đổi
|
|
|
|
*Chỗ cải thiện thuộc tính này làm hỏng thuộc tính kia. Phải được nói ra để người sau không
|
|
"tối ưu" một chiều rồi phá chiều còn lại.*
|
|
|
|
| # | Điểm | Cải thiện | Đánh đổi bằng | Cân bằng hiện tại | Ai quyết |
|
|
|---|---|---|---|---|---|
|
|
| 1 | | `QAS-nnn` | `QAS-nnn` | | PO |
|
|
|
|
## A4. `ADR` chạm điều kiện xét lại
|
|
|
|
| `ADR` | Điều kiện (§7 của ADR) | Ngưỡng | Thực tế | Chạm chưa | Hành động |
|
|
|---|---|---|---|---|---|
|
|
|
|
## A5. Rủi ro mới
|
|
|
|
| Nguồn | Rủi ro | Mức | Hành động | `ARISK` |
|
|
|---|---|---|---|---|
|
|
| Vendor | *(đổi giá, đổi điều khoản, ngừng dịch vụ)* | | | |
|
|
| Vòng đời công nghệ | *(phiên bản hết hỗ trợ, thư viện ngừng bảo trì)* | | | |
|
|
| Tuân thủ | *(luật mới, chuẩn kiểm toán mới)* | | | |
|
|
| Nhân sự | *(người duy nhất biết một phần hệ thống)* | | | |
|
|
| Quy mô | *(tải sắp vượt ngưỡng thiết kế)* | | | |
|
|
|
|
## A6. Kết luận định kỳ
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Kiến trúc còn phù hợp không** | ✅ còn / ⚠️ còn nhưng có điểm phải xử lý / ❌ cần vòng thiết kế mới |
|
|
| **Ba việc quan trọng nhất** | ⟶ `TRM` |
|
|
| **Có cần mở vòng `sa-1-context` mới không** | ☐ · vì sao |
|
|
|
|
---
|
|
|
|
# CHẾ ĐỘ B — Post-mortem kiến trúc sau sự cố
|
|
|
|
*Chỉ cho sự cố có nguyên nhân kiến trúc. Post-mortem vận hành (dòng thời gian, cách xử lý,
|
|
hành động khắc phục ngay) thuộc SRE — tài liệu này không lặp lại phần đó. Xoá phần A nếu dùng
|
|
chế độ này.*
|
|
|
|
## B1. Tham chiếu
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Sự cố** | `INC-…` |
|
|
| **Post-mortem vận hành** | *(đường dẫn — đọc trước tài liệu này)* |
|
|
| **Ảnh hưởng** | … phút · … người dùng · … giao dịch |
|
|
| **Ngân sách lỗi tiêu tốn** | … / … phút của tháng |
|
|
|
|
## B2. Ba câu hỏi kiến trúc
|
|
|
|
> 🔴 **Không đổ lỗi cho người.** "Dev quên đặt timeout" là triệu chứng. Câu hỏi kiến trúc là
|
|
> "vì sao hệ thống cho phép một lời gọi không timeout tồn tại, và làm sao để lần sau không
|
|
> thể". Câu trả lời thường là một `FIT` mới, không phải một lời nhắc nhở.
|
|
|
|
### Câu 1 — Kiến trúc đã CHO PHÉP sự cố này ở chỗ nào
|
|
|
|
| Điều kiện cho phép | Ở đâu | Có trong thiết kế không |
|
|
|---|---|---|
|
|
| | `SAD` §… / `FAIL` `FM-nn` / không có ở đâu cả | |
|
|
|
|
### Câu 2 — Thiết kế đã dự đoán tình huống này chưa
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Có trong `FAIL` không** | ☐ có (`FM-nn`) — vậy vì sao biện pháp không hiệu lực? · ☐ không — đây là điểm mù |
|
|
| **Có `QAS` liên quan không** | |
|
|
| **Có `ASM` nào sai không** | `ASM-nn`: … |
|
|
|
|
**Nếu ĐÃ có trong thiết kế mà vẫn xảy ra** — vấn đề nằm ở một trong ba:
|
|
|
|
| | Kiểm |
|
|
|---|---|
|
|
| Biện pháp không được cài đặt | ☐ |
|
|
| Cài đặt nhưng tham số sai *(timeout, ngưỡng)* | ☐ |
|
|
| Cài đặt đúng nhưng không đủ *(giả định về quy mô sai)* | ☐ |
|
|
|
|
### Câu 3 — Sửa ở tầng nào
|
|
|
|
| Tầng | Sửa gì | Ngăn được lần sau | Chi phí | Chọn |
|
|
|---|---|---|---|---|
|
|
| Code | | chỉ chỗ này | | ☐ |
|
|
| Cấu hình | | chỉ chỗ này | | ☐ |
|
|
| **Kiến trúc** | | cả lớp vấn đề | | ☐ |
|
|
| Quy trình / bài kiểm tự động | | cả lớp vấn đề, không phụ thuộc trí nhớ | | ☐ |
|
|
|
|
🔴 **Sửa ở tầng code chỉ ngăn được đúng lần này.** Hỏi thêm: *"Còn bao nhiêu chỗ khác trong hệ
|
|
thống có cùng vấn đề?"* — nếu > 1 thì phải sửa ở tầng kiến trúc hoặc bài kiểm.
|
|
|
|
## B3. Chỗ khác có cùng vấn đề
|
|
|
|
| Chỗ | Đã kiểm | Có cùng vấn đề | Xử lý |
|
|
|---|---|---|---|
|
|
|
|
## B4. Hành động
|
|
|
|
| # | Hành động | Tầng | Chủ | Hạn | Ngăn được gì | Ghi ở đâu |
|
|
|---|---|---|---|---|---|---|
|
|
| 1 | | `FIT` mới | | | cả lớp lỗi này | `FIT-nn` |
|
|
| 2 | | `ADR` mới | | | | `ADR-nnn` |
|
|
| 3 | | cập nhật `FAIL` | | | | `FM-nn` |
|
|
|
|
## B5. Cập nhật tài liệu
|
|
|
|
| Tài liệu | Cập nhật gì | Đã làm |
|
|
|---|---|---|
|
|
| `FAIL` | Thêm `FM-nn` cho tình huống này | ☐ |
|
|
| `QAS` | Thêm `QAS-nnn` về thời gian phát hiện | ☐ |
|
|
| `ADR-nnn` | Bổ sung hệ quả chưa lường trước vào §5 | ☐ |
|
|
| `ASM` | Sửa giả định sai, rà mọi thứ dựa trên nó | ☐ |
|
|
| `AGD` | Thêm ràng buộc | ☐ |
|
|
|
|
*Không sửa quyết định trong `ADR` cũ — chỉ bổ sung hệ quả quan sát được. Quyết định sai ⇒ ADR
|
|
mới có `Supersedes:`.*
|
|
|
|
---
|
|
|
|
## Bài học *(cả hai chế độ)*
|
|
|
|
| Bài học | Áp dụng vào | Ai chịu trách nhiệm |
|
|
|---|---|---|
|
|
| | dự án này / dự án sau / chuẩn chung của tổ chức | |
|
|
|
|
## Open Questions
|
|
|
|
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|
|
|---|---|---|---|---|
|