研发平台容量规划要回答的是：平台自身运行组件在未来一段时间内是否够用、何时需要扩容、由谁执行。可按“盘点资源与基线—建立容量指标—测算需求与余量—设定阈值与扩容规则—演练与复核”五步推进，规划对象限定为应用服务、数据库、缓存、存储、消息、网关等平台运行组件，周期上以年度计划配合季度滚动复核。本文给出每步的输入、动作、输出与完成标志，并附角色分工、测算示例和完成检查清单。
要点总览（TL;DR）
- 容量规划的对象是研发平台自身运行组件（应用服务、数据库、缓存、存储、消息、网关等），业务流水线编排与持续交付执行不纳入主线；周期采用年度计划加季度滚动复核。
- 按五步推进：资源盘点、指标基线、需求测算、余量设定、阈值与扩容规则，每步都要有输入、动作、输出和完成标志，避免规划停在“大概了解”。
- 角色分工解决数据来源和决策归属：运维负责盘点取数与执行，研发负责人确认业务排期，架构负责人评审余量标准，采购财务锁定预算。
- 测算用真实监控数据外推3–6个月需求，余量与阈值必须落到数值、责任人和时限；部署形态会影响资源关注点，私有化与高可用集群需分别计入容器环境占用和多节点冗余。
- 用完成检查清单逐项核对，并安排压测或演练、按季度复核，让阈值和余量随业务增长持续校准。
容量规划先定口径：管什么、按什么周期算
容量规划的第一步是划定边界。研发平台承载两类负载：一类是平台自身运行所需的组件资源，另一类是业务团队在平台上执行的流水线编排与持续交付任务。本文讨论前者，即应用服务、数据库、缓存、对象存储、消息队列、网关与负载均衡等组件的资源容量。流水线编排与交付执行属于交付效率与调度优化问题，其资源消耗若与平台共用同一资源池，可在盘点时作为一类负载单独标注，但不作为本文的规划主线。
周期上建议采用双层结构。年度容量计划确定全年资源预算、扩容批次和重大业务排期对应的资源准备；季度或月度滚动复核则根据实际监控数据修正预测，调整阈值和扩容时间点。两层之间用同一套指标口径衔接，避免年度计划做完就搁置。
规划启动前需要三类输入前提：现有部署清单（组件、部署形态、节点数量、当前配额）、可用的监控数据（至少覆盖近3–6个月的资源占用曲线）、业务排期（用户增长、项目数量、大促或集中上线等峰值事件）。缺少监控数据时，先补齐采集再测算，否则测算结果只能作为粗略参考。
| 约定项 | 内容 | 填写要求 |
|---|---|---|
| 规划对象 | 应用服务、数据库、缓存、存储、消息、网关等平台运行组件 | 逐项列出组件名称与部署形态 |
| 不纳入范围 | 业务流水线编排与持续交付执行 | 如共用资源池，单独标注负载占比 |
| 年度计划 | 资源预算、扩容批次、重大排期资源准备 | 明确审批人与生效时间 |
| 滚动复核 | 季度或月度，按监控数据修正预测 | 写明复核责任人与输出物 |
| 输入前提 | 部署清单、监控数据、业务排期 | 标注数据截止日期与来源系统 |
核心步骤：从资源盘点走到扩容规则
五个步骤按顺序推进，每步都有明确的输入、动作、输出和完成标志。完成标志的作用是判断该步是否可以结束进入下一步，避免规划停留在“大概了解”的状态。
第一步：资源盘点
输入为部署清单和配置管理系统记录。动作是逐个组件核对部署形态（单机、集群、容器化）、节点数量、当前配额（CPU核数、内存、磁盘容量）以及近一个月的实测占用峰值与均值。输出是一张组件资源清单，标注配额与实测占用的差距。完成标志是清单覆盖全部运行组件，且每个组件都有实测数据，无“待补充”项。
第二步：建立指标基线
输入为监控系统数据。动作是把容量指标落到可观测口径：CPU使用率（区分均值与峰值）、内存使用率、磁盘使用率与存储月增长量、并发用户数与数据库连接数、接口响应时间的P95或P99值。每个指标需注明采集周期和统计口径。输出是指标基线表，记录各组件当前水位。完成标志是指标与监控看板一一对应，任何人可按表取数复现。
第三步：需求测算
输入为指标基线、业务排期和增长假设。动作是按用户数、项目数、访问峰值的增长比例推算未来3–6个月的资源需求，并把已知的峰值事件（集中上线、季度评审、大版本发布）标注在时间轴上。输出是分组件、分月度的需求预测表。完成标志是预测表列出增长假设的来源，且与业务排期逐条对应。
第四步：余量设定
输入为需求预测表和组件的重要性分级。动作是为每类组件设定安全水位：核心交易或登录类服务保留更高的峰值冗余，内部工具类服务可适当收紧。余量的取值方法通常以“预测峰值×冗余系数”表达，冗余系数依据历史峰值波动幅度确定，波动大的组件取更高值。输出是余量标准表，写明每个组件的目标水位上限。完成标志是每个组件都有数值化的水位上限，并注明依据。
第五步：阈值与扩容规则
输入为余量标准表和现有告警配置。动作是设定告警阈值（如CPU持续15分钟超过70%触发预警）、扩容触发条件（达到目标水位上限或预测将在两周内触顶）、审批路径（谁审批、预算从哪出）和执行时限（触发后几个工作日内完成扩容）。输出是扩容规则文档。完成标志是每条规则都有阈值数值、责任人和时限，且经过架构或技术负责人评审。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 资源盘点 | 部署清单、配置记录 | 核对组件、部署形态、配额与实测占用 | 组件资源清单 | 全覆盖且有实测数据 |
| 指标基线 | 监控数据 | 统一CPU、内存、存储、并发、响应时间口径 | 指标基线表 | 指标与监控看板可对应复现 |
| 需求测算 | 基线、业务排期、增长假设 | 按用户数、项目数、峰值推算3–6个月需求 | 分月需求预测表 | 假设有来源、与排期对应 |
| 余量设定 | 预测表、组件分级 | 按峰值波动确定冗余系数与水位上限 | 余量标准表 | 每组件有数值上限与依据 |
| 阈值与扩容规则 | 余量标准、告警配置 | 设定阈值、触发条件、审批路径、时限 | 扩容规则文档 | 规则有数值、责任人和评审记录 |
角色分工与交付物：谁提供数据、谁做决策
容量规划常见的失败方式是数据由运维单方提供、业务排期无人确认，导致预测与实际脱节。角色分工要解决两个问题：数据从哪里来，决策由谁做。
平台运维或管理员承担取数与执行职责，包括资源盘点、监控口径维护、扩容操作实施。研发负责人或项目代表提供业务侧输入，包括未来季度的项目数量、用户增长预期和已知峰值时段。架构或技术负责人负责评审余量标准和扩容方案，判断冗余系数是否合理、扩容方式是否与架构演进一致。采购与财务确认资源预算和扩容成本，尤其在年度计划阶段需要提前锁定预算额度。
交接节点建议设在两个位置：需求测算完成后，业务输入需由研发负责人签字确认；扩容规则定稿前，方案需经架构评审。各角色的交付物按下表管理，交接时以文档状态标记完成。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 平台运维/管理员 | 资源盘点、监控口径、扩容执行 | 组件资源清单、指标基线表、扩容执行记录 | 盘点完成后提交基线 |
| 研发负责人/项目代表 | 提供业务排期与峰值预期 | 季度业务排期与增长预期说明 | 需求测算前确认 |
| 架构/技术负责人 | 评审余量标准与扩容方案 | 评审意见与定稿的余量标准 | 扩容规则定稿前 |
| 采购与财务 | 确认资源预算与扩容成本 | 预算确认单 | 年度计划审批时 |
这些排期确认、评审意见和扩容任务本身需要有承载位置。ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统；高可用集群部署基于高可用架构运行，可实现故障转移、数据容灾和零停机服务升级。对于容量规划中的管理动作，业务排期可作为需求或计划条目进入项目，扩容任务按工作项流转并记录审批与执行状态，季度复核结论沉淀为文档，使“谁在何时确认了什么”可追溯。部署形态的选择会影响资源关注点：私有化部署需把容器化运行环境和内部系统对接的占用计入盘点，高可用集群部署需为多节点冗余预留资源。
示例：一次季度容量测算怎么落地
以下为演示情景，数值均为假设，用于说明测算过程，实际使用时需替换为真实监控数据。
背景与假设。某研发平台服务约800名研发用户，在运行项目约120个。应用服务为4节点集群，每节点8核16GB；数据库为双节点主备，16核64GB；对象存储当前使用6TB。近三个月监控显示：应用服务CPU峰值62%、均值38%；数据库CPU峰值55%；存储月增长约400GB。下季度计划新接入两个事业部，预计用户数增长15%，项目数增长20%，并有一次全平台版本发布。
取数与基线。从监控导出近90天数据，按周统计峰值，取最高周峰值作为基线：应用服务CPU峰值62%，数据库连接数峰值约420，接口响应时间P95为380毫秒。存储按400GB/月线性外推。
增长预测与余量测算。用户增长15%、项目增长20%，按历史弹性系数估算应用服务CPU峰值上升约10–12个百分点，达到72%–74%；数据库连接数峰值预计增至约500。存储三个月后约7.2TB。若核心服务目标水位上限设为75%，应用服务已接近上限，需在下季度版本发布前扩容一个节点；数据库连接数上限按当前配置的80%即约560计，尚有余量但需纳入监控。存储按当前增速可在两个月内触发扩容，建议提前采购。
阈值与扩容动作。设定应用服务CPU持续15分钟超过70%触发预警，达到75%启动扩容审批；存储使用率超过80%触发扩容。扩容任务由平台运维创建，架构负责人审批，采购确认预算，执行时限为触发后5个工作日内完成。版本发布前安排一次压测，验证扩容后节点承载能力。
适用边界。该示例适用于用户和项目规模稳定增长的平台；若存在突发性大规模接入或业务模式变化，增长假设需重新校准。冗余系数、水位上限和响应时限均为示例取值，应结合组件重要性和历史波动调整。
完成检查：容量规划是否可执行的核对项
规划文档完成后，用以下清单逐项核对。全部通过，说明规划具备执行和复核条件；存在未通过项，应回到对应步骤补齐。
- 指标口径与监控数据对齐：每个容量指标都能在监控系统中找到对应数据源，统计周期和计算方式一致。
- 余量与阈值有明确数值：每个组件都有目标水位上限和告警阈值，数值旁注明依据。
- 责任人明确到岗：取数、测算、审批、执行各环节都有具体责任人，不写“相关团队”。
- 扩容路径完整：触发条件、审批路径、预算来源和执行时限四项齐全。
- 复核周期写入计划：季度或月度复核的时间点、参与人和输出物已约定。
- 触发式复核有定义：业务重大变化、峰值事件前后应启动临时复核，触发条件已写明。
- 压测或演练留有记录：验证扩容方案有效性的压测结果或演练记录已归档，包含时间、参与人和结论。
- 规划文档有版本和审批：文档标注版本号、定稿日期和审批人，后续修订可追溯。
核对通过后，把规划中的排期确认、扩容任务和复核结论纳入日常管理流程，按季度滚动更新。容量规划的价值在于持续校准，一次测算的结论会随业务增长和架构调整变化，定期复核才能让阈值和余量保持有效。
常见问题
平台监控数据不足3个月，容量规划还能做吗？
可以先做，但要降低结论的精度并标注数据缺口。做法是：用现有数据中可获得的峰值作为临时基线，同时启动监控采集补齐关键指标（CPU、内存、存储增长、并发与连接数、接口响应时间）；在需求测算表中注明哪些指标基于不足3个月的数据，哪些是估算值。等采集满一个完整业务周期后，用新数据回填并修正余量标准。若平台即将面临集中上线等峰值事件，建议先安排一次压测获取实测承载数据，作为临时基线的补充。
业务排期经常变动，容量预测怎么跟上？
把预测拆成“稳定增长”和“事件驱动”两部分。稳定增长按用户数、项目数的历史趋势外推，变动影响较小；事件驱动部分对应集中上线、大版本发布等已知峰值，逐条挂在业务排期上，排期调整时同步更新对应条目。同时设定触发式复核条件，例如新增事业部接入、项目数单季度增长超过约定比例时启动临时测算。这样日常按季度滚动复核，重大变化时临时校准，避免每次排期变动都重做全量测算。
扩容审批流程长，触发阈值后来不及扩容怎么办？
把“预警”和“扩容”分成两级处理。预警阈值设在目标水位上限之下，留出审批和执行的时间窗口；达到预警时即启动预算确认和方案评审，达到上限时直接执行已批准的扩容。对核心服务可预先申请一定额度的弹性预算，授权运维在阈值触发后先行扩容、事后补审批记录。同时把执行时限写进扩容规则（例如触发后5个工作日内完成），并在季度复核时检查实际执行是否超时，据此调整预警提前量。
私有化部署和高可用集群部署，容量规划的关注点有什么不同？
私有化部署需要把容器化运行环境本身的资源占用计入盘点，并考虑与企业内部系统（如 LDAP）对接带来的额外负载；高可用集群部署则要为多节点冗余和故障转移预留资源，单节点故障时剩余节点需能承接负载，因此水位上限通常设得更保守。ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统；高可用集群部署基于高可用架构运行，可实现故障转移、数据容灾和零停机服务升级。具体资源规格与节点数量需结合官方部署要求确认后再填入测算表。
容量规划做完后，怎么保证它不变成一份存档文档？
关键是让规划中的动作进入日常管理流程：排期确认作为计划条目、扩容任务按工作项流转并记录审批与执行状态、季度复核结论沉淀为文档，使每次确认和调整都可追溯。ONES 支持私有部署和公有云部署，这类管理动作可以在平台内承载。另外在完成检查清单中约定复核时间点、参与人和输出物，并把压测或演练记录归档；下一次复核时先比对上次预测与实际监控数据的偏差，偏差过大就修正增长假设和冗余系数。
