研发平台容量规划要同时约束四类边界：资源上限、负载结构、稳定性与合规要求、组织与预算条件。只盯服务器余量容易漏掉数据库连接、制品增长和审批周期带来的限制。本文给出一套可执行的规划步骤、角色分工和检查清单，帮助负责平台运行的团队完成一次有依据的容量评估。
要点总览（TL;DR）
- 研发平台容量规划要同时约束四类边界：资源上限、负载结构、稳定性与合规、组织与预算，只盯服务器余量会漏掉数据库连接、制品增长和采购周期。
- 可执行的做法分五步：采集基线、推算需求、设定冗余水位、形成分阶段扩容计划与触发条件、定期复核，每步都要有明确输入和产物。
- 平台运维、研发团队负责人、采购财务、安全合规各有对应交付物，评审重点放在假设是否成立、触发条件是否可监控、排期是否留足采购时间。
- 规划是否可执行，用检查清单判断：基线覆盖峰值与增长、推算写明假设与系数、水位与触发条件明确、审批采购纳入排期、复核责任落实。
先明确容量规划要回答的四个问题
容量规划的对象是研发平台自身的运行资源与服务能力，包括应用服务器、数据库、存储、网络带宽，以及登录会话、接口调用、后台任务等平台侧服务能力。业务流水线交付什么、调度多少构建任务，属于另一类容量问题，本文不展开。把约束归为四类，每类对应一个必须回答的问题，规划才不会停留在“加机器”层面。
| 约束类别 | 典型指标 | 需要回答的问题 |
|---|---|---|
| 资源上限 | CPU 与内存使用率、磁盘余量、数据库连接数、并发会话数、带宽占用 | 现有资源还能支撑多久，扩容需要多长时间到位？ |
| 负载结构 | 日活跃用户数、峰值时段在线人数、接口请求量、制品与日志的日增量、数据保留期内的累计量 | 负载由什么驱动，峰值是均值的几倍，增长速度是多少？ |
| 稳定性与合规 | 高可用节点冗余、备份恢复窗口、数据保留期、审计日志留存时长 | 故障时能否接管，备份能否在窗口内完成，数据要留多久？ |
| 组织与预算 | 扩容审批周期、采购到货时间、运维人力、可接受的停机窗口 | 从决定扩容到资源可用需要多少天，谁来实施？ |
四类约束相互牵制。资源余量充足但采购周期长，实际可用容量仍受排期限制；负载增长可预测但备份窗口随数据量变长，恢复能力会先于存储耗尽而成为瓶颈。规划时把四类问题并列回答，才能得到可执行的结论。
按步骤完成一次容量规划
一次完整的容量规划可以拆成五步。每步都明确输入、动作、输出和完成标志，避免评估做完却无法支撑决策。
第一步：采集现状基线
输入是监控系统、数据库统计和存储用量报表。动作是取最近一个完整周期（建议不少于 30 天）的资源用量数据，分别记录日均值、峰值和峰值出现时段，并计算周环比或月环比增长率。输出是一份基线报告，包含各类资源的当前用量、峰值系数和增长趋势。完成标志是每项关键资源都有峰值数据和增长率，且数据口径一致、可复算。
第二步：识别负载驱动因素并推算需求
输入是基线报告和业务侧输入，例如未来一个季度计划接入的团队数、用户数变化、新上线的平台模块。动作是找出与资源用量相关性最强的驱动因素，用“驱动因素增量 × 单位资源消耗”推算需求，再乘以峰值系数得到峰值需求。输出是需求预测表，逐项列出假设、系数和推算结果。完成标志是每个预测数字都能追溯到假设来源，假设本身写明适用条件。
第三步：设定冗余与安全水位
输入是需求预测表和高可用要求。动作是为每类资源设定告警水位和扩容水位，例如使用率达到某一比例时触发预警、达到更高比例时启动扩容；同时确认高可用部署下的冗余节点是否计入可用容量。输出是水位设定表，写明每类资源的预警值、扩容值和依据。完成标志是水位设定与故障接管需求一致，且不把冗余节点的容量重复计入业务可用容量。
第四步：形成分阶段扩容计划与触发条件
输入是需求预测表、水位设定和采购审批周期。动作是按季度或半年划分扩容阶段，每个阶段写明扩容内容、预计到位时间、触发条件和责任人。触发条件应与监控指标绑定，例如连续若干天超过扩容水位即启动。输出是扩容计划表。完成标志是每个阶段的启动条件可被监控自动判断，且到位时间早于预测的资源耗尽时间。
第五步：复核与滚动更新
输入是监控数据和上一版规划。动作是按固定周期（如每季度）比对实际用量与预测值，分析偏差原因，更新增长率和下一阶段计划。输出是复核记录和修订后的规划版本。完成标志是偏差有解释、计划有更新、责任人确认签字。
角色分工与各阶段交付物
容量规划停留在文档层面的常见原因是职责不清：数据有人采、结论没人认、扩容没人推。把角色和交付物对应起来，规划才能进入执行。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 平台运维 | 采集监控数据、维护基线、设定水位、执行扩容与验证 | 基线报告、水位设定表、扩容实施记录 |
| 研发团队负责人 | 提供业务侧输入，如团队与用户增长计划、新模块上线时间 | 需求输入说明、预测假设确认 |
| 采购与财务 | 确认预算额度、审批流程和采购到货周期 | 审批记录、采购排期 |
| 安全合规 | 确认数据保留期、审计留痕要求和备份恢复标准 | 合规要求清单、备份恢复验证记录 |
交付物的评审方式建议与规划节奏绑定：基线报告和需求预测表由平台运维与研发团队负责人共同确认，扩容方案由上述角色加采购财务会签，审批记录归档备查。评审的重点是假设是否成立、触发条件是否可监控、排期是否留足采购时间，而非文档格式。
这些交付物需要版本可追溯、状态可跟踪。ONES Wiki 可用于沉淀容量规划文档、基线报告和复盘记录，并与项目、任务等工作项保持关联；扩容任务、审批和验证记录则以工作项形式流转，评审结论和责任人确认留在同一处，便于下一轮复核时对照。具体承载方式可按团队现有工具链调整。
示例：一次季度容量评估怎么落地
以下情景为演示用途，其中用户数、增长率和阈值均为假设值，不代表任何真实平台数据。
背景与假设。某研发平台当前日活跃用户 800 人，峰值时段在线 300 人，应用服务器 CPU 日均使用率 35%、峰值 62%；存储中制品与日志合计占用 4 TB，月增长约 300 GB；数据库连接池上限 500，峰值占用 310。业务侧计划下季度新增两个团队，日活跃用户预计增长 15%。采购审批加到货周期约 45 天。
需求推算。按用户增长 15% 推算，峰值在线人数约为 345 人，CPU 峰值按同比例估算约 71%。存储按每月 300 GB 增长，一个季度后累计约 4.9 TB。数据库连接峰值按比例估算约 357，接近连接池上限的七成。推算中使用的系数是“资源用量与活跃用户近似线性”，这一假设需在复核时用实际数据检验。
水位与触发阈值设定。假设团队将 CPU 扩容水位设为峰值 75%、存储预警水位设为可用容量的 80%、数据库连接扩容水位设为上限的 75%。按此标准，CPU 峰值 71% 已接近扩容水位，数据库连接 357 已超过 75% 水位，两项需要在季度内处理；存储尚有缓冲，但需纳入下一阶段计划。
扩容动作与验证。形成两项动作：一是为应用服务器增加节点，触发条件为 CPU 峰值连续 5 天超过 75%，因采购周期 45 天，需在本季度初启动审批；二是扩大数据库连接池上限并评估数据库实例规格，由平台运维在变更窗口实施。扩容完成后连续观察两周峰值数据，确认使用率回落到水位以下，并将结果写入复核记录。
完成检查：容量规划是否可执行
规划交付前，用以下清单逐项核对。任何一项不满足，都说明规划还不足以支撑扩容决策。
- 基线数据覆盖至少一个完整周期，包含日均值、峰值和峰值时段，并给出增长率。
- 需求推算写明驱动因素、单位消耗系数和峰值系数，每个假设标注来源和适用条件。
- 每类关键资源都有预警水位和扩容水位，水位设定与高可用冗余要求一致。
- 扩容触发条件与监控指标绑定，可被自动判断，无需人工临时决定。
- 扩容审批、采购到货和实施时间已纳入排期，且到位时间早于预测的资源耗尽时间。
- 备份恢复窗口和数据保留期经过验证，数据量增长后仍能满足要求。
- 复核周期、责任人和复核输出物已明确，上一轮偏差有解释。
- 规划文档、审批记录和验证结果可追溯，下一轮评估能直接对照。
清单全部通过，说明规划具备了从基线到执行再到复核的闭环。后续只需按复核周期滚动更新，把新的增长数据和假设偏差补进去，容量规划就能持续支撑平台的稳定运行。
常见问题
容量规划多久做一次比较合适？
建议按季度做一次完整复核，并在业务侧出现明显变化时临时加做一次，例如新增团队、上线新模块或用户规模短期跳升。季度节奏的好处是与采购审批、预算周期对齐，扩容计划有足够时间走完流程。复核时重点比对实际用量与上一版预测的偏差，把偏差原因写进记录，再更新增长率和下一阶段计划。
平台刚上线、还没有历史监控数据，怎么做基线？
没有完整周期数据时，可以先用试运行阶段的监控数据做初始基线，同时明确标注数据周期不足这一限制。做法是把试运行期间的日均值、峰值和峰值时段记录下来，增长率暂用业务侧的用户增长计划替代实测值，并在下一季度复核时用真实数据替换。基线报告里要写清哪些数字来自实测、哪些来自假设，避免后续推算被误当成确定结论。
扩容触发条件设成固定阈值，还是按趋势预测？
两者可以结合使用。固定阈值适合作为兜底，例如使用率连续若干天超过扩容水位即启动流程，判断简单、可被监控自动执行。趋势预测适合提前排期，例如按当前增长率推算资源耗尽时间，倒推审批启动时点。实际做法是把趋势预测用于排期、把固定阈值用于触发，两者写在同一个扩容计划里，并注明各自的判断依据。
高可用部署下，冗余节点的容量要不要计入可用容量？
冗余节点的容量用于故障接管，不应重复计入业务可用容量。规划时要把业务可用容量和高可用冗余分开计算：先按业务峰值需求确定所需容量，再在此基础上叠加故障接管所需的冗余。否则一旦某个节点故障，剩余节点承接全部负载时就会越过安全水位。具体冗余比例需结合平台的高可用方案确定。
容量规划文档和扩容任务用什么方式管理比较好？
关键是让文档、任务和审批记录能互相对照。规划文档、基线报告和复核记录适合沉淀在知识库中并保留版本；扩容任务、审批和验证结果以工作项形式流转，状态和责任人可追踪。ONES Wiki 可用于沉淀容量规划文档与复盘记录，并与项目、任务等工作项保持关联，便于下一轮复核时直接对照。具体承载方式可按团队现有工具链调整。
