# CloudMart 架構評審工作紙

版本：2026-10-28

CloudMart、所有量測值、事件與目標都是本站編寫的合成演練，不是 Google 官方案例、產品效能、SLA 或真實部署紀錄。本練習不需要雲端帳號，也不執行切換或建立資源。

先寫初稿，再逐張讀證據，保留修訂理由。本工作紙不含參考判讀，也不會自行儲存或上傳答案。

## 案例事實

- 台灣電商，服務台灣與部分東南亞客戶，18 個月內規劃擴張亞太市場。
- 地端 VMware 上的 Java 單體、2 TB MySQL 8.0；訂單、庫存與商品共用 schema。
- 團隊熟悉 Java、SQL、Docker，Kubernetes 經驗有限；不能一次重寫整套應用。
- 促銷尖峰約為平日十倍；曾因資料庫連線耗盡停止結帳。
- 下列證據是不同測試或決策回合，E1 與 E2 不是同一批流量，不能合併分母。

## 本輪已核准的演練目標

- 成功率：30 天有效邏輯結帳的 99.95%。以 checkout_id 去重，明確使用者輸入錯誤才排除；5xx 與尚未確認結果的逾時仍納入失敗。
- 延遲：尖峰時台灣與新加坡各自的端到端結帳 p95 都小於 800 ms。E2 使用 nearest-rank：將 n 筆排序，取第 ceil(0.95 × n) 筆。
- 資料完整性：確認訂單不得讓權威庫存低於零；付款、訂單與庫存結果需可對帳。
- 區域災害：故障後 60 分鐘內恢復新單，且完成本輪定義的未決付款／庫存對帳；可復原資料點落後故障時刻不超過 5 分鐘。
- 上述是本次假設業務負責人已核准的演練條件。資料落地、法規適用、變更窗口與新市場細部延遲仍須另行確認，不能推定已核准。

## 證據資料

### E1：成功率的分母與驗證視窗

一小時合成負載測試；每列互斥且已依 checkout_id 去重，所有結果均在本輪觀察期限結束後分類。

| 結果 | 邏輯結帳數 | 是否納入有效事件 |
| --- | --- | --- |
| 成功完成 | 97,880 | 納入成功 |
| 服務 5xx | 70 | 納入失敗 |
| 逾時且結果尚未確認 | 50 | 納入失敗，另需付款／訂單對帳 |
| 明確使用者輸入錯誤 | 2,000 | 依已核准規則排除 |

任務：算出有效事件、成功率與同樣本量下的錯誤預算。能否由這一小時宣告達成 30 天 SLO？ADR 的上線條件要改什麼？

我的判讀／計算：

需修訂的決策與下一個驗證：


### E2：總體 p95 掩蓋小區域

另一輪尖峰負載的 10,000 筆完整結帳觀測；每筆有效事件各觀測一次且本輪全部完成。表格以相同延遲分組，不能把兩地的 p95 直接平均。

| 使用者位置 | 筆數 | 每筆端到端延遲 |
| --- | --- | --- |
| 台灣 | 8,900 | 650 ms |
| 台灣 | 100 | 900 ms |
| 新加坡 | 900 | 500 ms |
| 新加坡 | 100 | 1,200 ms |

任務：依 nearest-rank 算出台灣、新加坡與合併 p95。若只展示合併值，能否證明兩地都滿足 < 800 ms？接下來應量哪一段？

我的判讀／計算：

需修訂的決策與下一個驗證：


### E3：擴容前先算下游連線預算

以下上限是這次容量評估的合成配置，不是任何 Cloud SQL 規格的通用值；每個應用 instance 的所有 worker 合計最多 25 個連線。

| 配置／預算 | 數值 |
| --- | --- |
| 資料庫本輪核准連線預算 | 300 |
| 保留給管理、遷移及其他工作 | 80 |
| 每 instance 的應用 pool 上界 | 25 |
| 原方案規劃的 instance 上限 | 40 |
| 待評估的較小 instance 上限 | 8 |

任務：原配置在 pool 都用滿時會發生什麼？改成 8 個 instance 是否就能宣告促銷容量足夠？列出必要的防護與重測。

我的判讀／計算：

需修訂的決策與下一個驗證：


### E4：服務可連線不等於業務已復原

合成的區域故障演練，時間均為同日 UTC；依本輪事前定義，RTO 結束點包含新單恢復與未決付款／庫存對帳完成。

| 事件 | UTC 時刻 |
| --- | --- |
| 復原資料中最後確認一致的資料點 | 09:52 |
| 主要區域故障 | 10:00 |
| 次要區域資料庫可寫 | 10:22 |
| 應用路由切換完成 | 10:29 |
| 新結帳檢查通過 | 10:47 |
| 未決付款／庫存對帳完成 | 11:05 |

任務：分開計算新單恢復、業務 RTO 與資料點落後時間。是否通過 60 分鐘／5 分鐘目標？還缺什麼證據才能推算遺失訂單？

我的判讀／計算：

需修訂的決策與下一個驗證：


### E5：開始寫新資料之後怎麼回復

這是評審提供的切換情境，不是可執行操作指令；任何正式變更仍需核准窗口與測試過的程序。

| 時點／條件 | 合成紀錄 |
| --- | --- |
| 切換前 | 來源停止寫入，目標已追平至核對點；來源保留唯讀 |
| 切換後 | 新目標已接受 15 筆新訂單及相關庫存異動 |
| 可用備份 | 只有切換前備份；沒有已驗證的反向同步／重播程序 |
| 候選回復步驟 | 只將 DNS 指回舊應用與舊資料庫 |

任務：可否把候選步驟寫成「一鍵回滾」？區分新目標寫入前後的回復界線，列出停止條件、對帳與核准人。

我的判讀／計算：

需修訂的決策與下一個驗證：


### E6：新需求觸發重評，不抹掉舊證據

另一個決策回合：業務核准未來兩地同時接單、同一份庫存仍不得超賣。尚未核准跨區交易延遲、故障時接受的行為或改造預算。

| 狀態 | 新增資訊 |
| --- | --- |
| 已核准 | 未來兩地同時寫入訂單，庫存仍需一致且不得超賣 |
| 仍未知 | 可接受跨區寫入延遲、區域失聯時是否暫停接單、改造預算 |
| 現有 ADR | 低變更 Phase 1 以 Cloud SQL 為候選，未承諾全球 multi-writer |

任務：哪些舊決策仍有依據，哪些必須重開 ADR？是否能只憑這張卡立即核准全面改用 Spanner？

我的判讀／計算：

需修訂的決策與下一個驗證：

## 四份交付物

### 需求與證據矩陣

- 至少六列需求；標出事實、已核准目標、假設與未知
- 每列有範圍、負責人、驗證方法與 E1–E6 證據／缺口

初稿：

| ID | 類型／狀態 | 範圍與條件 | 負責人 | 驗證方法 | 證據或缺口 |
| --- | --- | --- | --- | --- | --- |
| R1 | | | | | |
| R2 | | | | | |
| R3 | | | | | |
| R4 | | | | | |
| R5 | | | | | |
| R6 | | | | | |

證據回合後的修訂與理由：


### 兩個候選與取捨

- 分開 Phase 1 與長期目標，不以產品名稱代替限制比較
- 至少兩個候選對照容量、資料一致性、故障、團隊與成本假設

初稿：

| 候選 | Phase 1／長期範圍 | 滿足的限制 | 新增負擔與成本假設 | 尚待驗證 |
| --- | --- | --- | --- | --- |
| 候選 A | | | | |
| 候選 B | | | | |

證據回合後的修訂與理由：


### 有狀態的 ADR

- 狀態、情境、候選、決策、後果、證據與未通過條件
- 寫出何時重評；E6 後標出保留、修訂及取代的部分

初稿：

- Status: Proposed（待驗證；通過哪些條件後才可改狀態？）
- Context／已核准條件：
- Decision／本輪傾向：
- Alternatives／捨棄理由：
- Consequences／接受的限制：
- Evidence／通過、未通過與未知：
- No-go／停止與暫緩條件：
- Review trigger／何時重評：

證據回合後的修訂與理由：


### 遷移與驗證計畫

- 切換前後各有 go/no-go、核准人、觀測點與停止條件
- 區分新寫入前後的回復；包含付款／庫存對帳及復原後回切

初稿：

| 階段 | 核准人 | Go／no-go | 觀測與對帳 | 停止條件 | 回復或修復前進的驗證 |
| --- | --- | --- | --- | --- | --- |
| 新目標開始寫入前 | | | | | |
| 新目標已接收寫入後 | | | | | |
| 區域故障後的恢復與回切 | | | | | |

證據回合後的修訂與理由：

## 最後評審

- 尚未達標或無證據的條件：
- 各條件的負責人與下一個驗證：
- 本輪決定（維持候選／修訂／暫緩）與核准邊界：

教材與參考判讀：https://cloudon.bobochen.dev/courses/gcp-pca/23-case-study-workshop/