需求分析與架構決策：先把模糊期待變成可驗證條件

「系統要快、不能停、資料要安全，而且預算不能增加。」

這種需求在會議上很常見，但還不能拿來選服務。架構師要做的第一件事，是把形容詞改成能量測、能測試，也能排出優先順序的條件。

一份需求至少要分五層

1. 業務結果

先問專案為什麼存在：

• 要增加多少轉換率？
• 要在什麼日期前退出資料中心？
• 要把新市場上線時間縮短多少？
• 哪種事故會造成合約、營收或信任損失？

「導入 Kubernetes」不是業務結果；「讓團隊能每週安全發布」才是。

2. 功能需求

系統要完成什麼工作，例如：

• 使用者能建立與取消訂單
• 財務能追蹤每筆退款
• 客服能查看訂單事件
• 系統能接收合作夥伴 Webhook

功能需求說明行為，不先指定產品。

3. 非功能需求

非功能需求描述品質：

• 可用性
• 延遲與吞吐
• 一致性
• 擴展性
• 安全與隱私
• 可維護性
• RTO 與 RPO
• 成本上限
• 永續性

「高效能」應改成「在每秒 2,000 筆請求時，P95 延遲低於 300 ms」這類可測條件。

4. 限制

限制是不能隨意改的邊界，例如：

• 必須在某日期前完成
• 只能使用核准區域
• 軟體授權綁定特定環境
• 團隊目前沒有 Kubernetes 維運能力
• 必須與既有身分或網路整合

要確認它真的是硬性限制，還是某人的偏好。兩者會導向完全不同的設計。

5. 假設與未知

架構文件應明確列出：

• 目前流量資料是否可信？
• 成長預估來自哪裡？
• 法規解讀是否已由適當團隊確認？
• 下游 API 有沒有 SLA？
• 遷移期間是否允許短暫唯讀？

沒有寫下來的假設，最後通常會變成事故時才被發現的需求。

flowchart TB
  S["Stakeholder statement<br/>快、穩、安全、不能加預算"] --> B["Business outcome<br/>Why／By when／<br/>Value／Loss"]
  B --> F["Functional requirements<br/>User／System must do"]
  F --> N["Non-functional requirements<br/>SLI／SLO／RTO／RPO／Scale／Cost"]
  N --> C["Hard constraints<br/>Region／License／Deadline／Team／Integration"]
  C --> A["Assumptions＋Unknowns<br/>Owner＋Due date＋Evidence method"]
  A --> G{"每項需求能量測、測試<br/>且有優先順序？"}
  G -->|"否"| S
  G -->|"是"| R["Candidate criteria＋Acceptance tests"]

SLI、SLO 和 SLA

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

SLA 不必然等於 SLO。團隊通常讓內部目標比合約承諾更嚴格，保留處理問題的空間。

先定義「可用」是什麼

首頁回傳 200，但使用者不能付款，算可用嗎？

好的可用性 SLI 應該接近使用者結果，例如「有效結帳請求在 2 秒內成功完成的比例」，而不是只看 VM 有沒有開機。

可用性百分比換算出的停機時間只是數學結果，不會自動告訴你要單區域還是多區域。還要看：

• 衡量窗口
• 計畫性維護是否納入
• 哪些請求算有效
• 依賴服務的可靠性
• 故障模式與復原方式
• 業務可以接受的降級

Error Budget

如果 SLO 是 99.9%，剩餘的 0.1% 就是 Error Budget。它能幫產品與 SRE 討論：目前可以承擔多少變更風險，還是該先停止發布、修復可靠性。

Error Budget 不是允許團隊故意製造故障，而是把「功能速度和可靠性」的拉扯變成可觀察的決策。

flowchart TB
  J["User journey events"] --> I["SLI<br/>成功且在時限內的<br/>有效請求比例"]
  I --> O["SLO<br/>內部目標＋<br/>Measurement window"]
  O --> B["Error Budget<br/>允許的未達標範圍"]
  O --> A["SLA<br/>對外承諾＋<br/>未達後果"]
  B --> C{"Budget burn rate<br/>與剩餘量？"}
  C -->|"健康"| R["維持正常<br/>Release cadence"]
  C -->|"快速燃燒／耗盡"| F["凍結高風險變更，<br/>優先處理<br/>Reliability"]
  R --> I
  F --> I

RTO 和 RPO 要搭配故障情境

• RTO：中斷後，服務最晚多久要恢復。
• RPO：恢復時，最多能接受遺失多少時間範圍的資料。

同一個系統可能需要多組目標：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

只寫「RTO 15 分鐘」仍不完整。必須說是哪種故障、從哪個時間點開始計算，以及怎麼驗證。

flowchart LR
  F{"Failure scenario"}
  F -->|"Instance／Zone"| H["Recreate／Failover<br/>Persistent data 不應遺失"]
  F -->|"Bad deployment"| D["Rollback／Fix forward<br/>Schema 必須相容"]
  F -->|"Region outage"| R["Cross-region failover<br/>Route＋Data＋Operations"]
  F -->|"Human delete／Corruption"| B["Independent backup＋Restore"]
  F -->|"Ransomware／Credential compromise"| I["Isolate＋Investigate＋Clean restore point"]
  H --> T["定義 Start event、Target service、<br/>RTO、RPO 與 Owner"]
  D --> T
  R --> T
  B --> T
  I --> T
  T --> G["Game day／Restore test<br/>量測每一步實際時間與 data loss"]

合規需求不能用產業關鍵字猜

HIPAA、GDPR、PCI DSS 和各地個資法的要求不同，而且適用性取決於資料、角色、流程、合約和法律解讀。

架構師應該：

1. 盤點受規範資料和資料流。
2. 和法務、隱私、安全及稽核人員確認適用要求。
3. 檢查使用的 Google Cloud 服務是否在相關合規範圍。
4. 把資料位置、保留、刪除、金鑰與稽核要求寫成控制。
5. 保存證據並定期驗證。

不要自行推導「使用者在歐盟，所以所有資料一定要留在歐盟」，也不要宣稱「用了 CMEK 就符合某法規」。雲端提供控制，組織仍要正確配置和操作。

flowchart TB
  R["Regulation／Contract／Policy text"] --> S["Legal／Privacy／Security／Audit<br/>確認適用範圍與責任"]
  S --> D["Data inventory＋Flow＋Roles＋Regions＋Retention"]
  D --> C["Control requirements<br/>Access、Encryption、Location、Deletion、Logging"]
  C --> I["實作 IAM／Policy／KMS／Network／Process"]
  I --> E["Collect Evidence<br/>Config、Logs、<br/>Approvals、<br/>Tests、Exceptions"]
  E --> V{"Control 持續有效<br/>且 Evidence 完整？"}
  V -->|"否"| P["Remediate＋<br/>Owner＋Due date"]
  P --> I
  V -->|"是"| A["Periodic<br/>reassessment／Audit"]
  A --> S

Trade-off 要有比較基準

可以先建立決策表：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

權重不是為了把架構假裝成精密數學。它的用途是讓利害關係人看見：大家是否真的同意什麼最重要。

CAP 定理不要變成產品標籤題

分散式系統發生網路分區時，不可能同時保證每個請求都成功和所有讀取都立即一致。實際產品還會提供不同讀取、複寫與路由模式。

CAP 三個字母分別是 Consistency（每次讀取都拿到最新寫入）、Availability（每個請求都得到回應）和 Partition tolerance（節點之間的網路斷開時系統仍能運作）。分區在分散式系統裡躲不掉，常見的標籤就剩兩種：CP 是分區時寧可拒絕請求也不回舊資料，AP 是先回應、接受讀到的可能是舊資料。

所以不要只背「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. 依市場分區

## 決策

選擇哪個方案，以及最重要的三個理由。

## 代價

成本、延遲、營運複雜度和退出限制。

## 待驗證

負載測試、故障演練、成本試算、法務確認。

## 重新檢視條件

流量、法規、事故或成本達到什麼門檻時重開決策。

這讓後來的人知道「當時為什麼這樣做」，而不是把舊架構當成永遠正確。

上面的範本每一格只寫了該填什麼；想看填好的樣子，第 23 課有一份完整的範例 ADR。

flowchart TB
  C["Context<br/>Outcome、Requirements、Constraints、Unknowns"] --> O["Options＋共同 Evaluation criteria"]
  O --> E["Evidence<br/>Docs、PoC、Load test、Drill、TCO、Legal"]
  E --> D["Decision＋Top reasons"]
  D --> T["Trade-offs／Consequences／Risks"]
  T --> V["Validation plan＋Owner＋Due date"]
  V --> R["Review triggers<br/>Traffic、Incident、Cost、Law、Product lifecycle"]
  R --> G{"Trigger 發生？"}
  G -->|"否"| M["持續監控 Evidence"]
  M --> G
  G -->|"是"| C2["建立新 ADR，<br/>Supersede 舊決策"]

PCA 案例題的閱讀順序

目前標準考試有四個可能案例，每次出現兩個。可以用四步讀法：

1. 先看商業需求：公司要達成什麼結果？
2. 圈出硬性限制：期限、法規、既有投資與明確技術要求。
3. 對照現況痛點：題目是否要求保留、遷移或淘汰某部分？
4. 再比較選項：哪個最直接滿足題目，不額外發明需求？

考試題沒有提供的資訊，不要自行補成選答案的理由。實務上則相反：資訊不足就要追問或做 PoC，而不是硬選。

練習：線上教育平台

目前已知：

• 使用者在台灣和東南亞
• 活動期間同時在線人數大增
• 有直播、錄播和互動 API
• 團隊三人，沒有 Kubernetes 經驗
• 希望六個月內完成第一階段遷移
• 管理層希望降低成本

先不要畫架構。列出至少這些未知：

• 現在各功能的流量、延遲和可用性基準
• 直播是自建傳輸，還是使用外部平台
• 學員、付款與影音資料的分類和法律要求
• 現有資料庫引擎、大小、交易與停機窗口
• 可接受的 RTO/RPO
• 目前 TCO 和預算上限
• 團隊是否能在遷移期間雙跑
• 哪些元件能先 Rehost，哪些值得 Replatform

Cloud Run 可能是互動 API 的候選方案，但要在 Concurrency、連線、延遲和成本測試後才能決定。資料庫也不能只憑「團隊小」就選 Cloud SQL。

這才是架構分析：先承認不知道什麼，再設計取得證據的方法。

動手做：交出一頁需求表

花 10 分鐘，把上面的案例整理成一頁表格。先自行完成，再看下方參考解答。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

課後檢查

你應該能回答：

• 業務結果、功能需求、非功能需求和限制有什麼差別？（回〈一份需求至少要分五層〉）
• 為什麼可用性百分比不能直接對應某種部署拓撲？（回〈先定義「可用」是什麼〉）
• RTO/RPO 為什麼要綁定故障情境？（回〈RTO 和 RPO 要搭配故障情境〉）
• 合規需求應由哪些角色一起確認？（回〈合規需求不能用產業關鍵字猜〉）
• 一份 ADR 至少要留下哪些資訊？（回〈用 ADR 保存決策〉）

答不出來的話，括號裡是該回去重讀的那一節。

下一課會進入遷移規劃，把需求、依賴、遷移批次和回退條件串成可執行的路線。

官方資料

• Professional Cloud Architect 考試指南
• Google Cloud Well-Architected Framework
• SRE：Service Level Objectives
• Google Cloud 合規資源
• Spanner 的外部一致性
• Bigtable 複寫與一致性

想把 SLI 和 SLO 練熟，站內的架構師設計工作坊 · 步驟 4可以直接填自己的案例。