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