一、先摸清请求特征
（一）请求量的时间曲线
按小时统计一段时间内的请求量，找出峰值、谷值与日均。只看日均会严重低估峰值时段的压力，而用户感受到的正是峰值时的表现。
（二）输入与输出长度分布
统计输入与输出长度的分位数，而不是只看均值。长尾请求虽然占比不高，却会占用不成比例的资源。
（三）时延要求
与业务方确认可接受的分位时延，例如绝大多数请求需要在多久内返回。要求越严，需要的冗余越多，成本也随之上升。
二、测量单实例的实际能力
1. 用真实语料压测
构造与生产分布一致的请求样本，逐步提高并发路数，记录吞吐与时延的变化曲线。随机生成的文本会得出偏乐观的结论。
2. 找到拐点
并发提高到某个值之后，吞吐不再增长而时延快速上升，这个拐点就是单实例的合理工作区间。超过拐点运行，性价比很低。
3. 注意长尾影响
少量超长请求会显著拉高分位时延。按长度分档路由到不同规格的实例，是处理长尾的有效办法。
三、从请求量换算实例数
换算过程可以拆成下面三步：
① 用峰值时段的每秒请求数除以单实例在拐点处的吞吐，得到基础实例数。
② 按可用性要求乘以冗余系数，单实例故障不影响服务时通常要留出额外余量。
③ 再按伸缩策略的反应时间留出缓冲，覆盖扩容完成之前的这段时间。
四、冗余与伸缩策略
（一）冗余系数怎么取
冗余取决于容错要求。要求单实例故障不影响整体，就要至少多留一份；要求跨位置容错，还要再翻倍。
（二）伸缩触发条件
按利用率、排队长度还是时延分位值触发，效果差别很大。按排队长度触发通常更贴近实际体验。
（三）冷却与缓冲
扩容之后要留出冷却时间，缩容之前要留出缓冲，否则会频繁抖动，反而增加开销。
五、上线前的验证
（一）按峰值流量压测
按估算峰值的若干倍压测，观察系统在超出预期时的表现，确认是排队等待还是直接失败。
（二）故障注入
停掉部分实例或模拟某个位置不可用，验证调度与伸缩能否按预期工作。没有验证过的容错等于没有容错。
（三）回退准备
保留上一版配置与模型文件，新配置出现问题时能快速回退。这一步成本极低却非常关键。
六、上线后持续跟踪
（一）三个核心指标
分位时延、错误率、实例利用率。三者结合才能判断容量是否合适，只看某一个容易误判。
（二）成本与体验的取舍
利用率长期偏低说明资源冗余过多，时延长期接近容忍额度则说明偏紧。两者都要定期回顾。
（三）记录与归档
-
压测结果与容量计算过程要记录下来，下次扩容直接复用。记录可存放到天翼云存储，与团队共享；监控脚本可放在天翼云主机上长期运行。
-
压测脚本要能复现，把样本集、并发配置与执行步骤写清楚，下次扩容时直接复用即可。
-
压测样本与历史报告、历史压测数据与容量结论建议存入天翼云存储，形成内部的容量基线库，后续项目、扩容或新项目可直接参考。
-
容量相关的决策要留档，记录当时的依据与假设，事后复盘时能快速理解背景。
-
监控采集与压测发起可以放在天翼云主机上，与被压测环境分离，减少压测本身影响测量结果的准确性。
（四）压测方法与指标
-
分位时延比均值更能反映体验，报告里至少要包含高位分位值，只看均值会掩盖长尾问题。
-
排队长度是比利用率更早的预警信号。队列开始堆积时，利用率往往还没到触发值。
-
伸缩策略调整后要观察至少一个完整的业务周期，只看几分钟容易漏掉只在特定时段出现的问题。
-
压测要覆盖从零到峰值的爬升过程，直接跳到峰值会漏掉伸缩策略在爬升阶段的问题。
-
实例启动之后的预热不能忽略，冷启动阶段的处理能力明显低于稳定状态。
（五）容量规划与请求分类
-
容量规划要区分在线与离线两类请求，前者对时延敏感，后者更盯住吞吐，策略完全不同。
-
批量请求可以安排在资源空闲时段，用较低的成本完成，不必与在线请求争抢资源。
-
缓存命中率会显著影响实际容量，命中率高的场景，同样的资源能支撑更多请求。
-
输入长度分布的尾部要单独处理，超长请求按比例路由到专用实例，减少拖慢整体。
-
多模型共存的场景要分别统计，不同模型的请求量与开销差异很大，合并计算会失真。
-
请求优先级机制能提升体验，把高优先级请求单独排队，减少被低优先级挤占。
-
超时设置与容量规划相互影响，超时过短会造成大量重试，反而增加实际负荷。
-
降级方案要提前设计，资源不足时返回简化结果，比直接失败对业务更友好。
-
跨地域部署时，容量要按各区域分别规划，不同区域的高峰时间不同，可以互为补充。
-
伸缩的反应时间要计入容量规划，从触发到可用的这段时间内，请求仍会持续进入。
-
容量的额度要留有余地，完全按峰值规划会让成本偏高，也不必要地压缩了弹性。
-
不同时段的容量可以差异化配置，高峰多留一些，低峰适当收缩，整体效率更高。
（六）成本与体验的取舍
-
成本与体验的取舍要有人拍板。技术指标只提供数据，最终取哪个点需要业务方决定。
-
成本与体验的关系要量化呈现，让业务方看到不同选择对应的支出，便于做出取舍。
-
成本随容量线性增长，找到体验与支出的合理交点，比一味追求低时延更有价值。
（七）持续更新与复核
-
新模型上线或模型升级后，容量需求可能变化，应当重跑一次压测，不能直接沿用旧模型的容量结论；新版本开销可能不同，原有结论需要重新验证。
-
容量规划不是一次性工作，业务增长与模型变化都会让原有结论失效，需要定期重算。
-
容量结论要标明适用条件，包括模型版本、输入分布与时延要求，条件变化就要重算。
-
容量模型要用实际数据校准，初期估算的偏差可以通过上线后的观测逐步修正。
结语：容量规划的第一步不是估资源，而是摸清请求特征。请求量的峰谷、输入长度的分布、可接受的时延，这三个数字决定了后面所有的计算。单实例能力要用真实语料实测，用短样本测出的吞吐会明显偏高。算出实例数之后别忘了冗余，以及为伸缩留出反应时间。
