系統規劃（三）：容量規劃用算的、上線計畫用清單的

容量規劃用算的、上線計畫用清單的

一句話總結：容量規劃靠數字不靠直覺，上線靠清單不靠祈禱。

結論先講：「先開兩台 server 應該夠了吧」——每一個說過這句話的人，後來都在半夜被 PagerDuty 叫起來。

容量規劃：讓數字替你說話

容量規劃這件事，很多人的做法是「憑經驗抓個大概」。問題是，你的經驗是上一個專案的經驗，而每個專案的流量模式、資料量、使用行為都不一樣。用上一個專案的直覺來規劃這一個專案的容量，就像用台北的天氣來準備高雄的穿著。

正確的做法是：從用戶數開始，一路推算到需要多少機器。

從 DAU 推算 QPS

假設你的系統預期有 10 萬日活用戶：

DAU = 100,000
每用戶每日平均請求 = 20 次
每日總請求 = 2,000,000

平均 QPS = 2,000,000 / 86,400 ≈ 23
峰值係數 3x → 峰值 QPS ≈ 70
安全係數 2x → 設計目標 QPS = 140

看到了嗎？10 萬 DAU 聽起來很大，但算出來其實才 140 QPS。數字會幫你消除恐懼，也會幫你避免過度配置。

反過來，如果你的業務場景是搶票、閃購那種瞬間爆量的，峰值係數可能不是 3x 而是 50x，那就是完全不同的故事了。所以關鍵不在公式，在於你對業務場景的理解。

資料庫容量：算出三年後的你需要什麼

每筆訂單 ≈ 500 bytes
每日新增 = 10,000 筆
每日增量 = 5 MB
每月 = 150 MB
每年 = 1.8 GB
加上索引 1.5x = 2.7 GB/年
三年 = 8.1 GB

8 GB？聽起來根本不多對吧。但這只是訂單資料，加上日誌、快取、圖片儲存，數字會快速膨脹。重點是：每一項都要算，不要用感覺。

頻寬：別忘了 CDN 幫你扛了多少

平均頁面大小 = 2 MB
峰值 QPS = 140
原始頻寬需求 = 280 MB/s ≈ 2.24 Gbps

CDN 快取命中率 80%：
實際源站頻寬 = 0.448 Gbps ≈ 450 Mbps

如果沒有 CDN，你的源站要扛 2.24 Gbps——這不是一般機房能處理的。所以 CDN 不是「加分題」，是「必考題」。

資源對應表：把數字變成採購單

算完以上這些，就能產出一張資源規劃表。這張表的價值在於：它讓你跟基礎設施團隊（或雲端供應商）的對話有依據，而不是「你幫我開幾台看看夠不夠」。

開發計畫：把大象切成牛排

有了需求、架構、容量規劃，下一步是把工作拆解成可執行的任務。

WBS：分到一個人一個 Sprint 能做完

WBS（Work Breakdown Structure）的原則就是不斷拆分，直到每個任務都小到可以被一個人在一個 sprint 內完成。

為什麼要這麼做？因為粒度太粗的任務根本無法追蹤進度。「開發用戶模組」這種任務，你問進度，得到的回答永遠是「差不多了」。但如果拆成「註冊 API」「登入 API」「JWT Token 管理」，每一個都是明確的完成或未完成，沒有模糊空間。

Sprint 規劃：先求有再求好

常見的 Sprint 安排邏輯：

第一個 Sprint：基礎建設 + 最核心的模組。Sprint 結束時要有一個可跑的 staging 環境
中間的 Sprint：核心功能開發 + 前後端整合
倒數第二個 Sprint：測試、修 bug、效能優化
最後一個 Sprint：上線準備 + 正式發布

注意最後一定要留整個 sprint 做上線準備。我見過太多團隊把最後一個 sprint 塞滿功能開發，然後上線那天才開始處理部署問題。

風險管理：先把最壞的情況想過一遍

不是悲觀，是務實。你至少要想過這些：

關鍵工程師突然離職 → 每個模組至少兩人熟悉
第三方 API 延遲交付 → 準備 Mock Server，設計抽象層
需求不斷膨脹 → PRD freeze + 正式的 Change Request 流程
效能達不到標準 → 提前做 Load Testing，預留優化時間

風險管理不是「等出事再說」，是「出事的時候抽屜裡已經有 Plan B」。

上線計畫：最後一哩路，也是最危險的一段

上線不是按一個 deploy 按鈕就好了。它是風險最集中的階段，需要一份嚴謹的清單。

Pre-Launch Checklist

把該檢查的事項全部列出來，一項一項勾。不要靠記憶，記憶會在壓力下背叛你：

程式碼品質：

Code Review 全數完成？
測試覆蓋率達標？
安全掃描無 Critical 漏洞？

基礎設施：

Production 環境已部署且通過 smoke test？
DB migration 在 staging 驗證過？
SSL、DNS、CDN 都確認了？

監控告警：

應用層、基礎設施層的監控都設好了？
告警規則設定了，通知管道也測試過了？
Dashboard 準備好了？

溝通：

所有利害關係人都知道上線時間？
客服團隊完成培訓了？

每一項都是血淚教訓。少勾一項，就是多一個上線當天爆炸的可能。

回滾計畫：你的安全網

回滾計畫回答一個問題：如果上線出事了，怎麼在最短時間內恢復？

你需要事先定義好：

觸發條件：錯誤率超過 5%？P99 回應時間超過 2 秒？核心功能掛掉？
回滾步驟：寫成逐步操作的 runbook，讓任何 on-call 工程師都能照做
資料處理：如果有 schema 變更，回滾時資料怎麼辦？
驗證方式：回滾完怎麼確認系統恢復正常？
時間預算：回滾應該在多久內完成？超時就要升級處理

沒有回滾計畫就上線，就像不帶降落傘就跳傘——你只有一次機會，而且沒有容錯空間。

常見的坑，你踩過幾個？

過度規劃：花三個月規劃，市場窗口關了。規劃時間不要超過總開發時間的 20%。

文件沒人看：文件寫了等於沒寫？那是因為文件太長或沒嵌入流程。把 Tech Spec 連結放進 PR template 裡，強制每次開 PR 都要對照。

需求持續變更：PRD 在進入開發後要設 freeze date，後續變更走 Change Request 流程。

容量靠猜的：「先開兩台看看」不是規劃，是賭博。任何容量決策都要有數字依據。

系列回顧

三篇走完了系統規劃的六個階段：

階段	核心問題	產出
需求收集	做什麼？為誰做？	PRD
技術選型	用什麼技術？	ADR
架構設計	怎麼做？	Technical Spec
容量規劃	需要多少資源？	資源估算表
開發計畫	什麼時候做完？	WBS + Sprint Plan
上線計畫	怎麼安全上線？	Launch Checklist

最重要的不是嚴格遵守每一步，而是建立「在動手之前先想清楚」的習慣。規劃的深度可以根據專案大小調整，但規劃本身不應該缺席。

系列文章：

系統規劃（一）：需求收集
系統規劃（二）：技術選型與架構設計
你在這裡 → 系統規劃（三）：容量規劃、開發計畫與上線

Terry Yao's Blog

分類

目錄