Bộ biểu mẫu SA

00Chọn đúng biểu mẫu

Không phải quyết định nào cũng cần dùng tất cả biểu mẫu. Chọn mẫu theo câu hỏi cần trả lời, sau đó liên kết các hiện vật liên quan.

Trường quản trị dùng chung

Mọi biểu mẫu có quyết định hoặc hành động theo dõi nên có tối thiểu:

• Owner: người chịu trách nhiệm cập nhật hoặc thực hiện.
• Status: Draft · In review · Accepted · Blocked · Superseded.
• Review date: ngày xem lại hoặc điều kiện kích hoạt review lại.
• Assumption: giả định đang dùng để ra quyết định.
• Risk: điều có thể làm quyết định sai hoặc gây tác động xấu.
• Evidence: số liệu, test, log, tài liệu hoặc người xác nhận.

Liên kết với rubric và checklist review

01ADR — Architecture Decision Record

Một trang. Viết trong 30 phút. Nếu mất hơn 1 giờ thì đang viết HLD, không phải ADR.

# ADR-{số} — {Tiêu đề quyết định, dạng động từ}

Trạng thái:  Đề xuất | Đã chấp nhận | Đã thay thế bởi ADR-XX
Ngày:        YYYY-MM-DD
Người quyết: {tên}        Người tham vấn: {tên}
Dự án:       {mã dự án}

## Bối cảnh
Vấn đề gì đang cần quyết. Ràng buộc nào đang có hiệu lực
(thời gian, ngân sách, năng lực đội ngũ, ràng buộc kỹ thuật).
Con số liên quan nếu có.

## Các phương án đã cân nhắc
1. {Phương án A} — ưu / nhược
2. {Phương án B} — ưu / nhược
3. {Phương án C} — ưu / nhược

## Quyết định
Chọn phương án {X}.

## Vì sao loại các phương án khác        ← PHẦN QUAN TRỌNG NHẤT
{Lý do cụ thể, gắn với ràng buộc ở phần Bối cảnh.}

## Hệ quả
Tích cực:  {...}
Tiêu cực:  {...}
Nợ kỹ thuật chấp nhận: {có / không — nếu có, điều kiện trả nợ là gì}

## Khả năng đảo ngược
Type 1 (khó đảo ngược, chi phí cao) | Type 2 (đảo ngược được)
Nếu Type 1: điều gì phải đúng để quyết định này còn giá trị sau 18 tháng?

## Cần xem lại khi
{Điều kiện kích hoạt việc xem lại quyết định này.}

02NFR Specification — bảng ràng buộc phi chức năng

Điền cùng lúc với BRD sign-off. Mọi ô "chưa xác định" là một rủi ro cần ghi vào Risk Register.

03Napkin Math Card — in ra, dán bàn

RAM                    ~100 ns
1 MB tuần tự từ RAM     ~10 µs
SSD random read        ~100 µs
1 MB tuần tự từ SSD      ~1 ms
Round-trip cùng DC     ~0.5 ms   ★
Query có index, cached 0.1–1 ms
HN ↔ HCM                ~30 ms
VN ↔ Singapore          ~40 ms
VN ↔ US East           ~230 ms
Ngưỡng "tức thì"       <100 ms

1 ngày        ≈ 86.400 s ≈ 100.000 s
1 triệu/ngày  ≈ 10/s
5 triệu/ngày  ≈ 58/s
100 triệu/ngày ≈ 1.150/s
Hệ số đỉnh thường     5–10×
Đỉnh chiến dịch      30–100×

Postgres write đơn giản  vài nghìn/s
Postgres read có index   chục nghìn/s
Redis                    ~100k ops/s
Kafka 1 broker           trăm nghìn/s
App node, không DB       vài nghìn req/s
App node, 2–3 query DB   vài trăm req/s
1 triệu bản ghi × 1 KB   ≈ 1 GB

Little's Law
  Concurrency = Throughput × Latency
  500/s × 0,2 s = 100 connection

Tail latency (fan-out N service)
  P(chậm) = 1 − (1 − p)^N
  10 service, p99 → ~9,6% request chậm

Saturation
  >70–80% → latency tăng phi tuyến

SLO → thời gian lỗi/tháng
  99%    = 7,2 giờ
  99,9%  = 43 phút
  99,99% = 4,3 phút

04Integration Contract — mẫu tối thiểu

# Integration Contract: {Hệ thống A} → {Hệ thống B}

Phiên bản:        v1.0
Chủ sở hữu A:     {tên, team}
Chủ sở hữu B:     {tên, team}
Nguồn sự thật:    {A hay B — bắt buộc điền}

## Cơ chế
Kiểu:      sync REST | async event | batch file | CDC
Lý do chọn: {...}

## Hợp đồng dữ liệu
Schema:    {link hoặc mô tả}
Bắt buộc:  {các field không được thiếu}
Tuỳ chọn:  {các field có thể null}

## Quy tắc tiến hoá
- Chỉ thêm field, không xoá, không đổi nghĩa field cũ
- Breaking change phải tạo version mới, chạy song song tối thiểu ___ tuần
- Bên tiêu thụ phải bỏ qua field lạ

## Hành vi khi lỗi
Timeout:       ___ ms
Retry:         ___ lần, backoff có jitter
Khi B chết:    {A làm gì — dồn hàng đợi, bỏ qua, hay dừng}
DLQ:           {có/không — ai xử lý}

## Cam kết vận hành
Throughput dự kiến:  ___ TPS (đỉnh ___)
SLO của B:           ___
Liên hệ khi sự cố:   {kênh}

05Individual Development Plan — SA track

Họ tên: ______________  Vai trò hiện tại: ______  Kỳ: Q_/2026

## Kết quả khảo sát
Trụ 1 Design       ___    Trụ 4 Technology   ___
Trụ 2 Quality      ___ ★  Trụ 5 Trade-off    ___ ★
Trụ 3 Data         ___ ★  Trụ 6 Comm         ___
Mức tổng đề xuất: SA__     (★ = trụ gate)

## Hai trụ ưu tiên quý này
1. Trụ ___ : từ SA_ lên SA_
   Chủ đề học (từ Knowledge Map): ____________________
   Bằng chứng cần tạo ra:         ____________________
2. Trụ ___ : từ SA_ lên SA_
   Chủ đề học: ____________________
   Bằng chứng cần tạo ra: ____________________

## Cam kết cụ thể trong quý
[ ] Tham dự ≥ 8/12 buổi Architecture Dojo
[ ] Trình bày ít nhất ___ lần
[ ] Nộp ___ ADR từ dự án thật (không phải từ bài Dojo)
[ ] Đọc xong: ____________________
[ ] Áp dụng vào dự án: ____________________

## Người đồng hành
Mentor: ______  Nhịp gặp: ______  Đánh giá lại: __/__/2026

06Checklist đối chiếu bằng chứng — Lớp 2

Lớp 2 có hai người đánh giá độc lập cho mỗi ứng viên: một SA chấm chất lượng kỹ thuật, một PM xác nhận bối cảnh dự án thật. Hai checklist dưới đây tách riêng vì hai người trả lời hai câu hỏi khác nhau — không dùng chung một form.

Phần A — SA đánh giá kỹ thuật

Người được review: ______________  SA đánh giá: ______________
Ngày: __/__/2026

## Hai câu hỏi bắt buộc

1. Bằng chứng kỹ thuật có CỤ THỂ không?
   (quyết định kiến trúc nào, đánh đổi nào đã thực sự đưa ra — hay chỉ
   là mô tả chung chung kiểu "đã tham gia thiết kế hệ thống"?)
   [ ] Cụ thể, kiểm chứng được    [ ] Chung chung, cần hỏi thêm

2. Có dấu hiệu nào của BA TRỤ GATE (2 Quality Attributes,
   3 Data & Integration, 5 Trade-off) trong công việc thực tế
   của người này không? Nêu ví dụ cụ thể, không suy diễn.
   Trụ 2: ____________________________________________
   Trụ 3: ____________________________________________
   Trụ 5: ____________________________________________

## Kết luận (SA)
[ ] Đạt — đủ căn cứ kỹ thuật để xét tiếp
[ ] Chưa đạt — bằng chứng kỹ thuật không đủ thuyết phục

Lý do (bắt buộc, 1–2 câu):
______________________________________________________________

Phần B — PM xác nhận dự án thật gate bắt buộc Đợt 1

Người được review: ______________  PM xác nhận: ______________
Ngày: __/__/2026

## Câu hỏi duy nhất, bắt buộc trả lời cụ thể

Người này đã XÂY DỰNG hoặc CHỊU TRÁCH NHIỆM CHÍNH về kiến trúc
của một dự án thật trong phòng SU02 chưa? Không tính "đã tham gia",
"đã hỗ trợ", hay "có mặt trong dự án" — phải là người thực sự ra
quyết định kiến trúc hoặc đồng sở hữu quyết định đó.

Tên dự án cụ thể:        ____________________________________
Vai trò của người này:   ____________________________________
Quyết định kiến trúc họ từng đưa ra (nêu ít nhất một):
______________________________________________________________
Dự án đã triển khai/go-live chưa, hay mới ở giai đoạn thiết kế?
______________________________________________________________

## Kết luận (PM) — BẮT BUỘC chọn một
[ ] CÓ — xác nhận đây là dự án thật, vai trò thật
[ ] KHÔNG — chưa có dự án nào đạt mức này ở thời điểm hiện tại

(Nếu chọn KHÔNG, ứng viên tự động không đủ điều kiện Đợt 1 dù
điểm khảo sát hay đánh giá kỹ thuật của SA cao đến đâu.)