PCA 雲端架構師之旅 03 — 撰寫 User Stories

上一篇把人畫出來了——你知道阿元是誰、小葵在意什麼。但 persona 只回答了「誰」，沒回答「他到底想做什麼、做成了長什麼樣」。這一篇就是把人翻譯成系統要做的事。

很多人一聽到 User Story 就皺眉，覺得那是敏捷開發、是 PM 在 Jira 上拉卡片的東西，跟架構師沒關係。這是個會讓你後面一路吃虧的誤會。在 PCA 的設計流程裡，user story 是地基中的地基：你後面要訂的 SLO、要切的微服務、要設計的 API，全都從這裡長出來。沒有它，每一步都只能憑感覺。

這是 PCA 雲端架構師之旅 的第三步。上一篇 02 · User Personas。

---

考題不會跟你說「這是一個 user story」

PCA 的 case study 滿滿都是 user story，只是它從來不會貼標籤。它會寫成「業務希望使用者在 2 秒內看到首頁」「資料分析師每天早上需要前一天的銷售報表」這種一句話帶過的敘述，藏在落落長的需求段落裡。

你要做的，是看到這種句子就自動在腦中把它拆成「誰 + 想做什麼 + 成功的標準是什麼」。為什麼這很要命？因為考題後面常常就是拿這句話來考你選服務、選數字。一句「分析師每天早上需要前一天的報表」，背後考的是 D+1 的資料新鮮度、是批次而非即時、是 BigQuery 而不是 Spanner。你要是讀漏了「每天早上」「前一天」這幾個字，很可能就去選了一個又貴又即時的方案，看起來很厲害，其實答非所問。

我看過不少剛入行的人在讀需求時的毛病：把每句話都當成「待辦清單」掃過去，掃完只記得「要快、要穩、要報表」。但架構師的本事就在於從同一句話裡讀出別人讀不到的量化線索——「2 秒」是 P 幾的 2 秒？「每天早上」幾點前要好？這些數字差一個級距，整套架構就換一套服務。

📝 考場提點

看到「使用者希望……」「業務需要……」「分析師每天……」這種句子，先在草稿紙上把它還原成「角色 / 動作 / 量化標準」三欄。特別盯緊三類字眼：時間（2 秒、每天早上、即時 vs 隔天）、頻率（每筆 vs 批次）、容忍度（不能中斷 vs 可以慢一點）。考題最愛在這裡偷換——把 RPO 寫得像 RTO、把「分析查詢」混進「線上交易」，你只要把句子拆乾淨，這些陷阱就現形了。

---

一個能用的 User Story 長什麼樣

骨架其實就一句話：「身為 <角色>，我想要 <目的>，以便 <好處>。」 角色對應到上一篇的某個 persona，目的是他想做的事，好處說明為什麼值得做。

但這句話只是開頭。真正讓架構師能動工的，是後面那組驗收條件（acceptance criteria）——「成功長什麼樣」。寫驗收條件最常用的是 Given/When/Then 這種寫法，意思就是「給定某個前置狀態、當使用者做了某個動作、就該得到某個結果」。它原本是 BDD（Behavior Driven Development，行為驅動開發）在用的，但你不用管它的學派來歷，把它當成一個逼你把「成功」講清楚的格式就好。

舉個對比你就懂差別在哪：

• 「使用者可以快速看到商品」——這不是 user story，這是願望。快是多快？P95 還是平均？空庫存的商品要不要顯示？通通沒講。
• 「身為消費者，我想要在首頁 P95 1.5 秒內看到 Top 10 暢銷榜，以便快速決定要買什麼；庫存為零的商品仍要顯示但標註缺貨」——這才是能餵給下一步的東西。它有角色、有目的、有可以拿尺量的標準。

差別就在那個「可以拿尺量」。一個寫得好的 user story，到了下一篇定 SLO 的時候，你幾乎是把驗收條件裡的數字直接搬過去。寫得爛的，到那一步你還得回頭重猜一次需求。

---

三種一寫就壞掉的 user story

過來人經驗：絕大多數寫壞的 user story 都逃不出這三種。

第一種，把解法寫成需求。 「系統要用 Pub/Sub 接收訊息」「我要用 Memorystore 快取熱門商品」——這些都是 how，不是 what。User story 只該講「使用者要達成什麼」，至於用什麼服務去達成，是你後面選型的事。一旦你在故事階段就把 Pub/Sub 寫死，等於提早幫自己關掉了其他選項，後面想換還得先說服自己「當初為什麼這樣寫」。考試也一樣：題目給你的是需求，你的工作是選服務；你要是把服務當需求讀，整個推理鏈就反了。

第二種，沒有驗收條件，或寫得跟沒寫一樣。 「要快」「要穩」「體驗要好」——這種詞放進驗收條件等於沒寫。下一步要定 SLO，你拿「要快」去定，定不出任何數字。驗收條件的價值就在於它逼你把模糊的形容詞換成百分位數加時間：不是「要快」，是「P95 1.5 秒」。

第三種，一個故事包山包海。 「使用者可以購物」聽起來很完整，但它其實是三四個故事擠在一起：瀏覽、加入購物車、結帳、查訂單。這幾件事的 SLO 天差地遠——瀏覽掛了頂多體驗差，結帳掛了是真的在掉錢。把它們綁成一個故事，你就沒辦法給結帳訂一個比瀏覽嚴格得多的可用性。實務上有個簡單的判準：如果一個故事跨了好幾個服務、或者它失敗時「痛的程度」明顯分好幾種，那它就該拆。

還有一個容易整批漏掉的：非功能性的故事。大家寫 user story 很自然會寫「我想做什麼」，卻很少寫「我不想遇到什麼」。但「我不想等超過 5 秒」「我不想看到 500 錯誤頁」「付款失敗時我絕對不能被重複扣款」這些，同樣是 user story，而且往往是架構裡最難、最值錢的部分。我見過太多設計只顧著把 happy path 做漂亮，第一次遇到區域故障或重複請求就原形畢露——因為當初根本沒人把「失敗的時候該怎樣」寫成一條故事。

---

走一遍範例 — 登雲書店

回到我們的主線。前面替每個 persona 畫好了輪廓，現在替他們各寫 2–3 個核心 user story。重點不在數量，在於每一條都帶著可以驗收的標準——因為這些標準，就是下一篇 SLO 的原料。

消費者阿元

故事 3.1 · 瀏覽暢銷榜

身為一般消費者阿元，我想要在首頁看到即時暢銷榜，以便快速決定要買什麼。

驗收條件：

• Given 我是未登入訪客，When 我打開首頁，Then P95 在 1.5 秒內看到 Top 10。
• 暢銷榜更新延遲不超過 15 分鐘。
• 區域故障時暢銷榜仍可顯示（可接受降級為前一次快照）。

注意第三條。這就是上面講的非功能性需求——它不講「我要看暢銷榜」，它講「就算機房出事，我還是要看得到」。一旦把這條寫進故事，你後面的架構就被逼著去想跨區降級、想快取舊資料頂著用，而不是讓整頁開天窗。

故事 3.2 · 下單結帳

身為一般消費者阿元，我想要用 Apple Pay 一鍵結帳，以便不用每次輸入信用卡。

驗收條件：

• 結帳流程從按鈕到完成不超過 6 秒（P95）。
• 結帳 API 可用性 99.99%。
• 付款失敗時金流不會重複扣款（idempotent，同一筆請求重送結果不變）。
• 所有交易紀錄符合 PCI DSS 4.0.1 稽核需求。

把 3.1 跟 3.2 擺一起看，差別就出來了：暢銷榜掛了你頂多少賺幾單，結帳掛了或重複扣款是直接出事、會上新聞。所以結帳的可用性訂到 99.99%，而且特別點名 idempotent 跟 PCI DSS。這就是為什麼前面堅持要把「購物」拆開——綁在一起，你根本沒辦法給結帳這種等級的嚴格度。

電子書訂閱者小葵

故事 3.3 · 同步閱讀進度

身為訂閱者小葵，我想要換裝置時自動跳到上次看到的頁面，以便通勤跟在家看可以順順接著讀。

驗收條件：

• 換裝置後 10 秒內看到最新進度。
• 同一本書在兩台裝置同時閱讀時，以最後一次 sync 為準。
• 離線時可繼續閱讀，重新上線後 30 秒內同步。

這故事看起來人畜無害，其實是個小陷阱題的原型：「同時在兩台裝置讀」逼你想清楚衝突要怎麼解（這裡選 last-write-wins）；「離線可讀」逼你接受最終一致性。寫故事的時候把這兩條講白，後面選資料同步方案才有依據；漏了，你做出來的東西第一次遇到兩台手機搶著寫就會打架。

書商合作夥伴天下出版

故事 3.4 · 每日批次上傳庫存

身為書商合作夥伴，我想要透過 SFTP 上傳 CSV 並在 email 收到處理結果，以便知道價格是否成功更新。

驗收條件：

• 單筆 CSV 最大 200MB，處理時間 < 30 分鐘。
• 失敗時 email 包含失敗列號與原因。
• 庫存更新對消費者端可見的延遲 < 10 分鐘。

這條故事一看就知道屬於批次世界，不是即時世界——「上傳完 email 通知」「30 分鐘內處理完」，沒有任何一個字在要求即時。讀懂這個語氣很重要：它直接決定你後面會走批次處理那條路，而不是去硬搭一套即時管線。考題也常用這種「email 通知」「每日上傳」的措辭來暗示你「這裡是批次，別選即時服務」。

內部營運分析師 Marcus

故事 3.5 · 查詢昨日銷售

身為分析師 Marcus，我想要用 SQL 直接查昨日所有訂單，以便製作每週行銷報表。

驗收條件：

• 資料新鮮度 D+1（前一日 6am 前完成 ETL）。
• 查詢 1 億筆訂單聚合不超過 30 秒。
• 僅能看到去識別化後的會員 ID。

這條值得多看兩眼，因為它是最容易被誤讀的那種。Marcus 要的是「昨日」資料、做「每週」報表——這是分析場景，不是線上交易。我看過不少團隊（也看過不少考生）反射性地想「查訂單？那就連去訂單資料庫查啊」，結果一支分析師的聚合查詢掃 1 億筆，把正在處理結帳的 OLTP 資料庫拖到喘不過氣，線上交易跟著變慢。分析歸分析、交易歸交易——這條故事用「D+1」「1 億筆聚合」明明白白告訴你它該落在資料倉儲那一側。最後那條「去識別化的會員 ID」也別漏，它是合規線：分析師不需要、也不該看到能對到本人的個資。

把這 5 個故事擺在一起，你會發現它們不只是在描述功能，而是替後面每一個服務的 SLO 與行為先卡好位子：哪個要訂到 99.99%、哪個可以接受 15 分鐘延遲、哪個是批次、哪個碰個資要去識別化。下一篇定 SLO 的時候，你做的事情很大程度上就是把這裡的數字翻譯成可監控的指標。

📝 考場提點

case study 給你的需求，記得分兩個維度快速歸類：一是即時還是批次（看「立刻 / 每天 / 每週」這類字眼），二是線上交易還是分析（看「下單 / 結帳」還是「報表 / 趨勢 / 聚合」）。這兩刀切下去，一半的錯誤選項會自己排除——把分析查詢丟去打 OLTP 資料庫、或拿即時服務去處理隔天才要的批次報表，都是考題故意鋪的坑。先分類，再選服務，比硬背哪個服務適合哪個情境穩得多。

---

延伸閱讀

• Google Cloud Architecture Framework — Define Reliability Requirements — 官方建議從使用者期望開始定義可靠度。
• SRE Book — Chapter 4 Service Level Objectives — 把 user story 轉成 SLI/SLO 的標準作法。
• Atlassian — User Story Examples — 結構與範例參考。

---

下一步：故事有了可以拿尺量的驗收條件，就能正式把它變成 SLO 與 SLI，讓期望成為可以監控、可以被告警叫醒的指標。

🎯 換你練習

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