「系統要快、不能停、資料要安全，而且預算不能增加。」
這種需求在會議上很常見，但還不能拿來選服務。架構師要做的第一件事，是把形容詞改成能量測、能測試，也能排出優先順序的條件。
圖解：先把需求分層，再用 SLO、RTO、RPO 與風險指標量化；候選方案要在同一組基準上比較，最後把理由、代價與重新檢視條件寫進 ADR。
一份需求至少要分五層
1. 業務結果
先問專案為什麼存在：
- 要增加多少轉換率？
- 要在什麼日期前退出資料中心？
- 要把新市場上線時間縮短多少？
- 哪種事故會造成合約、營收或信任損失？
「導入 Kubernetes」不是業務結果；「讓團隊能每週安全發布」才是。
2. 功能需求
系統要完成什麼工作，例如：
- 使用者能建立與取消訂單
- 財務能追蹤每筆退款
- 客服能查看訂單事件
- 系統能接收合作夥伴 Webhook
功能需求說明行為，不先指定產品。
3. 非功能需求
非功能需求描述品質：
- 可用性
- 延遲與吞吐
- 一致性
- 擴展性
- 安全與隱私
- 可維護性
- RTO 與 RPO
- 成本上限
- 永續性
「高效能」應改成「在每秒 2,000 筆請求時，P95 延遲低於 300 ms」這類可測條件。
4. 限制
限制是不能隨意改的邊界，例如：
- 必須在某日期前完成
- 只能使用核准區域
- 軟體授權綁定特定環境
- 團隊目前沒有 Kubernetes 維運能力
- 必須與既有身分或網路整合
要確認它真的是硬性限制，還是某人的偏好。兩者會導向完全不同的設計。
5. 假設與未知
架構文件應明確列出：
- 目前流量資料是否可信？
- 成長預估來自哪裡？
- 法規解讀是否已由適當團隊確認？
- 下游 API 有沒有 SLA？
- 遷移期間是否允許短暫唯讀？
沒有寫下來的假設，最後通常會變成事故時才被發現的需求。
SLI、SLO 和 SLA
| 名稱 | 用途 | 例子 |
|---|---|---|
| SLI | 實際量測服務表現的指標 | 成功請求比例、P99 延遲 |
| SLO | 團隊希望 SLI 在一段時間內達到的目標 | 30 天內 99.95% 合格請求 |
| SLA | 對客戶的合約承諾與未達成後果 | 低於承諾門檻時提供 Service Credit |
SLA 不必然等於 SLO。團隊通常讓內部目標比合約承諾更嚴格，保留處理問題的空間。
先定義「可用」是什麼
首頁回傳 200，但使用者不能付款，算可用嗎？
好的可用性 SLI 應該接近使用者結果，例如「有效結帳請求在 2 秒內成功完成的比例」，而不是只看 VM 有沒有開機。
可用性百分比換算出的停機時間只是數學結果，不會自動告訴你要單區域還是多區域。還要看：
- 衡量窗口
- 計畫性維護是否納入
- 哪些請求算有效
- 依賴服務的可靠性
- 故障模式與復原方式
- 業務可以接受的降級
Error Budget
如果 SLO 是 99.9%，剩餘的 0.1% 就是 Error Budget。它能幫產品與 SRE 討論：目前可以承擔多少變更風險，還是該先停止發布、修復可靠性。
Error Budget 不是允許團隊故意製造故障，而是把「功能速度和可靠性」的拉扯變成可觀察的決策。
RTO 和 RPO 要搭配故障情境
- RTO：中斷後，服務最晚多久要恢復。
- RPO：恢復時，最多能接受遺失多少時間範圍的資料。
同一個系統可能需要多組目標：
| 故障 | 可能的 RTO/RPO 思考 |
|---|---|
| 單一實例失效 | 自動重建，通常不應遺失持久資料 |
| 錯誤部署 | 快速回退，資料 Schema 要能相容 |
| 區域中斷 | 是否要切到另一區域，切換由誰決定 |
| 人為刪除 | 依備份與還原速度，不可只靠同步副本 |
| 勒索或憑證外洩 | 需要隔離、調查與乾淨還原點 |
只寫「RTO 15 分鐘」仍不完整。必須說是哪種故障、從哪個時間點開始計算，以及怎麼驗證。
合規需求不能用產業關鍵字猜
HIPAA、GDPR、PCI DSS 和各地個資法的要求不同，而且適用性取決於資料、角色、流程、合約和法律解讀。
架構師應該：
- 盤點受規範資料和資料流。
- 和法務、隱私、安全及稽核人員確認適用要求。
- 檢查使用的 Google Cloud 服務是否在相關合規範圍。
- 把資料位置、保留、刪除、金鑰與稽核要求寫成控制。
- 保存證據並定期驗證。
不要自行推導「使用者在歐盟，所以所有資料一定要留在歐盟」，也不要宣稱「用了 CMEK 就符合某法規」。雲端提供控制，組織仍要正確配置和操作。
Trade-off 要有比較基準
可以先建立決策表：
| 評估條件 | 權重或優先級 | 方案 A | 方案 B | 證據 |
|---|---|---|---|---|
| 達成 P99 延遲 | 必須 | 待測 | 待測 | 負載測試 |
| RPO 小於 5 分鐘 | 必須 | 符合 | 不符合 | 產品文件、演練 |
| 每月成本上限 | 高 | 試算值 | 試算值 | 真實流量與定價 |
| 團隊維運負擔 | 高 | 低 | 高 | On-call 與技能盤點 |
| 退出與遷移難度 | 中 | 中 | 低 | PoC、資料匯出測試 |
權重不是為了把架構假裝成精密數學。它的用途是讓利害關係人看見：大家是否真的同意什麼最重要。
CAP 定理不要變成產品標籤題
分散式系統發生網路分區時，不可能同時保證每個請求都成功和所有讀取都立即一致。實際產品還會提供不同讀取、複寫與路由模式。
所以不要只背「Firestore 是 CP、Bigtable 是 AP」。架構師要問的是：
- 這個操作需要哪種一致性？
- 發生分區時，要拒絕請求、回傳舊資料，還是降級？
- 使用的產品配置實際提供什麼語意？
- 應用能否辨認資料版本或處理衝突？
Spanner 預設提供外部一致性；Firestore 提供強一致性；Bigtable 則要依單叢集、複寫與 App Profile 判斷。這些產品行為比兩個字母更有用。
TCO 和 ROI 必須有基準
TCO 要算什麼？
- 雲端運算、儲存、網路與代管服務
- 地端硬體、機房、電力和維護合約
- 軟體與資料庫授權
- 遷移、雙跑、測試和訓練
- 維運、On-call 與事件處理人力
- 備份、資安、合規與支援
- 結束舊合約或資料移出的成本
只比較 VM 月費，通常會低估其中一邊。
ROI 要連回業務結果
可以衡量：
- 發布前置時間是否縮短
- 事件恢復時間是否下降
- 新市場是否提早上線
- 過去因容量不足失去的交易是否減少
- 團隊花在例行維護的時間是否降低
「上雲後節省 30%」必須有目前成本、預期用量、計算期間和風險範圍。沒有基準的百分比只是願望。
用 ADR 保存決策
Architecture Decision Record 可以很短：
# 決策：訂單資料庫的區域策略
## 背景
使用者分布、交易模式、SLO、RTO/RPO、資料位置限制。
## 候選方案
A. 單區域 HA
B. 雙區域或多區域
C. 依市場分區
## 決策
選擇哪個方案，以及最重要的三個理由。
## 代價
成本、延遲、營運複雜度和退出限制。
## 待驗證
負載測試、故障演練、成本試算、法務確認。
## 重新檢視條件
流量、法規、事故或成本達到什麼門檻時重開決策。這讓後來的人知道「當時為什麼這樣做」，而不是把舊架構當成永遠正確。
PCA 案例題的閱讀順序
目前標準考試有四個可能案例，每次出現兩個。可以用四步讀法：
- 先看商業需求：公司要達成什麼結果？
- 圈出硬性限制：期限、法規、既有投資與明確技術要求。
- 對照現況痛點：題目是否要求保留、遷移或淘汰某部分？
- 再比較選項：哪個最直接滿足題目，不額外發明需求？
考試題沒有提供的資訊，不要自行補成選答案的理由。實務上則相反：資訊不足就要追問或做 PoC，而不是硬選。
練習：線上教育平台
目前已知：
- 使用者在台灣和東南亞
- 活動期間同時在線人數大增
- 有直播、錄播和互動 API
- 團隊三人，沒有 Kubernetes 經驗
- 希望六個月內完成第一階段遷移
- 管理層希望降低成本
先不要畫架構。列出至少這些未知：
- 現在各功能的流量、延遲和可用性基準
- 直播是自建傳輸，還是使用外部平台
- 學員、付款與影音資料的分類和法律要求
- 現有資料庫引擎、大小、交易與停機窗口
- 可接受的 RTO/RPO
- 目前 TCO 和預算上限
- 團隊是否能在遷移期間雙跑
- 哪些元件能先 Rehost，哪些值得 Replatform
Cloud Run 可能是互動 API 的候選方案，但要在 Concurrency、連線、延遲和成本測試後才能決定。資料庫也不能只憑「團隊小」就選 Cloud SQL。
這才是架構分析：先承認不知道什麼，再設計取得證據的方法。
課後檢查
你應該能回答：
- 業務結果、功能需求、非功能需求和限制有什麼差別？
- 為什麼可用性百分比不能直接對應某種部署拓撲？
- RTO/RPO 為什麼要綁定故障情境？
- 合規需求應由哪些角色一起確認？
- 一份 ADR 至少要留下哪些資訊？
下一課會進入遷移規劃，把需求、依賴、遷移批次和回退條件串成可執行的路線。
