SRE 实战手册九延申篇容量规划实战——在拐点到来之前算清楚延申篇。本篇把课程里容量与 SLO 的关系落到可操作的工程方法用两个经典模型理解容量再用我们实验台的loadtest.py真刀真枪地把容量拐点测出来。配套脚本../deploy/loadtest.py。一、先厘清三个常被混用的词很多人把容量“性能”可用性当成一回事但 SRE 视角下它们是三件不同的事┌─────────────┐ 吞吐/并发到顶 ┌─────────────┐ 性能(单请求) │ Latency │ ───────────────► │ 容量(Capacity)│ p50/p95/p99 │ R S/(1-ρ)│ 拐点之后 │ 系统能扛多少 │ └─────────────┘ └──────┬──────┘ │ 扛不住 → 排队/失败 ▼ 可用性(SLI 下降)性能单请求视角关心延迟分位数p50/p95/p99。容量系统视角关心在可接受的延迟下能稳定处理多大的吞吐/并发。可用性结果视角容量被打破后错误率上升、SLI 跌落。一句话容量规划的目标是让峰值流量落在容量拐点左边且拐点左边的 p99 仍满足 SLO。二、两个必须懂的核心模型模型 1Little’s Law稳态下L λ × WL系统中平均并发请求数在途请求λ到达率QPSW平均驻留时间含排队服务即用户感知的延迟含义并发 吞吐 × 延迟。想降并发少占资源要么降吞吐不可能业务要的要么降延迟优化服务时间S。模型 2M/M/1 利用率—延迟关系单服务台、到达与处理均为随机时R S / (1 - ρ) ρ λ × S 利用率S平均服务时间不含排队ρ利用率0~1这条公式揭示了一个反直觉但致命的事实延迟 R ↑ │ ╱⟍ 指数级飙升 │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ └────────────────────────────► 利用率 ρ 0 0.5 0.7 0.8 0.9 1.0 ↑拐点区当利用率ρ超过约0.7~0.8延迟开始明显抬头到 0.9 以后延迟呈指数级恶化。这就是为什么经验上要给系统留20%~30% 的 headroom余量——不是浪费是 bought 的稳定性。三、SLO 视角下的容量规划容量规划不是买多大机器而是回答一个问题在业务峰值 QPS 下p99 延迟是否仍满足 SLO错误率是否仍 ≥ 99.9%步骤估算峰值历史峰值 × 增长系数如大促 5×~10×或压测反推。定 headroom按 ρ≤0.7 留余量。找拐点用压测工具扫描 QPS记录 p99 与错误率定位延迟开始指数恶化的点。算冗余拐点容量 ÷ 目标峰值 ≥ 安全系数通常 ≥ 1.5×。常态化压测容量不是一次算清就完随代码/依赖变化要复测。四、用实验台把拐点测出来我们的悦购 Demodemo_app.py自带约 25 QPS 的后台基线流量。要测纯外部容量先关掉后台流量再用loadtest.py扫描# 在任一业务节点如 ecs-584a-0002上# 1) 关后台流量重启 demo更干净的容量测量BACKGROUND_TRAFFIC0python3 /opt/sre-lab/demo_app.py# 2) 从操作机扫描不同 RPS观察 p99 / 错误率python3 /opt/sre-lab/loadtest.py--urlhttp://节点:8080--rps10--duration8--endpointcheckout python3 /opt/sre-lab/loadtest.py--urlhttp://节点:8080--rps50--duration8--endpointcheckout python3 /opt/sre-lab/loadtest.py--urlhttp://节点:8080--rps200--duration8--endpointcheckoutloadtest.py是零依赖压测器多线程令牌桶 延迟分位数统计输出示例 压测结果checkout 请求总数 : 40 实际 QPS : 10.0 (目标 10) 错误率 : 0.00% 延迟 p50 : 55.5 ms 延迟 p95 : 82.2 ms 延迟 p99 : 118.0 ms本地单核沙箱实测诚实标注本机仅单核悦购 Demo 的拐点很低——含后台 25 QPS 后外部再叠加约 10 QPS合计 ~35 QPS即开始吃紧一旦越过p99 从百毫秒级直接飙到 2s 且错误率 100%正是利用率悬崖的现场。在 4 台 8C ECS 上同样的loadtest.py拐点会高得多多核 真实网络。请在你自己的 ECS 上跑上面的命令把真实拐点记进容量文档——这才是有价值的产出而不是抄我的数字。也可直接看 Grafana 仪表盘的「结账 QPS / p99 延迟」面板真监控栈起好后扫描 RPS 时观察曲线拐弯的位置。五、容量规划的工程清单项做法本实验台对应峰值估算历史 × 系数大促单独建模用loadtest.py模拟目标峰值headroom利用率 ≤ 0.7留 20%~30%拐点 QPS × 0.7 作为安全容量拐点测量压测扫描 分位数loadtest.py输出 p50/p95/p99冗余系数安全容量 ÷ 峰值 ≥ 1.5×对比测得拐点与业务目标常态化每次发版/依赖升级后复测把loadtest.py接进 CI 冒烟弹性超峰值的兜底限流/降级/扩容博客十的发布与降级机制六、小结与思考题容量、性能、可用性是三件事容量规划要让峰值落在拐点左边、且 p99 满足 SLO。R S/(1-ρ)告诉你利用率过 0.8 后延迟指数恶化必须留 headroom。拐点是测出来的不是猜出来的——loadtest.py就是我们的测量仪。思考题你们核心服务的拐点 QPS和峰值 QPS分别是多少两者的安全系数到了 1.5× 吗如果没测过今天就用loadtest.py测一次。下一篇拐点被打破往往源于一次变更——我们聊变更与发布工程如何让上线本身变得安全。