用 AI 制定容量計劃，先定單位、服務目標，凍結需求供應，以明確公式計情景、驗假設。AI 整證據、找缺口；預測、資源量、風險、配置決定歸負責人。

依負責任的 AI 框架：有界輸入、明示不確定性、確定性計算、人工批准。

關鍵要點

容量只對具名服務、隊列、單位和時間窗口有意義。

實測資料與增長、季節性、高峰和服務時間假設必須分離。

公式、中間值、單位和捨入規則不得隱藏在模型推理中。

冗餘、依賴上限與供應提前期要進入同一情景。

承諾資源前要回測或負載測試。

觸發器必須早於服務質素明顯惡化。

甚麼是營運容量規劃？

營運容量計劃把需求連到滿足服務目標的人員、設備、空間、網絡、計算或供應商吞吐量；它是輸入、情景、公式、限制、驗證、負責人、觸發器的版本化模型，非單點預測。

Google SRE 以軟件工程處理營運，平衡可用性與變更速度［1］。容量須兼顧可靠性；忽略故障、維護、高峰的高利用率，帳面便宜卻不可靠。

欄位	應記錄內容
service/queue	精確營運邊界
unit of demand	請求、工單、訂單、作業或工作階段等計量單位
baseline window	起止日期、採樣粒度和時區
peak factor	有證據的峰值與基準關係
growth/seasonality	假設、來源、負責人和置信度
service time	每單位工作量或分布
current capacity	明確條件下的可用吞吐量
utilization/headroom	獲批准約束及理由
redundancy	故障域及故障後的剩餘容量
provisioning lead time	從批准到資源可用所需時間
dependency limit	上下游、供應商、設施或配額限制
scenario/formula	輸入、單位、表達式和輸出
validation test	回測、負載測試、試點或營運對照
owner/trigger	決策人和復審閾值

如何在容量計劃中完成容量假設核查？

步驟 1：定義容量計劃的容量單位和服務目標

選擇一個能一致量度、並能與面向用戶的結果連繫的單位。「流量」太含糊；「每五分鐘完成的 API 要求數目」或「每個當值小時解決的個案數目」才可以檢驗。寫明重試、取消、轉介、返工和被放棄的需求是否計算在內。

把單位與一個目標配對，例如最長輪候時間、完成時間、錯誤預算、資料新鮮度或可用性。不要讓模型虛構服務水平目標（SLO）。把容量模型與已批准的目標及其負責人連繫起來。

記錄時間粒度、時區、業務日曆、排除範圍和來源系統。如果兩個系統對同一項工作的計算方式不同，便同時保留兩種定義，直至負責人批准如何勾稽。

步驟 2：凍結歷史觀測窗口

匯出一份唯讀基線，記錄資料集 ID、擷取查詢或報表版本、起訖時間戳、篩選條件、欠缺的時段、事故、遷移和已知的口徑變化。保留用作勾稽的原始總數。

不要只揀平靜的時期。在相關時，納入具代表性的平日、週末、月底效應、推廣、維修和已知的高峰。標示異常事件，而不是悄悄刪去；之後的情景可以決定它們會否重現。

AI 可以為筆記分類、提出待覆核的異常，但不得改寫原始量度值。把來源觀測、清理決定和衍生指標放在不同的表中。

步驟 3：拆分需求驅動因素

列出可能改變需求的驅動因素：活躍用戶、訂單量、產品組合、地區、推出事件、日曆效應、推廣活動、客戶遷移、監管限期或依賴服務的行為。為每個因素寫明來源、有效期、負責人和不確定區間。

把相關性與可用的驅動因素分開。業務量隨某次活動上升，並不證明所有增長都由該活動造成。建立一條驗證問題，並在可行時比較不同時期或群組。

使用 KPI 定義指南令分母和負責人保持明確。容量輸入是營運量度，而不是因為看來穩定而挑選的展示指標。

步驟 4：為容量計劃建立基準、高峰與壓力情景

最少建立三個情景：

基準： 已批准的中心假設和正常運作條件。
高峰： 有量度或有根據的高需求，依賴保持正常。
壓力： 高需求再加上一項合理的故障、延誤或依賴限制。

每個情景都必須列出改變了哪些輸入，而不只是貼上「樂觀」或「嚴重」這類標籤。峰值系數應來自觀測資料或問責的規劃假設。壓力情景應寫明不可用的故障範圍、供應商配額的減少、服務時間的延長或其他限制。

Google 的「非抽象設計」練習展示了如何由具體的需求和資源要求出發，再檢查可行性和擴展極限。［2］借鏡這種嚴謹方法，但不要把它的數字照搬到無關的服務。

步驟 5：用確定性模型計算

把計算放在試算表、notebook、查詢或經審查的規劃工具中。一個簡化的服務模型可以用需求乘以服務時間得出工作量，再除以可用工作時間和已批准的使用率限制。真實的系統可能需要輪候、並行、批次、儲存、頻寬或按組合區分的模型。

為每條公式註明單位。保留中間值和捨入規則。如果模型建議了某條公式，分析員必須重新推導，並檢查量綱是否一致。禁止讓模型暗算最終資源量。

只使用所提供的觀測資料和假設。
傳回情景表和欠缺輸入清單。
不要選擇使用率、餘量、增長、冗餘或最終資源數量。
不要暗中計算；以具名欄位和單位表達公式。
在負責人批准之前，把每項預測都標為假設。

切勿索取「通用 20% 安全餘量」。合適的餘量取決於波動程度、擴容所需時間、故障行為、服務目標和決策成本。一個通用的百分比只會掩蓋不確定性，而不是管理它。

步驟 6：加入冗餘、依賴和提前期

計算扣除計劃維修和可信故障之後的可用容量。把安裝容量與可用來服務需求的容量分開。識別故障範圍，例如站點、可用區、團隊、班次、機器組別、供應商或網絡路徑。

記錄每項依賴限制：資料庫連線數目、下游速率限制、電力、冷卻、場地空間、授權席位、受過培訓的人員、交付時段或供應商配額。即使其他層級仍有富餘，實際吞吐量亦由最先觸及的那項限制決定。

AWS Well-Architected 指引強調監察需求與供給、在適當時使用彈性，並考慮取得資源所需的時間。［3］並非每種資源都能即時彈性擴展。招聘、設施、硬件、供應商合約和審批都可能需要很長的提前期，因此觸發條件必須早於預測中的短缺。

步驟 7：用證據核查容量計劃假設

為每項重要假設選擇最有力而又可行的驗證方式：

以過去的某次高峰回測公式；
在隔離環境中重播具代表性的工作負載；
進行設有明確停止條件的受控負載測試；
按約定的定義，為真實工作抽樣計時；
比較計劃和實際的資源交付提前期；
就所聲明的冗餘情況進行一次故障演練；
把容量報告與獨立的來源總數核對。

記錄測試、環境、資料集、預期結果、實際結果、偏差、決定和負責人。未經授權令共用的正式系統達到飽和，是不可接受的。保護客戶和營運資料，並在獲批准時使用具代表性的合成輸入。

步驟 8：挑戰置信度和故障路徑

就每項預測輸入，記錄可信程度、證據時效、敏感度和一項區分性檢查。透過以有界的替代值重新計算模型來排定敏感度，而不是讓 AI 憑「感覺」判斷哪個變數重要。

NIST AI RMF 建議在整個生命週期中對 AI 風險進行管治、對應、量度和管理。［4］就容量計劃而言，這代表記錄模型的使用、檢查資料轉換、評估錯誤的後果，並保留一條由人決定的界線。

請覆核人思考甚麼會令計劃出錯：遺漏的需求、重複計算、服務時間改變、隱藏的速率限制、相關連的故障、供應商延誤或無效的 SLO。把每條可信的失敗路徑轉化為測試、監察、應變計劃或明確接受的風險。

步驟 9：批准容量計劃觸發器並持續維護

發佈一份附版本號的容量計劃，包含公式、輸入、情景輸出、驗證證據、負責人決定和剩餘風險。不要把預測輸出當作承諾呈現——預測不是承諾。記錄批准了哪項資源決定，以及理由。

為覆審訂立門檻：持續的使用率、輪候延誤、錯誤預算消耗、需求增長、預測誤差、當值覆蓋、供應商分配、資源交付提前期的改變，或某項依賴接近配額。同時訂明幅度和觀測窗口，以免雜訊造成的單一數據點引起反覆變動。

每個規劃週期完結後，比較預測與實際的需求、容量、服務質素和提前期，讓誤差保持可見。透過變更控制更新假設，而不是改寫歷史。

需求壓力情景核查清單

總結

定義可測需求和服務目標。
預測前凍結歷史觀測。
暴露每個驅動因素、假設、公式和單位。
測試基準、高峰、壓力和故障條件。
納入冗餘、依賴與提前期。
由負責人批准資源與復審觸發器。

常見問題

AI 能計算最終資源量嗎？

AI 可協助表達公式和整理已核驗輸入，但最終算術應在確定性模型中運行並獨立覆核，資源決定由負責人批准。

甚麼是合適的利用率目標？

沒有通用目標。它取決於波動、擴容速度、故障容忍、服務目標、排隊行為，以及冗餘與短缺的成本。

應預留多少餘量？

使用有證據的服務專屬情景，計算高峰和可信故障時的剩餘容量。不要採用模型生成的通用比例。

如何處理季節性需求？

單獨記錄日期、來源、置信度和驗證方法，不要把季節性與長期增長合併，這樣兩者才能分別被挑戰。

自動擴縮容能替代容量規劃嗎？

不能。它仍受配額、啟動時間、下游限制、成本控制、故障域和信號準確性約束。

多久復審一次計劃？

採用固定週期加事件觸發；需求、SLO、架構、供應限制、人員或提前期實質變化時應提前復審。

歷史資料中有事故怎麼辦？

保留並標注事故，判斷是否可能重現，再放入相應情景。靜默刪除事故期會低估風險。

容量計劃與項目計劃有何不同？

容量計劃模擬需求、供給、約束和觸發器。項目計劃組織工作、日期、依賴和責任；它可以交付容量，卻不能取代容量模型。比較較宏觀的策略方案時使用情景分析，呈現已批准的財務影響時使用預算預測。

免責聲明： 本文僅提供一般營運規劃資訊，不構成工程、財務、安全或其他專業建議。承諾資源前，應在相關環境驗證假設並取得負責人批准。

來源

Google, Site Reliability Engineering: Introduction — https://sre.google/sre-book/introduction/
Google, The Site Reliability Workbook: Non-Abstract Large System Design — https://sre.google/workbook/non-abstract-design/
AWS, Well-Architected Framework — https://docs.aws.amazon.com/pdfs/wellarchitected/latest/framework/wellarchitected-framework.pdf
NIST, AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework

Sources checked 2026 年 9 月 6 日。

如何用 AI 制定容量計劃：分情景計算並以測試核查假設