容量规划

• 需求侧预测与供给侧配置的建模能力
• 动态扩缩容机制的实现与触发条件
• 供需匹配的延迟、误差与兜底策略

供需匹配的核心是建立"需求预测与供给配置"的闭环：先通过历史监控、业务预测和发布计划汇总出未来一段时间的需求输入（QPS、并发、存储量等），再换算成所需资源（CPU、内存、带宽、实例数），最后让供给随需求动态调整。动态调整通常包含三个层次：一是基于阈值的自动扩缩容（HPA/KEDA、AWS Auto Scaling），在负载超过/低于阈值时按冷却时间伸缩实例；二是基于排程的容量供应（如 Karpenter、Cluster Autoscaler）按需调度新节点；三是人工/预留的基线容量兜底。为了降低伸缩滞后，常采用"预留一定安全水位 + 自动扩缩容响应突发"的组合，并利用预测式扩缩容（proactive scaling）提前拉高供给。

供给必须滞后于需求，因此一味地"精确匹配"并不现实，关键是控制匹配误差与响应延迟。过度匹配导致浪费，匹配不足导致 SLO 受损，所以需要安全水位作为缓冲，并且用监控告警尽早发现供给不足的趋势。

• 安全水位与容量上限的设定依据
• 突发流量与故障场景下的缓冲设计
• 过度预留与资源不足的权衡

安全水位是"名义容量与预测峰值需求之间的富余比例"，容量上限则是系统允许供给的最大资源边界。安全水位的确定需综合考虑：峰值/均值比、突发流量特征、故障切换的冗余需求（如 N+1、多可用区）、扩缩容的冷启动时间以及业务对延迟的容忍度。通常先基于历史峰值设定基准水位，再按业务重要性加权（核心业务水位更高）。容量上限则受成本预算、实例/配额上限、依赖系统能力共同约束，并在上限处设计降级与排队策略。实践中常用"预测峰值 × (1 + 安全水位) ≤ 容量上限"作为约束，并定期用压测验证该水位是否仍成立。

安全水位过低会在大促或故障时触发 SLO 违约，过高则持续浪费成本。安全水位本质是"为不确定性支付的保险费"，其高低应该与业务风险承受能力和成本预算动态联动。

• 负载画像的采集维度与方法
• 各类资源瓶颈的识别与定位
• 瓶颈资源对容量规划的影响

负载画像是通过对线上流量特征进行采样与分析，识别应用在 CPU、内存、磁盘 I/O、网络、连接数等维度上的资源消耗模式。做法包括：在生产环境收集各资源的利用率曲线与分位数（如 P50/P95/P99）、分析瓶颈资源的饱和点（saturation）、通过压测放大流量观察哪个资源先达到上限，以及在部署与调度时考虑资源间的相互干扰（如 CPU 争用导致 I/O 延迟上升）。识别 I/O 瓶颈通常看磁盘队列深度、IOPS/latency；网络瓶颈看带宽利用率、连接数、丢包与重传。画像结果用于确定该负载的"主导资源"（bottleneck resource），容量规划以主导资源为基准配置实例，避免按非主导资源过量配置。

很多系统 CPU 利用率并不高，但 I/O 或网络已饱和，此时按 CPU 扩容会误判。负载画像能揭示真正的资源约束，使容量规划与实例规格更精准，避免"扩容了却仍不达标"的假象。

• 异常值识别与清洗方法
• 噪声平滑与季节性趋势分解
• 节假日/事件效应的建模与校准

处理方式分三步：一是异常值识别，通过统计方法（如 3σ、IQR、MAD）或经验规则标记出促销、故障、发布等造成的异常点，与大促事件单独建模，避免污染基准趋势；二是去除噪声，对短周期波动采用移动平均或指数平滑，保留长期趋势与季节性成分；三是节假日效应，识别节假日、工作日/周末、月度周期等不同季节模式，为节假日单独建立乘数因子，并在预测时叠加。常用时间序列分解（趋势、季节、残差）配合 Prophet/ARIMA 等模型，把异常点视为"残差中的离群值"处理，或作为事件日历显式注入模型。

若把大促峰值直接当作常态趋势，会系统性高估容量；若把故障导致的低峰当作供给过剩，会低估需求。因此必须区分离散事件与稳态趋势，才能得到可信的预测基线。

• 垂直扩容与水平扩容的适用场景
• 两者的成本、复杂度与扩展上限
• 有状态与无状态负载的差异

垂直扩容是提升单实例规格（更大的 CPU/内存/磁盘），水平扩容是增加实例数量。取舍依据：无状态应用优先水平扩容，因为可无限扩展、弹性好、故障影响面小；有状态应用（数据库、缓存、消息队列）因数据一致性、分片与连接限制，通常先垂直扩容，达到单机上限后再考虑分片或读写分离等水平方案。水平扩容会增加分布式复杂度（负载均衡、会话管理、分布式事务），垂直扩容则受单机规格上限和成本非线性增长限制。成本上，小规格实例按需扩展通常比一味升配更经济。实践中常"先水平、后垂直"，或两者结合：先 scale-out 满足弹性，再对瓶颈组件 scale-up。

没有绝对优劣，关键看应用状态性与扩展瓶颈。容量规划应评估两种路径的扩展上限、成本与停机时间，选择与业务形态匹配的伸缩策略。

• 各数据来源的含义与获取方式
• 数据汇总与统一口径的方法
• 数据来源的权重与优先级

需求输入由三类数据汇总：监控历史提供"过去实际跑过多少"的基线，包括各资源利用率、峰值/均值、流量曲线；业务预测提供"未来业务会增长多少"的预期，来自业务方对齐的增长目标、活动日历、新功能上线；发布计划提供"未来系统会变化多少"的因素，包括新版本性能变化、资源占用调整、架构改造。汇总时需统一口径（同一时间粒度、同一资源维度），以监控历史为基准，叠加业务预测的增长率，再调校发布计划带来的资源变化，最终形成未来 N 周/月的需求曲线。为防止某个来源失真，还需交叉校验并给出置信区间。

单一来源容易偏颇：只看历史会低估增长，只看业务预测会高估趋势，只看发布计划会忽略稳态需求。三源汇总并交叉校验是容量预测可信的基础。

• 三种方法各自的适用场景
• 输出结果之间的交叉验证
• 偏差的定位与修正

历史趋势外推用于快速给出基准预测，基于过去数据延展未来；容量模型计算根据业务指标（QPS、并发、数据量）到资源（CPU、内存、带宽）的换算系数，按模型推导出理论容量；压力测试验证通过对测试环境或线上压测，实测不同负载下的容量上限。三者综合时，以模型计算为骨架、历史外推为基线、压测为真值；若压测实测容量远低于模型或历史推算，说明模型系数或资源假设有误，需要修正换算系数；若历史外推与模型差异大，可能是业务增长或架构变化造成。通过周期性重跑三种方法并对比，形成校验闭环。

三种方法各有盲区：历史外推对突变失效，模型计算依赖系数准确性，压测受环境与成本限制。三者互相校验能显著提升容量预测的置信度，避免单一方法的系统性偏差。

• 业务对齐的流程与节奏
• 活动日历与外部事件的收集机制
• 预测输入的评审与更新机制

建立流程的关键是"定期、结构化、有记录"：由容量/运维团队定期（如月度/季度）与业务方召开对齐会议，收集业务增长目标、新功能上线、大促活动日历、政策与市场等外部事件，形成标准化的需求输入表。流程还应包括：定义统一的需求字段（时间、幅度、影响范围、置信度）、建立事件日历并纳入预测模型、明确负责人与更新频率，以及设置"重大变化时即时通知"的机制。对齐结果需经过评审确认，并与历史覆盖情况进行复盘，持续校准业务方的预测偏差。

业务预测若不作为正式流程管理，容易变成"口头沟通"导致口径不一、无人负责。结构化的对齐流程能提升预测输入的质量与可追溯性。

• 扩缩容指标的选择原则
• 冷却时间与稳定窗口的配置
• 最小/最大副本数的约束

指标选择上应优先选与业务容量直接相关的、前瞻性的指标（如基于 QPS、请求延迟、队列长度），而非滞后指标（如 CPU 利用率在突发时可能延迟反映）；KEDA 支持基于自定义指标（消息队列长度、HTTP 请求数）缩放。冷却时间（cooldown/稳定窗口）用于避免副本数在阈值附近震荡，需设置在实例就绪时间之上，一般秒级到分钟级。最小副本数保证基线可用性，避免缩到 0 导致冷启动延迟；最大副本数防止资源失控超预算。合理配置还应考虑"缩容保守、扩容激进"，即扩容的稳定窗口短、缩容的长，以优先保证 SLO。

指标若选滞后或与业务无关，会导致扩缩容失真；冷却时间过长响应慢、过短则抖动。最小副本数平衡了弹性与冷启动，最大副本数平衡了弹性与成本上限。

• 各优化手段的适用对象与收益
• 收益评估的量化方法
• 组合优化的优先级与风险

实例缩容是通过下线或降低规格闲置实例直接减少成本；资源利用率提升是通过更好的装箱（bin-packing）、调度优化与合理的 request/limit 设置，让同样的资源承载更多负载；冷数据归档是把低频访问的数据下沉到低成本存储（如 S3 Glacier、冷热分层），减少热存储成本。组合评估时应先量化各项收益（节省金额、风险影响），优先实施低风险高收益项（如缩容明显闲置实例、调整明显过高的 request），再逐步推进利用率提升与归档。收益评估需考虑实施成本与回滚风险，并建立"优化前后的成本基线对比"以验证效果。

不同手段针对不同浪费来源：缩容治"闲置"，利用率提升治"低效"，归档治"热数据存储过高"。组合优化需按收益/风险排序，避免为省小钱而引入大风险。

• 闲置资源的识别逻辑
• owner 确认与责任归属
• 审批流程与通知机制

流程设计为：先通过指标（长时间低利用率、无请求、无 IP 访问）自动识别闲置资源并生成待回收清单；然后通知资源 owner 确认，避免误删仍被使用的资源，owner 需在规定时限内认领或申请保留；确认后可回收的资源进入审批流程（按金额/重要性分级审批），执行前再次通知并设置宽限期，回收后验证并记录。通知应采用多渠道（邮件、IM、工单），并设置"无人认领则自动回收"的默认策略或"先归档后删除"的兜底，降低误删风险。

闲置资源回收最大的风险是误删在用资源，因此 owner 确认与审批不可或缺。通过"识别→确认→审批→执行→验证"的闭环，既保证回收效率又控制风险。

• 峰值与均值口径的选择
• 多核利用率与网络吞吐的统计方法
• 统计口径统一的重要性

统一口径需要明确：容量规划以"峰值"为准（保证可用性），成本核算以"均值"为准（反映实际消耗），并记录两者比值（峰值/均值比）反映波动性。多核利用率不能简单平均，应区分"单核饱和"与"整体平均"，对多核负载按加权利用率并关注单核打满的情况；网络吞吐统计需统一单位（bps/pps）、采样窗口与聚合方式（分钟/小时均值与峰值），并区分内外网流量。所有指标应统一命名、单位、采样频率与聚合函数，存入同一指标体系，避免因口径不一导致预测与核算偏差。

口径不统一会导致不同团队看到不同数字、无法对齐。峰值决定容量、均值决定成本，多核要防"平均不高但单核打满"，网络要统一单位与聚合，这是指标可信的基础。

• 换算系数标定的方法
• 压测与线上数据的结合
• 系数随版本更新的校准

换算系数标定的核心方法是"压测实测 + 线上校准"：在压测环境模拟不同 QPS/并发，实测对应的 CPU/内存/带宽消耗，得到"单位 QPS 消耗多少资源"的系数；再与线上监控数据交叉验证，校正压测与生产环境的差异。例如测得单实例在 1000 QPS 时 CPU 利用率 60%，则可估算每 QPS 消耗约 0.06% CPU。系数还应按不同 SKU、不同版本、不同业务类型（读/写/热点）分别标定，并在版本发布或架构变化后重新校准，避免使用过时系数。

换算系数是容量模型的核心参数，其准确性直接决定模型预测质量。仅靠压测可能脱离生产真实特征，仅靠线上又难以控制变量，故需压测与线上数据结合并持续校准。

• 利用率目标与成本预算的关系
• 两者协同约束供给的机制
• 冲突时的平衡策略

利用率目标规定了"资源应被使用到多满"（如平均 60%），成本预算规定了"能花多少钱"。两者共同约束供给：供给既要满足利用率下限（避免过低造成浪费），又要满足服务容量的上限（保证可用），还要受成本预算封顶。当利用率目标与成本预算冲突时（如提高利用率可降本但风险上升），需权衡：设定一个"利用率目标区间"而非单一值，在预算约束下尽量提高利用率，同时为关键业务保留安全水位。实践中常将"单位成本/利用率"作为联动指标，扩容决策同时检查利用率与剩余预算。

容量与成本是一体两面：只盯利用率可能超预算，只盯预算可能牺牲可用性。通过利用率目标区间与成本预算联合约束，能在稳定与成本之间找到平衡。

• N+1 冗余与多可用区的容量含义
• 冗余预留的计算方法
• 冗余对成本的权衡

为高可用预留容量，需在"满足业务所需的最低容量"之上额外增加冗余容量，以应对单点故障。N+1 冗余指至少比所需多 1 个实例，当某实例故障时其余实例能吸收流量；多可用区冗余则要求容量在多个 AZ 间平均分布，任一 AZ 故障时其余 AZ 能承载全部流量。计算上，若业务需要 X 容量、跨 3 个 AZ 平均分配，则每 AZ 需承载 X/2（某 AZ 故障时由剩余 2 个 AZ 承担），总容量为 1.5X。冗余容量会提高成本，需结合业务重要性、RTO/RPO 与故障概率权衡，核心业务冗余高、边缘业务冗余低。

高可用冗余本质是"为故障保险购买容量"，其大小取决于业务对故障容忍度与成本承受能力。容量规划必须显式把冗余部分纳入计算，否则故障时无法切换。

• 报告与建议的产出机制
• 审批决策的层级与授权
• 决策链的闭环与跟踪

决策链设计为"数据驱动、分级授权、闭环跟踪"：运维/容量团队月度产出容量报告（现状、趋势、预警），并附扩容建议（建议规模、理由、成本、风险）；建议按金额与影响分级审批——常规小额扩容由团队负责人授权，大额或涉及架构变更的扩容需经技术负责人与财务/预算审批；审批通过后执行扩容并记录，下月报告对比实际与计划的偏差，形成闭环。决策链应明确各环节 owner、时限与升级路径，确保扩容建议不被搁置。

清晰的分级决策链能兼顾效率与管控：小扩容快速执行，大扩容充分审批。缺乏决策链会导致容量建议无人评审、扩容无人拍板，最终要么延误要么失控。

• 各 KPI 的含义与度量方式
• KPI 之间的平衡
• KPI 对容量工作的指导意义

容量规划 KPI 可分为效率类与时效类：利用率反映资源使用效率（目标区间内为佳，过高有风险、过低有浪费）；峰值/均值比反映负载波动性，比值越大说明越需灵活弹性与安全水位；扩容前置时间（lead time）反映从提出扩容到完成扩容的时间，越短越能应对突发。设计时应避免单一 KPI 误导——例如只追求高利用率会牺牲可用性，因此需组合使用，并设置"利用率达标同时 SLO 不违约"的复合目标。KPI 还应区分月度趋势，指导持续优化。

容量 KPI 的本质是衡量"稳定、效率、及时"三者的平衡。利用率看效率、峰值/均值比看波动、lead time 看响应速度，三者结合才能全面反映容量管理水平。

• 链路各环节的自动化边界
• 自动化与人工审批的权衡
• 风险控制与兜底

自动化程度应"按风险分级"界定：预警触发可完全自动化（指标超阈值自动告警）；扩缩容执行对无状态、低风险、额度内负载可自动化（HPA/KEDA、Auto Scaling），对有状态、关键业务或大额变动保留人工审批门禁；人工审批只介入高风险/高成本的变更，且需设定自动升级时限避免延误。整个链路应具备快速回滚与熔断能力，当自动扩缩容反复震荡或异常时自动降级为人工。核心原则是"常规自动化、异常人工化、全程可观测"。

完全自动化风险高（误扩费钱、误缩毁 SLO），完全人工响应慢。自动化程度取决于变更风险、成本敏感度与业务重要性，通过分级与兜底机制平衡。