2. 性能与容量治理的度量体系
性能优化如果没有统一的度量体系，就会退化成“凭感觉调参”。容量治理同样如此：扩容还是缩容、是否达到瓶颈、成本是否合理，都必须由可观测数据说话。本节围绕四类核心指标、SLI/SLO/SLA 三层目标、容量水位与成本效率指标，以及监控数据的采集方法，建立一套可落地的度量框架。
一、四类关键指标：延迟、吞吐、错误率、饱和度
业界常把这四类指标称为“黄金信号”，它们分别回答四个不同问题：
- 延迟（Latency）：一次请求从进入到返回耗时多久。必须区分平均值与分位数，P50 反映典型体验，P95/P99 反映尾部体验。平均值会被少数极快请求拉低，掩盖长尾问题，因此生产环境应以 P95/P99 为主。
- 吞吐（Throughput）：单位时间处理的请求数或数据量，如 RPS、QPS、MB/s。吞吐与延迟通常不是线性关系，接近饱和时延迟会急剧上升。
- 错误率（Error Rate）：失败请求占比。要区分客户端错误（4xx）与服务端错误（5xx），前者多为调用方问题，后者才是服务健康度的直接信号。
- 饱和度（Saturation）：资源被占用的程度，如 CPU 使用率、内存占用、连接池使用率、队列深度。饱和度是容量预警的先行指标，往往在延迟恶化之前就已升高。
这四类指标之间存在因果链：饱和度上升 → 排队变长 → 延迟升高 → 超时导致错误率上升 → 有效吞吐下降。理解这条链路，才能在故障早期定位到根因，而不是只盯着最终的错误率报警。
二、SLI、SLO 与 SLA：从测量到承诺
三者是层层递进的关系，不能混用：
- SLI（Service Level Indicator，服务等级指标）：实际测量出来的数值，例如“过去 5 分钟 HTTP 请求成功率 = 99.95%”“P99 延迟 = 320ms”。SLI 必须可采集、可复现。
- SLO（Service Level Objective，服务等级目标）：团队内部设定的目标值，例如“月度成功率 ≥ 99.9%”“P99 延迟 ≤ 500ms”。SLO 是工程决策依据，不是对外承诺。
- SLA（Service Level Agreement，服务等级协议）：对客户或上下游的正式承诺，通常附带赔偿条款，因此 SLA 一般比 SLO 宽松，留出缓冲。
一个可用的 SLI 必须写清三要素：测量对象、统计窗口、合格判定。例如“过去 28 天内，/api/order 接口返回非 5xx 的请求数 ÷ 总请求数”。窗口选择很关键：太短会频繁触发误报，太长则故障响应迟钝，常见做法是同时看 1 小时（快速发现）和 28 天（趋势与预算）。
与 SLO 配套的是错误预算（Error Budget）：允许的失败额度 = 1 − SLO。若 SLO 为 99.9%，则 30 天窗口内允许约 43 分钟不可用。错误预算耗尽时，应冻结新功能发布，优先做稳定性修复；预算充裕时则可加快迭代。这把“稳定性”和“交付速度”从对立变成了可量化的权衡。
三、容量水位：把“还剩多少余量”变成数字
容量水位描述当前负载相对可用容量的占比。它不是一个指标，而是一组指标的组合视图，通常包括 CPU、内存、磁盘 IOPS、网络带宽、数据库连接数、队列深度等。实践中建议按以下方式设定阈值：
| 水位区间 | 含义 | 建议动作 |
|---|---|---|
| < 40% | 健康，余量充足 | 可评估缩容或降配以节省成本 |
| 40% – 70% | 正常，需持续观察 | 关注增长趋势，准备扩容方案 |
| 70% – 90% | 预警 | 触发扩容，检查是否存在热点 |
| > 90% | 危险 | 立即扩容或限流降级，防止雪崩 |
需要注意，水位阈值应结合业务特征调整。例如延迟敏感型服务在 CPU 60% 时 P99 就可能明显恶化，而批处理任务可以跑到 85% 仍可接受。因此阈值不是通用常数，而是通过压测和线上观察校准出来的。
四、成本效率指标：让性能与花费挂钩
只看性能不看成本，容易造成过度配置；只看成本不看性能，则会牺牲用户体验。常用的成本效率指标包括：
- 单位请求成本：月度总费用 ÷ 总请求数，用于横向比较不同架构或不同版本的效率。
- 资源利用率：实际使用量 ÷ 已购容量，反映是否存在长期闲置。
- 每万次请求成本：便于在业务量级差异较大时做归一化对比。
举例说明（以下为教学示例参数，非实测数据）：某服务月度费用 3000 元，处理请求 1.2 亿次，则单位请求成本约为 0.000025 元/次。若通过优化将实例数从 10 台降到 7 台，费用降至 2100 元，而请求量不变，则单位请求成本降至 0.0000175 元/次，降幅约 30%。这类计算能把“优化有效”从主观判断变成可验证的数字。
五、监控数据采集方法
度量体系要落地，必须有稳定的数据来源。AWS 环境下常用的采集方式包括：
- CloudWatch 指标：EC2、ALB、RDS、Lambda 等托管服务默认上报 CPU、延迟、请求数等指标，可直接用于告警和仪表盘。
- CloudWatch Logs Insights：对日志做结构化查询，统计错误率、慢请求分布等指标。
- AWS X-Ray：分布式链路追踪，定位跨服务调用中的延迟瓶颈。
- 自定义埋点：通过 CloudWatch PutMetricData 上报业务级 SLI，如订单成功率、支付耗时。
采集时要注意两点：一是指标粒度，标准监控为 1 分钟，高精度可达 1 秒，粒度越细成本越高；二是标签设计，为指标打上服务名、环境、版本等维度，才能在故障时快速下钻定位。建议先用 CloudWatch 建立基础指标，再逐步补充业务埋点，避免一次性铺开导致维护负担过重。