用 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 制定容量计划：分情景计算并用测试核查假设