🎯 什麼情境該想到我
當你要評估或設計一個資料/後端系統，想有一套「該顧哪些面向」的總框架時。
⚙️ 怎麼用（三個評估軸）
- 可靠性（Reliability）：即使硬體/軟體/人為出錯，仍能正確運作。→ 設計容錯，主動注入故障測試。
- 可擴展性（Scalability）：先定義負載參數（QPS、讀寫比、資料量），再看負載成長時效能如何。用百分位（p95/p99）談延遲，別只看平均。
- 可維護性（Maintainability）：可運維性、簡單性（控制複雜度）、可演進性。
面對任何系統，逐軸問一遍，就不會漏掉非功能面。
★ 可靠性：三種故障，三種應對
| 故障類型 | 例子 | ★ 應對 |
|---|---|---|
| 硬體 | 磁碟壞、機器當、斷電 | 冗餘（複製、多可用區）——這是最容易解的一種 |
| 軟體 | bug、記憶體洩漏、失控的重試 | ★ 難得多：相關聯的故障會同時發生在所有節點上 |
| ★ 人為 | 設定錯誤、誤操作 | ★ 統計上最大的故障來源 |
★ 「人為是最大來源」這一點最常被忽略。對策不是「叫人更小心」，而是：
- 讓正確的事容易做、錯的事難做（好的預設值、危險操作要多一道確認）
- 沙箱環境讓人可以安全地試
- ★ 快速回滾比「不要出錯」更實際（見 工具-低風險發布模式）
- 完整的遙測（見 工具-遙測與監控）
★ 可擴展性：必須先定義「負載參數」
「這個系統可擴展嗎」是一個無法回答的問題。 要先問：
① 負載參數是什麼？
★ 不同系統的關鍵參數完全不同：
Web 服務 → QPS
資料庫 → 讀寫比
聊天室 → 同時在線人數
★ Twitter → 「每個使用者的追蹤者數分布」（不是總推文數）
② 負載增加時，系統怎麼變？
固定資源下，效能降低多少？
要維持效能，資源要增加多少？
★ Twitter 的例子值得記住：
瓶頸不是「每秒幾則推文」，而是**「名人發一則推文要寫進幾百萬個時間線」**——
找對負載參數，才找得到真正的瓶頸。 找錯了，優化全部做在沒用的地方。
★★ 延遲一定要用百分位，不能用平均
100 個請求：99 個 10ms，1 個 5000ms
平均 = 59.9ms ← ★ 這個數字騙了你
p99 = 5000ms ← ★ 這才是「最糟的那 1% 使用者」的體感
| 為什麼 | 說明 |
|---|---|
| ★ 平均會被長尾拉走，但又掩蓋長尾 | 它既不代表典型，也不代表最糟 |
| ★ 尾延遲放大（tail latency amplification） | 一個請求要呼叫 10 個後端，只要有一個慢，整個請求就慢。 後端 p99 = 1%，則前端「至少碰到一個慢的」機率 ≈ 9.6%——尾巴被放大了 10 倍 |
| ★ 最重要的使用者常在尾巴 | 資料最多的往往是最有價值的客戶 |
要看的指標：p50（典型）、p95、p99、p999、max。
★ 而且百分位不能平均（三台機器的 p99 各是 100ms ≠ 整體 p99 是 100ms）——
要用直方圖或 t-digest 合併（見 順序統計量與中位數）。
★ 可擴展的兩個方向
| 垂直（scale up） | 水平（scale out） | |
|---|---|---|
| 做法 | 換更大的機器 | 加更多機器 |
| 複雜度 | ★ 低（什麼都不用改） | 高（分區、複製、一致性） |
| 上限 | 有物理上限 | 幾乎無限 |
| 建議 | ★ 先垂直。單機現在可以很大（TB 記憶體、上百核心） | 垂直撐不住才水平 |
★ 「無狀態服務水平擴展很容易，有狀態的很難」——
所以架構設計的一個核心目標是把狀態集中到少數地方（資料庫、快取），讓其他部分無狀態。
★ 可維護性：三個子維度
| 維度 | 問什麼 |
|---|---|
| 可運維性 | ★ 出事時能不能快速知道、快速定位、快速修？（遙測、runbook、可回滾） |
| 簡單性 | ★ 新人多久能上手？複雜度是本質的還是偶然的？（見 工具-管理複雜度） |
| 可演進性 | 需求變了，改起來容易嗎？ |
★ 「偶然複雜度」是可以被消除的（Brooks 的區分）：
本質複雜度來自問題本身；偶然複雜度來自我們的解法——
工具爛、抽象錯、歷史包袱。可維護性的工作幾乎都在消除偶然複雜度。
★ 怎麼實際使用這三軸
在設計 review 或系統設計面試時，逐軸問一遍：
可靠性 → 哪裡會掛？掛了會怎樣？人為失誤怎麼防？能多快回滾？
可擴展性 → 負載參數是什麼？10 倍時哪裡先爆？p99 是多少？
可維護性 → 誰來維運？出事怎麼查？新人要多久上手？
★ 這三個問題涵蓋了幾乎所有「非功能需求」，而它們正是系統設計評審真正在看的東西
（見 AI 系統設計框架、工具-系統設計思考框架）。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- ★ 三者互相衝突。更可靠通常更慢更貴；更可擴展通常更複雜（更難維護）。
這是取捨不是清單——要明說你選了哪一邊、為什麼。 - ★ 不要過早追求可擴展性。「未來可能要撐一百萬使用者」是最常見的過度設計理由。
先做能跑的簡單系統，量出真正的瓶頸再擴展——而且那時你才知道正確的負載參數。 - 可靠性有邊際成本。從 99% 到 99.9% 不貴；從 99.99% 到 99.999% 可能要十倍投入。
★ 先問業務需要多少個 9，不要預設越高越好。 - ★ 平均值幾乎永遠是錯的指標（見上）。
- 可維護性最難量化，所以最容易被犧牲。→ 用可觀測的代理指標：
DORA 的交付指標：吞吐量（變更前置時間、部署頻率、失敗部署的恢復時間）與不穩定度（變更失敗率、部署重工率），共五項；「失敗部署的恢復時間」取代了早期的 MTTR（查證 2026-09-25，見 工具-部署管線與持續交付）。 - 「可擴展的架構」不存在，只有「針對某種負載可擴展」。負載模式變了就要重新設計。
🔗 相關工具
- 工具-系統設計思考框架 —— 怎麼把這三軸用在實際設計上
- 工具-容量估算 —— 可擴展性的量化
- 工具-管理複雜度 —— 可維護性的核心
- 工具-服務容錯設計 —— 可靠性的具體手段
- 工具-遙測與監控 —— 可運維性的基礎
- 順序統計量與中位數 —— ★ 百分位怎麼算、為什麼不能平均
- 工具-用度量取代模糊判斷 —— DORA 四指標
- 設計資料密集型應用