研发平台容量规划要解决的是平台自身资源与业务增长之间的匹配问题：计算、存储、数据库、中间件、网络和许可证够不够用，什么时候该扩，扩多少，由谁来决定。本文面向负责研发平台运行维护的团队，按盘点基线、测算预测、设定触发、复盘校验四步展开，并给出角色分工、完整示例和完成检查清单。范围限于管理平台自身的运行容量，不涉及交付流水线的编排容量。
要点总览（TL;DR）
- 容量规划从资源清单开始：覆盖计算、存储、数据库、中间件、网络与许可证，每类资源记录当前用量、周期峰值、增长趋势、容量上限和归属团队。
- 基线取最近一个完整季度，同时保留日、周、季度三个峰值口径，并注明监控工具与采样方式，保证不同人按同一口径能复现。
- 预测用历史外推和业务规划两条线并行，稳态增长与突发峰值分开处理，所有假设和数据缺口写进假设清单。
- 为关键资源设定预警阈值与扩容触发条件，把申请、评审、执行、验证四个节点对应到平台运维、研发团队负责人、采购财务和平台负责人。
- 用月度或季度复盘校验预测偏差，优先检查偏差最大的资源项，让容量规划随业务节奏持续更新。
容量规划先盘清什么：平台资源清单与基线
容量规划的第一步是把平台“用了什么、用了多少、谁在用”记录下来。没有这份清单，后续的预测和扩容决策都缺少依据。盘点对象应覆盖平台自身运行所依赖的全部资源类型，而不只是服务器。
需要盘点的资源类型
- 计算资源：应用服务器、构建节点的CPU核数、内存分配量与使用率。
- 存储资源：代码仓库、制品库、日志与附件的容量占用及增长速度。
- 数据库：实例规格、连接数、存储空间、慢查询与IO压力。
- 中间件：消息队列、缓存、任务调度等组件的吞吐与堆积情况。
- 网络资源：带宽峰值、内外网流量分布、负载均衡连接数。
- 许可证与配额：商业软件授权数量、并发用户数上限、第三方服务调用配额。
每类资源要记录的字段
清单的价值在于字段统一，便于横向比较和逐期对比。建议每类资源至少记录以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 资源名称与类型 | 唯一标识，便于跨期追踪 | 制品库存储-集群A |
| 当前用量 | 取数时点的实际占用 | 已用 6.2 TB |
| 周期峰值 | 统计周期内的最高值及发生时间 | 峰值 7.8 TB，出现在季度末 |
| 增长趋势 | 近几个周期的环比或同比变化 | 月均增长约 4% |
| 容量上限 | 当前配置或授权允许的最大值 | 可扩至 12 TB |
| 归属团队 | 资源的使用方或责任方 | 平台运维组 / 某产品研发团队 |
基线取数的周期与口径
基线不能用某一天的数据代表常态。建议以最近一个完整季度为取数周期，同时保留日峰值、周峰值和季度峰值三个口径：日峰值反映日常波动，周峰值反映发布或集中提交带来的规律性压力，季度峰值往往对应版本封版、季度汇报等业务节点。取数时注明监控工具、采样间隔和统计方式，避免不同人用不同口径得出互相矛盾的结论。基线表完成后，应由平台运维负责人确认口径，再作为后续预测的输入。
从基线到预测：容量测算的步骤与假设
基线回答“现在用了多少”，预测回答“未来什么时候会不够”。测算时用两条线并行：一条按历史趋势外推，一条按业务规划自下而上估算，两条线结果差异较大时，说明需要补充信息或调整假设。
测算步骤
- 整理历史序列：把基线表中每类资源的用量按周或按月排列，识别稳态增长部分和周期性峰值部分。
- 外推稳态增长：用近几个周期的平均增长率推算未来一到两个季度的常态用量，同时给出乐观与保守两个区间。
- 叠加业务规划：向业务方收集已知的增量事件，例如新增研发团队、接入新项目群、大版本集中构建、数据保留周期延长，把可量化的影响折算成资源增量。
- 单独处理突发峰值：突发峰值不适用平均增长率，应按历史最大峰值加一定比例预留，并注明该比例的来源，例如“按过去四个季度最大峰值的1.3倍预留”。
- 形成预测表：每类资源给出预测用量、预计触及上限的时间点、建议扩容窗口。
记录假设与数据缺口
预测的可靠性取决于假设是否写清楚。建议在预测表旁附一份假设清单，逐条记录：增长率取自哪个时间段、业务增量由谁提供、哪些资源缺少历史数据、哪些结论需要实际核实。数据缺口要显式标注，例如“新接入团队的存储需求尚未量化，暂按人均占用估算”，而不是用默认值悄悄填上。假设清单在每次复盘时更新，成为下一轮预测的起点。
阈值、扩容触发与角色分工
预测给出的是数字，触发机制把数字变成行动。核心是为关键资源设定两级阈值，并明确每个动作的责任人。
阈值与触发规则
| 资源类型 | 预警阈值 | 扩容触发条件 | 响应时限 |
|---|---|---|---|
| 存储 | 用量达上限70% | 达85%或按预测30天内触及上限 | 预警后一周内提交扩容申请 |
| 计算资源 | 周期峰值CPU使用率达75% | 连续两个周期峰值超85% | 下个扩容窗口前完成 |
| 数据库 | 存储或连接数达70% | 达85%或慢查询显著上升 | 两周内完成评估 |
| 许可证与配额 | 用量达授权量80% | 达90%或业务规划明确增量 | 按采购周期提前启动 |
阈值数值应结合平台实际波动调整，上表给出的是常见起点。触发条件要写成可判断的语句，避免“资源紧张时扩容”这类无法执行的表述。
角色与职责
- 平台运维：维护资源清单与基线数据，监控阈值，发起扩容申请，执行扩容并记录结果。
- 研发团队负责人：提供业务增量信息，确认本团队资源需求的优先级，参与扩容评审。
- 采购或财务：根据扩容申请核对预算，处理许可证与商业资源的采购流程。
- 平台负责人：审批超出常规额度的扩容，主持定期复盘。
交接节点与记录方式
一次扩容通常经过申请、评审、执行、验证四个节点。申请时附上触发依据（阈值截图或预测表条目）；评审记录结论与预算影响；执行后记录变更内容和实际效果；验证时对比扩容前后的用量曲线。这些记录集中存放在平台团队可共同访问的文档或工作项中，便于复盘时追溯。在ONES中，可以把每类资源的扩容事项建成工作项，关联对应的资源清单文档和阈值规则，使申请、评审、执行的状态和责任人留痕在同一处，复盘时按工作项记录核对预测偏差。
一个容量规划示例：从季度峰值到扩容决策
以下为演示情景，用于说明方法如何串联，数据为示意，实际执行时需以真实监控数据替换。
情景：某研发平台的制品库存储连续两个季度在季度末出现峰值，最近一次季度峰值达到容量的82%。
- 基线：取最近一个完整季度数据，当前用量6.2 TB，季度峰值7.8 TB，容量上限9.5 TB，月均增长约4%，归属平台运维组。取数口径为每日采样、取季度最高值。
- 预测：按4%月增长外推，下季度末常态用量约7.0 TB；叠加两个新团队接入的增量（假设每个团队每月新增约0.15 TB，需实际核实），季度峰值预计接近8.9 TB，距上限约6%。
- 触发：该资源已超过70%预警线，且预测显示下季度峰值将超过85%触发条件，运维按规则提交扩容申请，附预测表与假设清单。
- 决策：评审会确认新团队接入计划属实后，批准扩容至12 TB，采购流程同步启动；执行后一周内验证用量曲线，记录实际增长与预测的偏差。
这个示例中需要实际核实的数据包括：新团队接入时间与人均存储占用、历史峰值是否受一次性事件影响、扩容所需采购周期。把这些待核实项写进假设清单，复盘时逐条关闭。
完成检查：容量规划是否可用的核对项
一份可用的容量规划应能通过以下核对。任何一项不满足，都说明规划还停留在草稿状态。
| 核对项 | 通过标准 |
|---|---|
| 资源覆盖 | 计算、存储、数据库、中间件、网络、许可证均有对应条目，无关键资源遗漏 |
| 取数口径 | 每类资源注明统计周期、采样方式和数据来源，不同人按同一口径能复现结果 |
| 预测假设 | 增长率、业务增量、预留比例均有来源说明，数据缺口已标注并指定核实人 |
| 阈值与触发 | 关键资源有预警阈值和扩容触发条件，条件可判断、可执行 |
| 角色对应 | 每个触发条件对应到具体角色，申请、评审、执行、验证的交接节点有记录方式 |
| 复盘机制 | 明确复盘周期（月度或季度）、参与人和调整规则，上期预测偏差有记录 |
核对通过后，把资源清单、预测表、阈值规则和复盘记录放在同一处归档，并在下一次复盘时优先检查预测偏差最大的资源项。容量规划由此从一次性文档变成随业务节奏持续更新的运行机制。
常见问题
平台刚上线、历史数据不足一个季度，基线怎么建？
可以先用较短周期建立临时基线，例如最近四到六周的周峰值，并在清单中注明数据周期不足、结论待验证。同时补充两类信息：一是压测或试运行阶段的资源占用记录，二是同类平台或同规模团队的参考用量。临时基线只用于首轮预警阈值设定，等积累满一个完整季度后重新校准，避免用短期数据直接定长期配额。
业务方给不出明确的增量计划，预测怎么做？
把不确定性显式写进假设清单，而不是等业务方给出确定数字。可以按乐观、中性、保守三档分别估算增量，并标注每档对应的业务条件，例如“新增两个团队接入”或“数据保留周期延长至一年”。预测表给出触及上限的时间区间而非单一时间点，扩容决策按最早触及时间倒推准备周期。复盘时对照实际增量，逐步修正估算系数。
突发峰值和稳态增长为什么要分开测算？
两者的规律不同。稳态增长可以用平均增长率外推，突发峰值往往由版本封版、集中构建、季度汇报等事件触发，用平均增长率会明显低估。分开处理后，常态容量按增长趋势规划，峰值余量按历史最大峰值加一定比例预留，并注明比例来源。这样扩容决策既能覆盖日常增长，也不会因为一次集中压力就过度采购。
扩容申请经常卡在预算审批，流程上怎么衔接？
关键是把触发依据前置到申请环节。申请时附上阈值截图或预测表条目，说明不扩容的具体影响和预计触及时间，评审方据此判断优先级。对采购周期长的资源，例如许可证和商业软件授权，把预警阈值设得更早，按采购周期倒推启动时间。超出常规额度的扩容由平台负责人审批，常规范围内的按既定规则执行，减少每次都要走完整评审的情况。
容量规划多久复盘一次比较合适？
常见做法是按季度复盘，业务增长快或资源波动大的平台可以按月。复盘内容至少包括：上期预测与实际用量的偏差、偏差最大的资源项及原因、假设清单中待核实项的关闭情况、阈值是否需要调整。复盘结论直接更新资源清单和预测表，形成下一轮的输入。复盘周期一旦确定就固定下来，避免只在资源告警时才临时讨论。
