PCA 雲端架構師之旅 02 — 定義 User Personas

讀完 case study，很容易馬上打開白板畫架構圖。但在畫圖前，先問一句：這套系統要服務誰？偶爾購物的顧客、批次上傳資料的合作夥伴，和每天查報表的分析師，需求不會一樣。

User Persona（使用者輪廓）把籠統的「使用者」拆成具體角色、任務和使用頻率。有了這些資訊，設定 SLO、設計 API 或選資料庫時，才知道自己在照顧哪一種使用方式。

這是 PCA 雲端架構師之旅 的第二步。上一篇讀懂案例情境整理了需求；現在要看看誰會使用系統，以及他們各自在什麼情況下使用。

從案例描述找出使用者

案例可能不會直接要求列出 persona，卻會提到誰在用系統、做哪些工作。官方案例通常只寫到這裡，例如 Cymbal Retail 提到客服人員會手動替顧客輸入訂單、舊系統靠 SFTP 傳檔與 ETL 批次處理；使用頻率沒寫時，先標成待確認。若題目進一步寫到「消費者每週登入一次」「供應商批次上傳 CSV」「分析師每月跑報表」這類句子，就等於說明了誰在使用、使用頻率，以及服務要處理哪種工作。

例如前台購物需要互動回應，凌晨匯入則可能更在意大量資料能否處理完、失敗後能否重試。角色本身不會直接決定要用 Cloud Run、GKE 或哪個資料庫，但能幫你找出該先問的延遲、流量與權限問題。

把這些使用情境記下來，後面訂 SLO、畫資料流和比較服務時才有依據。

flowchart TB
  C[案例中的角色與行為] --> W[Who<br/>誰在使用]
  W --> G[Goal<br/>要完成什麼]
  G --> X[Context<br/>裝置、頻率、尖峰]
  X --> F[Failure<br/>失敗代價]
  F --> D[Data<br/>接觸的敏感資料]
  D --> S[架構訊號<br/>延遲、可靠度、權限、成本]

Persona 要寫使用情境，不只是功能

「使用者可以登入、下單、查訂單」說的是系統功能，還看不出這個人怎麼用服務。寫 persona 時，補上他的目標、使用情境，以及哪些限制會影響設計；具體功能留到 user story 再拆。

以通勤時用手機買電子書的讀者為例：他可能常遇到網路中斷，希望離線閱讀；結帳時願意等多久、閱讀進度能不能在另一台裝置接上，也會影響後面的 SLO 與資料同步設計。這些細節比年齡或一張人物照片更有用。

另外確認他會接觸哪些資料：一般個資、持卡人資料，或受規範的健康資訊，需要的存取與稽核控制不同。不是看到敏感資料就先指定某個資料庫，而是先畫出資料流與誰能存取，再核對適用規範。

教材常提到 PII（可識別個人身分的資訊）、PCI DSS（支付卡資料安全標準）與 PHI（美國 HIPAA 定義的受保護健康資訊）。PCI DSS 是標準，不是資料類型；PHI 也要看資料與組織是否落在 HIPAA 適用範圍。這些名詞的作用，是提醒我們先確認資料與法規邊界。（參考：PCI DSS 適用範圍、HHS 的 PHI 說明）

📝 考場提點

「每週登入一次」「凌晨跑批次」「每月拉報表」都在描述使用頻率與流量型態。先記下每個角色要完成什麼、什麼時候做，再決定是即時服務還是排程工作，以及需要哪一種運算平台。

Persona 太多或太少，都會漏掉重點

Persona 列得太多，團隊很難分辨誰的需求優先；只寫一個「消費者」，又可能漏掉管理員、客服或外部系統。先保留會影響架構決策的角色，再合併需求相近的角色。

最容易被漏掉的，是內部使用者跟非人類使用者。

內部使用者包括管理員、客服和資料分析師。他們的需求也會改變架構：分析查詢要不要和交易資料庫分開？管理操作需不需要稽核？客服能看到哪些訂單資料？若分析師只能直接對正式資料庫跑大型報表，線上交易也可能受影響。

別漏了非人類使用者：凌晨的批次排程、合作夥伴呼叫的 API、第三方 SaaS 發來的 webhook。它們也有流量、失敗模式和服務承諾。每天凌晨匯入一批資料，重點可能是吞吐量與失敗重試；消費者在網站上點選商品，則更在意回應延遲。把這兩類需求分開，才容易選對處理方式。

Persona 不必湊固定數量。只要每個角色都有會影響功能、權限或流量設計的差異，就值得保留；若兩個角色的需求與操作幾乎一樣，先合併會比較好討論。

flowchart LR
  P[列出核心 Persona] --> E{外部使用者已涵蓋？}
  E -- 否 --> A[補消費者或合作夥伴]
  E -- 是 --> I{內部使用者已涵蓋？}
  I -- 否 --> B[補客服、營運或分析師]
  I -- 是 --> N{非人類角色已涵蓋？}
  N -- 否 --> C[補排程、API 或 webhook]
  N -- 是 --> R{角色是否重複或失焦？}
  A --> P
  B --> P
  C --> P
  R -- 是 --> M[合併相同目標與行為]
  M --> P
  R -- 否 --> D[保留會影響設計的核心角色]

替每個 persona 確認五件事

把角色寫成卡片後，用下面五個問題檢查。這些問題不只用來答題，規劃真實系統時也用得上。

他最在意什麼？ 消費者在意快，分析師在意資料對不對、夠不夠新，外部系統在意有沒有確實送達。在意的東西不一樣，你優化的方向就不一樣。

他尖峰的時候在做什麼？ 這題直接決定你的 scaling 要服務誰的尖峰。消費者的尖峰可能是雙 11 晚上八點，批次的尖峰是固定凌晨三點——前者要彈性自動擴張，後者你早就知道時間，可以排程預備。

他失敗的時候會怎樣？ 商品頁暫時打不開、結帳失敗、合規日誌漏寫，影響的範圍和補救方式都不同。先估計使用者、金流與法規風險，才能決定哪些操作要即時恢復，哪些可以稍後重試。

他對成本的影響是什麼？ 大量免費會員讀取資料，和少數企業客戶高頻呼叫 API，會把成本推向不同的資源。估算前先看各角色的請求量、資料量和尖峰時間。

有沒有非人類的角色被你漏了？ 問完前四題，回頭再掃一次題目，確認排程、外部整合、合作夥伴 API 都被你當成正式 persona 對待，而不是事後補丁。

📝 考場提點

先替每個角色列出失敗情境，再判斷需要多快恢復、能否非同步重試，以及是否需要隔離成獨立服務。不是每個功能都要相同的可用性目標；保護強度應與失敗造成的影響相符。

flowchart TB
  F[角色操作失敗] --> I{會造成金流、法規<br/>或不可逆資料損失？}
  I -- 是 --> H[高保護<br/>嚴格 SLO、冪等、稽核]
  I -- 否 --> R{可稍後重做或重試？}
  R -- 是 --> Q[非同步保護<br/>佇列、重試、告警]
  R -- 否 --> G[體驗降級<br/>快取、舊快照、<br/>友善錯誤]
  H --> B[核對成本是否符合業務價值]
  Q --> B
  G --> B

走一遍範例 — 登雲書店

老規矩，回到我們的主線案例。登雲書店這套系統，我會抓出 4 個核心 persona——兩個外部、一個非人類、一個內部，剛好把上面講的幾種角色都涵蓋到。

Persona 1 — 一般消費者「阿元」

• 32 歲，上班族，通勤時用手機瀏覽書目，週末用筆電下單。
• 目標：快速找到想看的書，結帳流程不要卡關。
• 使用頻率：每月 2–4 次。
• 裝置/網路：iPhone + 捷運 5G，偶爾訊號弱。
• 非功能敏感度：首頁超過 2 秒直接離開；結帳失敗會客訴。
• 資料敏感度：會輸入信用卡與地址（PCI、PII）。

阿元會在訊號不穩的通勤途中瀏覽，也會留下地址並完成付款。後續設計除了頁面速度，還得追問結帳失敗時怎麼恢復，以及持卡人資料與個資會經過哪些系統。

Persona 2 — 電子書訂閱者「小葵」

• 25 歲，喜歡閱讀冷門類型，每天通勤閱讀 30 分鐘。
• 目標：閱讀進度即時同步，換裝置接著看也不卡。
• 使用頻率：每日。
• 裝置/網路：Android 平板 + 家裡 Wi-Fi、捷運 4G。
• 非功能敏感度：書籍下載要秒開；進度不能遺失。
• 資料敏感度：閱讀紀錄（個人偏好，屬於 PII）。

小葵和阿元都是消費者，遇到的問題卻不同。阿元在意結帳能否完成；小葵更在意離線閱讀和換裝置後的進度。只寫一個籠統的「消費者」，這些差異很容易被蓋掉。

Persona 3 — 書商合作夥伴「天下出版 IT 窗口」

• 外部系統角色，每日凌晨 3 點批次上傳 CSV 更新庫存與價格。
• 目標：確保每日批次在 30 分鐘內完成，失敗時能收到 email。
• 使用頻率：每日 1 次大批量。
• 非功能敏感度：對延遲不敏感，但對準確性與可追溯性極敏感。
• 資料敏感度：庫存與成本（商業機密）。

這個角色代表合作夥伴的批次系統，需求和一般訪客不同：首頁速度與它無關，資料是否完整、正確且可追溯才重要。批次失敗後，系統會不會重試、重送會不會造成重複更新，以及誰會收到告警，都需要先說清楚。

Persona 4 — 內部營運分析師「Marcus」

• 34 歲，每週跑 10 份報表給行銷主管。
• 目標：能用 SQL 直接查詢昨日資料，不要寫程式拉 API。
• 使用頻率：工作日 9am–6pm。
• 非功能敏感度：資料新鮮度 D+1 可接受；查詢慢一點沒關係。
• 資料敏感度：去識別化後的會員行為資料。

Marcus 是容易在規劃時被漏掉的內部使用者。他接受前一天的資料，查詢也不必像結帳一樣快；但報表必須在工作需要前完成。這提醒我們估算分析查詢量，以及它是否會和線上交易爭用資源。

四個角色的需求可以先分成幾條路徑：阿元和小葵需要順暢的網站與閱讀體驗；天下出版需要可重試、可追溯的批次匯入；Marcus 需要不拖慢線上交易的報表查詢。這些需求會縮小後續選型範圍，但還要核對流量、資料量與成本，不能只憑 persona 就定服務。

想像 Marcus 直接對處理訂單的 Cloud SQL 跑月報：資料量還小時也許沒感覺，之後大型查詢可能和結帳流量爭用連線與 I/O。這不是說 Cloud SQL 不能做報表，而是分析需求若早在 persona 階段就被看見，便能提早評估讀副本、匯出或獨立分析系統，不必等到線上請求變慢才補救。

flowchart LR
  U[阿元<br/>即時購物] --> U1[低延遲前台＋可靠結帳]
  E[小葵<br/>跨裝置閱讀] --> E1[離線可讀＋最終一致同步]
  P[出版夥伴<br/>每日批次] --> P1[可追溯佇列＋重試與通知]
  A[Marcus<br/>D+1 分析] --> A1[分析倉儲＋去識別化資料]
  U1 --> D[分離交易、同步、批次與分析路徑]
  E1 --> D
  P1 --> D
  A1 --> D

不同角色，需要不同的服務目標

最後回到一個實際的取捨：不同 persona 對延遲、資料新鮮度和故障的容忍度不一樣，不必套同一組服務目標。

Marcus 的報表若隔天交付即可，也容許較長的等待時間，就不需要直接套用結帳流程的 99.99% 可用性、即時更新與多區複製。先問清楚延遲或延後交付會造成什麼損失，再決定哪些地方值得增加成本。Persona 的作用，就是讓這種差異在設計前被看見。

同樣地，也別把 persona 寫成廣告文案。「熱愛科技、樂於嘗鮮」這種句子讀起來很美，但對你選 Cloud Run 還是 GKE 一點幫助都沒有。persona 要的是行為跟限制：他多久用一次、容忍幾秒延遲、碰什麼資料、失敗會怎樣。能換算成技術決策的，才是有用的 persona。

延伸閱讀

• Well-Architected Framework — Define reliability based on user-experience goals — 官方說明如何先評估使用者的實際體驗，再對應到可靠度目標與指標。
• Nielsen Norman Group — Persona Definition — 說明 persona 的定義、建立方式與用途。
• Google SRE Workbook — Ch. 2 Implementing SLOs — 講如何把使用者期望轉成 SLO，第 04 篇會用到。

下一步：人物到手了，接著就把「誰」跟「他要做什麼」連起來，寫成使用者故事（User Stories）。

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 2 填入你的 case study，邊寫邊內化。