判断研发平台扩容时点，核心是把平台自身的资源使用和业务负载整理成带时间窗的指标序列，设定容量水位阈值与预警线，再用趋势外推估算触达预警线的时间。当这个时间短于扩容准备周期时启动扩容。本文给出一套可复算的指标、口径与计算步骤，并说明趋势外推的适用边界。ONES 的部署方式与资源管理能力可在指标采集与趋势复核环节提供衔接。
要点总览（TL;DR）
- 扩容判断的核心是比较两个时间：按当前趋势触达预警线所需的时间，以及完成扩容准备所需的交付周期；前者短于后者时启动扩容。
- 指标分资源类和业务负载类两组，资源类看 CPU、内存、存储、连接数、队列积压，负载类看活跃用户、并发请求、构建与任务提交量，预警线一般取容量的 70% 至 75%。
- 趋势外推前先固定口径：公式、分子分母、单位、时间窗和采集频率；缺失值不补零，异常尖峰标注后剔除，跨版本数据分段处理。
- 计算按五步走：平滑序列、算周均增长率、外推触达周数、换算天数与交付周期比较、输出判定；多指标取最早触达者作为决策依据。
- 趋势外推假设历史增长延续，遇到业务扩张、季节性峰值或架构变更需用区间估计并回看复核，单指标不能代表整体容量结论。
扩容判断要回答什么问题
扩容判断要回答的是一个时间问题：按当前增长趋势，平台还有多少时间到达不可接受的水位，这段时间是否足够完成扩容准备。目标是在容量触顶前留出交付时间，保障研发平台自身的运行可用性，同时避免过早扩容造成资源闲置。
评估范围需要先划清。本文讨论的是研发平台管理侧自身的容量，包括应用服务、数据库、存储、消息队列等支撑平台运行的部分。交付业务流水线的容量与性能属于另一类问题，不在本文展开。把两者混在一起统计，会让指标失去解释力：流水线并发升高可能来自一次集中发布，而平台自身的连接数和队列积压才是判断管理侧是否吃紧的直接依据。
最终判断形式可以写成一句话：预测触达预警线的时间小于扩容交付周期，则启动扩容；否则继续观测。这个形式把趋势数据、阈值和交付周期三个输入放在同一个比较里，便于复核和留痕。
观测哪些指标与容量水位
指标分为资源类和业务负载类两组。资源类反映平台自身的消耗，业务负载类反映推动消耗的来源。两组同时观测，才能在趋势变化时判断是容量问题还是负载问题。
| 指标类别 | 具体指标 | 观测意义 |
|---|---|---|
| 资源类 | CPU 使用率 | 计算资源余量，持续高位说明处理能力接近上限 |
| 资源类 | 内存使用率 | 常驻服务与缓存占用，增长过快可能触发交换或重启 |
| 资源类 | 存储使用量与增长率 | 附件、日志、构建产物的累积速度 |
| 资源类 | 数据库连接数 | 连接池占用，接近上限时请求排队 |
| 资源类 | 队列积压量 | 异步任务处理能力是否跟得上提交速度 |
| 业务负载类 | 活跃用户数 | 平台使用规模的直接体现 |
| 业务负载类 | 并发请求数 | 峰值压力来源 |
| 业务负载类 | 构建与任务提交量 | 触发资源消耗的上游输入 |
水位阈值按指标分别设定。常用做法是设两级：预警线取容量的 70% 至 75%，扩容线取 85% 至 90%，具体数值结合平台对短时过载的容忍度调整。存储类指标增长不可逆，预警线可以设得更早，例如 70%，因为清理和迁移都需要时间。阈值一旦确定，应写入容量规划文档并保持稳定，频繁调整会让趋势比较失去基准。
时间窗与采集粒度要匹配决策周期。资源类指标按 5 分钟或 1 分钟采集，用于观察峰值；趋势判断用小时均值或日均值，观察周期取 4 至 12 周。业务负载类指标按天汇总即可。采集粒度过粗会掩盖峰值，过细则噪声大，趋势外推前需要先聚合到统一的时间窗。
数据口径与可比性处理
趋势可比的前提是每个指标的计算方式固定。口径定义表至少包含公式、分子、分母、单位、时间窗和采集频率六项，缺一项就可能在跨周期比较时出现偏差。
| 指标 | 计算口径 | 单位 | 时间窗 |
|---|---|---|---|
| CPU 使用率 | 周期内 CPU 使用时间 ÷ 周期总时间 | % | 小时均值，按日汇总 |
| 内存使用率 | 已用内存 ÷ 可用总内存 | % | 小时均值，取日峰值 |
| 存储使用率 | 已用存储 ÷ 分配容量 | % | 日快照 |
| 连接数占用率 | 当前连接数 ÷ 最大连接数 | % | 5 分钟采样，取日峰值 |
| 队列积压率 | 待处理任务数 ÷ 单位时间处理能力 | % | 小时均值 |
| 人均请求量 | 周期内请求总数 ÷ 周期内活跃用户数 | 次/人 | 按日计算 |
时间窗对齐是可比性的关键。不同指标采集频率不同，做趋势比较前统一聚合到日粒度，并保证每个统计日覆盖完整的 24 小时。跨版本或跨架构变更时，在序列上标注变更日期，变更前后的数据分段处理，不直接连成一条趋势线。
缺失值和异常尖峰单独处理。缺失值不补零，标记为缺失并在外推时排除该点；连续缺失超过窗口的 10%，该周期不参与趋势计算。异常尖峰先判断来源：一次集中导入、批量构建或压测造成的尖峰，标注后从趋势拟合中剔除，但保留在原始记录中备查。分母为零的情况要显式处理，例如某日活跃用户为零导致人均请求量无法计算，该日记为无效值，不用零填充，否则会拉低整体趋势。
用趋势数据推算扩容时点的步骤
计算分五步，每一步都有明确的输入和输出，便于他人复算。
- 序列整理与平滑。取最近 8 至 12 周的日粒度数据，剔除已标注的异常点和缺失点，用 7 日移动平均平滑周内波动，得到平滑序列。
- 计算增长率。用平滑序列首尾值计算周均增长率：周均增长率 =（末期值 ÷ 初期值）^(1 ÷ 周数) − 1。也可以用线性回归斜率，两种方法结果接近时结论更稳。
- 趋势外推。按当前水位和增长率推算触达预警线所需周数：触达周数 = ln(预警线 ÷ 当前水位) ÷ ln(1 + 周均增长率)。增长率接近零时改用线性外推：触达周数 =（预警线 − 当前水位）÷ 周均增量。
- 换算为交付周期比较。触达周数乘以 7 得到触达天数，与扩容交付周期比较。交付周期包括采购、资源申请、部署、验证和切换，按实际流程估算。
- 输出判定。触达天数小于交付周期，启动扩容；触达天数在交付周期的 1 至 1.5 倍之间，进入准备状态并缩短观测间隔；其余情况维持常规观测。
多个指标分别计算后取最早触达的那个作为决策依据，同时记录各指标的触达时间，便于判断瓶颈位置。判定规则应写进容量规划流程，明确谁发起、谁审批、扩容后如何回看。
一个可复算的示例
以下为演示情景，数值为假设，用于说明计算过程。
某研发平台管理侧存储使用率在 12 周内从 52% 升至 61%，取平滑后的首尾值计算周均增长率：（61 ÷ 52）^(1 ÷ 12) − 1 ≈ 1.34%。预警线设为 75%，触达周数 = ln(75 ÷ 61) ÷ ln(1 + 0.0134) ≈ 15.5 周，约 109 天。
同期数据库连接数占用率从 48% 升至 66%，周均增长率约 2.69%，预警线 75%，触达周数 = ln(75 ÷ 66) ÷ ln(1 + 0.0269) ≈ 4.8 周，约 34 天。
扩容交付周期按实际流程估算为 45 天。存储指标触达天数 109 天大于 45 天，维持观测；连接数指标触达天数 34 天小于 45 天，触发扩容。决策输出为：优先扩容数据库连接能力，存储容量列入下一周期计划。这个例子也说明，单看存储会得出“还早”的结论，多指标并列计算才能找到真正的瓶颈。
结果解读与限制
趋势外推成立的前提是历史增长模式延续。业务扩张、组织合并、平台功能上线都会改变增长斜率，此时外推结果只能作为参考，需要结合已知的业务计划修正。增长率本身波动较大时，用区间而非单点：分别按乐观和保守增长率计算触达时间，给出一个时间范围。
单指标不能代表整体容量。CPU 有余量不代表存储够用，连接数正常不代表队列不积压。判断时应看多个指标的触达时间分布，并结合平台架构中各组件的依赖关系，确认瓶颈是否会被上游或下游放大。
季节性和活动峰值会干扰趋势。季度末集中提交、版本发布窗口、大规模构建任务都会形成周期性尖峰。处理方法是在平滑前识别周期规律，用同比而非环比判断增长，避免把一次峰值当成趋势拐点。
建立复核与回看机制。每次扩容决策后记录当时的指标值、预测触达时间和实际触达时间，定期比对预测误差。误差持续偏大时，检查增长率算法、阈值设定或数据口径是否需要调整。容量规划是一个持续校准的过程，趋势数据提供的是决策依据，最终判断仍需结合业务节奏和交付能力。
在指标采集与复核环节，ONES 支持私有部署和公有云部署两种方式，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统，便于把平台运行数据纳入统一的协作流程。容量阈值的确认、扩容任务的发起与验证记录可以在工作项中流转，配合 ONES Project 资源管理中的资源报表跟踪投入情况。平台基础设施层面的容量指标采集与告警，需结合具体部署形态另行核验。
常见问题
扩容交付周期应该怎么估算，包含哪些环节？
交付周期按实际流程逐段估算，通常包括资源申请与审批、采购或云资源开通、部署与配置、验证测试、切换上线几个环节。私有部署场景下采购和到货往往占大头，公有云场景下开通较快但审批和验证仍需时间。建议用最近一次扩容的实际耗时作为基准，再留出一定缓冲；流程有变化时同步更新这个数值，因为它直接进入“触达天数与交付周期比较”的判定。
增长率波动很大时，单点外推还可信吗？
波动大时单点外推容易失真，建议改用区间估计：分别按乐观和保守两种增长率各算一次触达时间，给出一个时间范围，再结合交付周期判断是否进入准备状态。同时检查波动来源，如果是季度末集中提交、版本发布窗口这类周期性因素，用同比而非环比看增长；如果是业务结构调整，外推结果只能作参考，需要结合已知的业务计划修正。
多个指标触达时间不一致时，以哪个为准？
取最早触达的那个作为决策依据，同时记录各指标的触达时间，用来定位瓶颈。比如存储还有 100 多天、连接数只剩 30 多天，就应优先处理连接能力。还要结合组件依赖关系判断：某个指标看似宽裕，但它的上游已经吃紧，实际压力可能提前传导过来。判定规则写进容量规划流程，明确谁发起、谁审批，避免多指标结论冲突时无人拍板。
扩容完成后如何验证判断是否准确？
每次扩容决策后留存当时的指标值、预测触达时间和实际触达时间，扩容完成后定期比对预测误差。误差持续偏大时，回头检查三处：增长率算法是否适合当前数据形态、阈值设定是否偏离平台实际容忍度、数据口径是否在期间发生过变化。容量规划是持续校准的过程，回看记录本身就是下一轮判断的基准数据。
平台运行指标和项目资源投入数据要分开看吗？
要分开看，两者回答的问题不同。平台运行指标反映管理侧自身的资源消耗，用于判断是否扩容；项目资源投入数据反映人员和工时的分配情况，用于判断投入是否合理。ONES Project 资源管理提供资源报表，可实时反馈项目投入情况并支持导出工时日志，适合跟踪投入侧；平台基础设施层面的容量指标采集与告警，需结合具体部署形态另行核验。
