🎯 什麼情境該想到我
當你要讓網站/服務「扛住高流量、少當機、能加機器就變強」時。
⚙️ 怎麼用（兩大目標的核心手法）
高可用（少當機）：
- 消除單點：關鍵元件都要有冗餘備援 + 自動故障切換。
- 服務無狀態：狀態外置（快取/DB），任一台掛了流量可轉到別台。
- 故障隔離：艙壁、限流、降級（見 工具-服務容錯設計），別讓局部拖垮全局。
伸縮性（能水平擴展）：
4. 無狀態 + 負載均衡 → 加機器就能分攤（見 工具-透明多級分流）。
5. 資料層靠分片 + 讀寫分離（見 工具-資料分區、工具-資料複製）。
6. 非同步削峰：用訊息佇列把尖峰流量緩衝、削峰填谷。
★ 先算清楚「幾個 9」的真實意義
| SLA | 每年可停機 | 每月 | 代價 |
|---|---|---|---|
| 99% | 3.65 天 | 7.2 小時 | 低 |
| 99.9% | 8.8 小時 | 43 分鐘 | 中 |
| 99.95% | 4.4 小時 | 22 分鐘 | ★ 多數 SaaS 的實際目標 |
| 99.99% | 52 分鐘 | 4.3 分鐘 | ★ 高（要多可用區 + 自動故障轉移） |
| 99.999% | 5.3 分鐘 | 26 秒 | ★ 極高（幾乎沒有人工介入的餘地） |
（「每月」以 30 天 = 43,200 分鐘計：99.9% → 43.2 分鐘、99.99% → 4.32 分鐘；若用平均月長 365/12 ≈ 30.44 天 ≈ 730 小時，則是 43.8、4.38 分鐘，即 工具-容量估算 表上的數字。）
★ 99.99% 代表「一個月只有 4 分鐘」——
這比「人被叫醒 + 登入 + 判斷 + 處理」還短。
所以四個 9 以上幾乎必然要求「全自動故障轉移」，而那本身就是一個複雜且會出錯的系統。★ 先問業務要幾個 9，不要預設越高越好——每多一個 9，成本大約是十倍。
★ 可用性是「相乘」的，不是「取最小」
服務 A（99.9%）同步呼叫 B（99.9%）與 C（99.9%）
★ 整體 = 0.999³ = 99.7% ← 比任何單一元件都差
★ 每增加一個同步依賴，可用性都在下降。
這推出三條設計原則：
| 原則 | 說明 |
|---|---|
| ★ 減少同步依賴 | 能非同步就非同步（見 工具-訊息傳遞整合模式） |
| ★ 讓依賴可選 | 推薦服務掛了仍能結帳（降級，見 工具-服務容錯設計） |
| 冗餘讓可用性相加 | 兩個副本並聯： |
★ 找單點的系統化方法
逐項問「這個掛了會怎樣」：
□ 負載均衡器本身 → 多台 + VIP/DNS 故障轉移
□ ★ 資料庫主庫 → 最常見的單點。需要 failover（見 [[工具-資料複製]]）
□ 快取 → 掛了會不會把流量全打到 DB？（★ 快取雪崩）
□ ★ 訊息佇列 → 叢集化
□ ★ 設定中心 / 服務發現 → 掛了服務還起得來嗎？要有本地快取
□ 物件儲存 / CDN → 通常是託管的，但要看 SLA
□ ★ 憑證 / DNS 到期 → ★ 最常被忘記的單點，而且會全站掛掉
□ ★ 單一可用區 → 整個機房掛掉
□ ★ 部署流程本身 → CI 掛了能不能緊急上線？
□ ★ 人 → 只有一個人會處理某件事
★ 最後三項最常被忽略，而且它們造成的事故最久。
★ 無狀態為什麼是可擴展的前提
有狀態（session 存在記憶體）
→ 使用者必須回到同一台（sticky session）
→ ★ 那台掛了，使用者的狀態就沒了
→ ★ 無法自由擴縮（加機器不會分擔既有使用者）
→ 部署要考慮 draining
無狀態（session 存 Redis / JWT）
→ ★ 任何一台都能處理任何請求
→ 加機器立刻分擔、掛一台無感、部署可以直接滾動
★ 「把狀態集中到少數地方」是架構設計的核心手法：
應用層無狀態（容易擴展）+ 狀態集中在資料庫/快取（難擴展但只有一處要處理）。
★ 削峰填谷：非同步化的三種形態
| 形態 | 做什麼 | 適合 |
|---|---|---|
| 佇列緩衝 | 收下請求先回 202，背景處理 | ★ 不需要即時結果的（寄信、產報表、轉檔） |
| ★ 批次合併 | 把 N 個小寫入合併成一次大寫入 | 高頻小寫入（計數、日誌） |
| ★ 限流 + 排隊 | 超過容量就排隊或拒絕 | 秒殺、搶票（見 工具-秒殺系統設計） |
★ 關鍵：佇列不是無限的緩衝。
生產者長期快於消費者 → 佇列無限成長 → 記憶體/磁碟爆掉，而且延遲會變得極長。
佇列只能吸收「尖峰」，不能解決「容量不足」。
→ 一定要有有界佇列 + 背壓 + 監控佇列長度（見 工具-MQ消費端防禦三原則）。
★ 可用性的敵人往往不是硬體
| 真實的停機原因 | 對策 |
|---|---|
| ★ 部署出錯 | 金絲雀 + 快速回滾（見 工具-低風險發布模式） |
| ★ 設定變更 | 設定也要走 review 與灰度 |
| ★ 憑證/網域過期 | 自動續期 + 到期告警 |
| ★ 依賴的第三方掛了 | 降級路徑 |
| 流量尖峰 | 限流 + 自動擴縮 |
| 硬體故障 | 冗餘（這是最容易解的一種） |
★ 統計上，「變更」是絕大多數事故的觸發點——
所以提升可用性最有效的單一手段，是「讓變更更安全」而不是「加更多冗餘」。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- ★ 自動故障轉移本身會製造事故。誤判、腦裂、轉移到一個也壞的節點。
很多成熟團隊選擇半自動（自動偵測 + 人工確認）——錯誤的 failover 比晚幾分鐘恢復更糟
（見 工具-資料複製、工具-故障偵測）。 - ★ 冗餘要真的獨立。兩台機器在同一個機架、同一個電源、同一個可用區 → 不是冗餘。
- ★ 快取掛掉要能撐住。快取雪崩（大量 key 同時過期或快取整個掛）會讓流量瞬間全打到 DB。
→ TTL 加隨機抖動、快取掛了要限流保護 DB。 - 演練過的才算有。沒演練過的 failover 在真正需要時多半會失敗（見 工具-注入故障與韌性演練、遊戲日）。
- ★ SLA 要包含「誰來承諾什麼」。99.99% 不含計畫性維護？不含第三方故障？這些都要寫清楚。
- 備份 ≠ 高可用。備份解決「資料遺失」，高可用解決「服務中斷」。兩者都要，而且備份要定期演練還原。
🔗 相關工具
- 工具-服務容錯設計 —— 降級、熔斷、艙壁的具體做法
- 工具-透明多級分流 —— 流量層的冗餘
- 工具-資料複製 —— 資料層的冗餘與 failover 的坑
- 工具-故障偵測 —— 自動轉移的前提與誤判風險
- 工具-低風險發布模式 —— ★ 變更是最大的事故來源
- 工具-注入故障與韌性演練、遊戲日 —— 演練過的才算有
- 工具-MQ消費端防禦三原則 —— 削峰的背壓
- 工具-秒殺系統設計 —— 極端尖峰的完整案例