為什麼 NFR 決定架構
功能需求告訴你系統要「做什麼」，NFR 告訴你系統要「做到什麼程度」——而這個「程度」往往是架構選型的主要驅動力：
- 「99.99% uptime」→ 逼出 Active-Active 多 AZ 部署，逼出 Saga Pattern 代替分散式 transaction
- 「p99 latency < 50ms」→ 逼出 CQRS + 讀模型預先計算，逼出 Redis 作為查詢快取
- 「每月 1TB 增長，三年不換架構」→ 逼出水平 Sharding，逼出 Partition 設計
先定 NFR，再選 Pattern。沒有 NFR 的架構設計是在猜。
NFR 分類
Performance
| 指標 | 說明 | 怎麼量化 |
|---|---|---|
| Latency | 單個請求的回應時間 | p50 / p95 / p99（用百分位，不用平均） |
| Throughput | 單位時間能處理多少 request | RPS / QPS |
| Concurrency | 同時在線用戶 / 連線數 | 峰值並發數 |
為什麼用 p99 不用平均：平均會被少量超快請求拉低，隱藏尾部延遲問題。100 個請求裡 99 個 10ms 回來、1 個 10000ms，平均是 108ms，p99 是 10000ms——用戶的痛在 p99。
Scalability
- 垂直擴展（Scale Up）：換更強的機器。有天花板，停機升級有風險。
- 水平擴展（Scale Out）：加更多機器，最終要能做到 stateless + load balancing。
量化：「需要支撐當前 10 倍流量，不修改架構的情況下」
Reliability / Availability
| 概念 | 定義 |
|---|---|
| Availability | 系統可用的時間比例 |
| MTBF | Mean Time Between Failures，失敗之間的平均時間 |
| MTTR | Mean Time To Recovery，從失敗到恢復的平均時間 |
| RTO | Recovery Time Objective，可接受的最長恢復時間 |
| RPO | Recovery Point Objective，可接受的最大資料遺失時間 |
可用性數字對照：
99% = 每年 87.6 小時停機
99.9% = 每年 8.76 小時停機
99.95% = 每年 4.38 小時停機（月約 21 分鐘）
99.99% = 每年 52.6 分鐘停機（月約 4.4 分鐘）
Durability
資料不丟失——和 Availability 不同，Availability 是「系統能用」，Durability 是「資料不消失」。
AWS S3 保證 99.999999999%（11 個 9）Durability，但 Availability 只保 99.99%——S3 偶爾會暫時不能存取，但你的物件不會消失。
Observability
- 系統自己能告訴你哪裡出問題（Metrics / Logs / Traces）
- alert 能在用戶報告前先發出
- 能在不重啟的情況下診斷問題
NFR 量化：「所有 API 都有 latency / error rate metric；p99 latency 超過 500ms 要 alert」
Security
- 靜態資料加密（at-rest encryption）
- 傳輸加密（TLS）
- 認證（Authentication）和授權（Authorization）的邊界
- GDPR / PCI-DSS / SOC 2 等合規要求（Compliance NFR）
Maintainability
- 新工程師多久能上手修 bug（onboarding time）
- 測試覆蓋率目標
- 技術債的可接受上限
NFR 之間的衝突
NFR 很少同時成立，常見的衝突：
| 衝突 | 說明 |
|---|---|
| Availability vs Consistency | CAP Theorem——無法同時保 AP + CP |
| Security vs Developer Experience | 嚴格的認證流程減慢開發速度 |
| Performance vs Cost | 更低延遲需要更多資源 |
| Flexibility vs Maintainability | 高度靈活的架構通常更難維護 |
在需求文件裡明確寫出衝突並記錄取捨決定，讓未來的人知道為什麼是這樣設計的。
怎麼寫有意義的 NFR
壞的 NFR（無法驅動架構決策）：
- ❌ 「系統要快」
- ❌ 「要穩定」
- ❌ 「要安全」
好的 NFR（能驅動架構決策）：
- ✅ 「首頁 API p99 latency < 200ms（東京 region）；超過觸發 alert」
- ✅ 「月可用性 >= 99.95%；計劃維護每月 < 2 次，每次 < 30 分鐘」
- ✅ 「用戶資料符合 GDPR；PII 欄位 at-rest 加密；audit log 保留 3 年」
- ✅ 「支撐當前 5 倍流量不改架構；10 倍需要加機器不需要改 code」
NFR → SLO / SLA
SLI（Service Level Indicator）：衡量服務表現的指標（如 error rate、latency）
SLO（Service Level Objective）：對 SLI 的目標（如 p99 latency < 200ms in 99.9% of rolling 30d windows）
SLA（Service Level Agreement）：對外的承諾，通常比 SLO 更保守（有違約賠償）
Error Budget：SLO 允許的失敗空間。99.9% SLO = 每月 43 分鐘 error budget。用完了就停功能開發，優先穩定性。