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

讀完 case study，手很癢，第一個衝動通常是打開白板畫架構圖。先把筆放下——你連這套系統要服務誰都還沒講清楚，圖畫出來也只是好看的猜測。

User Persona（使用者輪廓）就是把題目裡那個模糊的「使用者」，變成幾個有名字、有習慣、有脾氣的具體人物。有了對象，後面每一個技術決策才有東西可以對照。少了它，你的架構會變成「通用型」，而我得老實說，工程上的「通用」十次有九次等於「對誰都不夠好」。

這是 PCA 雲端架構師之旅 的第二步。上一篇我們把案例情境讀透了：01 · 讀懂案例情境。這一篇要做的，是把那份需求摘要裡的「人」拉出來，一個一個看清楚。

---

它在考卷上長什麼樣

PCA 的 case study 很少直接說「請定義 persona」。它的玩法是把使用者行為散在敘述裡：「消費者每週登入一次」「供應商需要批次上傳 CSV」「資料科學家每月跑報表」。你讀的時候如果只當成背景雜訊，後面就會吃虧。

吃虧在哪？選型題。Cloud Run 還是 GKE、Pub/Sub 還是 Cloud Tasks、Spanner 還是 Cloud SQL——這些題目的正確答案，幾乎都先取決於「這是哪種使用者、在做哪種事」。同一個服務，給即時互動的消費者用、跟給凌晨跑批次的外部系統用，最佳解可能完全相反。題目把線索藏在前面那幾句人物描述裡，沒讀進去，後面就只能用猜的。

所以我會說：persona 不是設計流程裡那個「軟軟的、做做樣子」的步驟。它是你後面所有硬技術判斷的源頭。

---

把人寫成人，不要寫成需求清單

新手最常犯的一個錯，是把 persona 寫成「系統要做什麼」的功能列表。寫出來像這樣：「使用者可以登入、可以下單、可以查訂單。」這不是 persona，這是 spec。persona 要寫的是人——他是誰、想幹嘛、在什麼狀況下用、容忍度到哪。功能是後面 user story 的事，這篇先別搶。

一個能用的 persona，腦袋裡至少要裝這幾件事：

這個人是誰，給他一個會黏在記憶裡的標籤，像「Lily，28 歲，通勤族，手機重度使用者」——有畫面，討論起來大家都知道在講誰。他用系統想達成什麼目標，這是 persona 的核心，其他都是為了支撐這件事。他多常用、在什麼情境下用，每天還是每月、通勤滑手機還是辦公室盯著螢幕，差很多。他用什麼裝置、什麼網路，手機 4G 偶爾斷訊，跟辦公室有線網路，對你的設計是兩種世界。他對延遲、正確性、可用性各能忍到哪——也就是非功能需求的敏感度，這條之後會直接變成 SLO 的依據。最後，他會碰到什麼層級的資料，是個資、支付卡資訊、還是醫療資料，這條一寫下去，儲存跟加密的選項當場就被砍掉一半。

關於最後那條資料分類，三個縮寫你在考場上會反覆看到：PII（Personally Identifiable Information，個人可識別資訊，例如姓名、地址、Email）、PCI（Payment Card Industry，支付卡資訊，受 PCI DSS 規範）、PHI（Protected Health Information，受 HIPAA 保護的醫療資料）。看到 persona 會碰 PHI，你心裡就該響警報——這條路後面接的是合規紅線，不是隨便挑個資料庫就好。

📝 考場提點

看到題目描述某個角色「每週登入一次」「凌晨跑批次」「每月拉報表」，別當廢話跳過——這通常就是後面選型題的伏筆。讀題時順手把每個出現的角色圈出來，旁邊標一句「他在意什麼」。後面遇到「該選 Cloud Run 還是 GKE」這種題，先回頭認人：是即時互動的前台使用者、還是排程觸發的後台工作？認對人，選項自己就收斂了。

---

過多跟過少，都是病

寫了十五個 persona 的設計，我看過，那種文件沒人讀得完，重點全糊掉，到頭來每個角色都顧一點、每個都顧不好。反過來，只寫一個「消費者」就收工的也很危險，因為真正會搞死你架構的，往往不是消費者，是那些你沒寫進去的角色。

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

內部使用者就是管理後台、客服、資料分析師這群人。他們不是你的客戶，所以新手很容易忘了他們存在。但 PCA 特別愛考這塊——分析師要怎麼查資料、管理員的操作要不要稽核、客服要不要看得到訂單明細，每一個都牽動架構。我看過不少團隊，前台做得漂漂亮亮，結果分析師沒有像樣的查詢介面，只能每天手動從正式資料庫撈，重的查詢一跑，線上交易跟著卡。這就是漏掉內部 persona 的代價。

非人類 persona 更隱形：凌晨的批次排程、合作夥伴打進來的 API、第三方 SaaS 的 webhook。它們沒有臉，但它們有流量、有失敗模式、有 SLA，照樣會逼你做架構決策。一個外部系統每天凌晨三點灌一批資料進來，跟一個消費者隨機點兩下，對系統的壓力型態天差地遠——前者要的是穩定的吞吐跟失敗重試，後者要的是低延遲跟快取。把它們混在一起想，架構一定走鐘。

數量上沒有魔法數字，但一個中型系統抓 4 到 6 個核心 persona，通常剛剛好：涵蓋得到關鍵角色，又不會多到失焦。

---

每個 persona，逼問自己五件事

把每個角色寫成卡片之後，別急著進下一步，先拿這五個問題輪一遍。這幾題我自己在真實提案前也是這樣盤的，不是考試專用。

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

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

他失敗的時候會怎樣？ 這題最容易被忽略，卻最重要。消費者看不到商品頂多跳去別家，惱人但不致命；但會計結帳對帳失敗、或合規日誌沒寫進去，那是會出大事、要報警、可能違規的等級。失敗的代價不一樣，你願意為它砸的可用性成本就不一樣。

他對成本的影響是什麼？ 一百萬個免費會員瘋狂讀取，跟一百個企業客戶高頻打 API，背後的計算資源模型完全是兩回事。沒先想清楚誰在燒錢，成本估算後面一定爆。

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

📝 考場提點

「失敗時會怎樣」這條，是區分高分跟普通答案的分水嶺。題目給你一個角色，先在腦中跑一遍他的失敗情境，你就能判斷該配多高的可用性、要不要做非同步重試、要不要拉出獨立的服務。一個常見陷阱題，是把所有角色都套到 99.99%——看起來很安全，其實是過度設計，會被扣分。記住：可用性是花錢買的，只買在會痛的地方。

---

走一遍範例 — 登雲書店

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

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

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

阿元就是典型的「快不快、會走不會走」族群。他碰到 PCI 跟 PII，所以他這條線後面一定牽扯到金流合規，不是隨便擺。

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

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

小葵跟阿元都是消費者，但敏感的點不一樣：阿元怕結帳卡，小葵怕進度掉。同樣是「消費者」，拆開來看，後面的設計就完全不同——這就是為什麼不能只寫一個 persona。

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

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

這就是典型的非人類 persona。它不在乎你首頁快不快，它在乎這批資料有沒有完整、正確、可追溯地進去。失敗模式也跟人不一樣——人會重試，系統不會，所以你得替它設計重試與告警。

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

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

Marcus 就是前面講的「最容易被漏掉的內部使用者」。注意他的容忍度跟阿元剛好相反：他不要求即時，D+1 的資料他收，查詢慢一點也認。這條訊息超級重要——它等於明示你「不要拿正式交易資料庫去扛他的分析查詢」。

寫到這裡，你應該已經隱約看到後面選型的輪廓了：阿元跟小葵要的是貼近使用者的全球前緣快取；天下出版要的是一條穩當、會重試、可追溯的非同步批次管線；Marcus 則明顯指向 BigQuery 這類分析型儲存，跟線上交易完全分開。

這裡借這個例子講一個我在真實案子裡看到太多次的反模式：把所有東西塞進同一個 Cloud SQL。前台交易、後台分析、報表查詢全擠在一個資料庫，剛上線都很好，量一上來，Marcus 一跑月報，重查詢吃光連線跟 I/O，阿元的結帳跟著變慢甚至逾時。事後回頭看，根本原因不是資料庫選錯，是當初沒把「交易型使用者」跟「分析型使用者」當成兩種 persona 分開設計。persona 拆乾淨，這種坑你在白板階段就避掉了。

---

別把每個人都當 VIP

最後提醒一個很實際的取捨：不是每個 persona 都值得頂規。

Marcus 的報表，D+1、可以慢，硬要給他 99.99% 可用性、即時資料、多區複製，純粹是把預算燒在沒人會感謝的地方。在真實專案裡這叫超支，在考場上這叫過度設計，兩邊都會被打。架構師的價值不是「全部都做到最好」，而是判斷哪個角色的哪個指標真的要顧、哪個可以省——這份判斷力，正是從 persona 來的。

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

---

延伸閱讀

• Design Thinking for Architects — GCP Docs — 官方提到的「以使用者為中心」設計思路。
• Nielsen Norman Group — Persona Definition — 業界最常被引用的 persona 方法論。
• Google SRE Workbook — Ch. 2 Implementing SLOs — 講如何把使用者期望轉成 SLO，正好接下一篇。

---

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

🎯 換你練習

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