SLA 指标详解：TTR、TTF、升级时间与达成率
指标定义是 SLA 管理的根基。定义不清楚，考核就是空谈。我见过不少团队，SLA 文件写了几十页，但一线对不上口径，扯皮不断。
另一个问题是定义脱离实际。指标定得太高，团队永远达不到；定得太低，又失去约束力。
我个人习惯，在定指标前，先把每个指标的含义、起点和终点的判定标准，一条条写在纸上，大家当面达成共识。嗯，这步至关重要。
1. 响应时间（TTR）
响应时间，说白了，就是从告警触发到有人确认接手，这段时间。
请注意，响应不等于解决。我刚开始带团队时，有个运维同学告警一响就冲上去修，但忘了先响应。结果 SLA 统计下来，响应时间全红。
TTR = 告警确认时间 - 告警产生时间
常见的响应行为包括：
- 点击“确认告警”按钮
- 在群内回复“收到，我来处理”
- 创建 JIRA/工单并指派
响应时间的参考阈值，按告警级别不同有差异：
| 告警级别 | P0（致命） | P1（严重） | P2（一般） | P3（提示） |
|---|---|---|---|---|
| 响应时间目标 | 5 分钟 | 15 分钟 | 30 分钟 | 当天 |
| 说明 | 立即响应 | 快速响应 | 及时响应 | 工作日结束前 |
2. 解决时间（TTF）
TTF，全称 Time to Fix，指从确认受理到根本解决的时间。它比你想象中更难定义。
比如，一个磁盘满了的告警。你临时清理了几 G，只是暂时恢复了，但没从根本上扩容。这算解决吗？
TTF = 根本解决时间 - 告警确认时间
我习惯把解决分为两种：
- 临时恢复：应用能跑，但问题还在。例如重启服务、临时扩容。
- 根本解决：问题彻底消除。例如修复代码、永久扩容。
你想想看，如果临时恢复就算解决，团队可能会陷入“重起一下”的恶性循环。我在项目里踩过一个坑——当时把所有告警的解决时间都设成 30 分钟。结果主机宕机这种的，30 分钟根本搞不定。后来我们按影响范围做了分层：
| 影响范围 | 目标 TTF | 典型场景 |
|---|---|---|
| 单实例、非核心 | 2 小时 | 某 Pod OOM |
| 单实例、核心服务 | 1 小时 | 支付服务 Pod 崩溃 |
| 集群级别 | 4 小时 | 阿里云 ECS 集群宕机 |
| 全站/全链路 | 8 小时 | CDN 全链路故障 |
3. 升级时间
升级时间是什么？如果一线在规定时间内搞不定，或者问题超出了处理能力，就得往上升级。
升级可以按时间触发，也可以按条件判断。
我曾经在牵头做 SLA 时，画了这样一张流程图，今天拿出来分享给你。它把几个指标的关系串联了起来：
关于升级的触发条件，我常用的策略是：
- 时间触发：超过 TTR 目标，一线未确认，自动升级给二线。
- 条件触发：一线尝试 2 次以上仍未根本解决，手动或自动升级。
- 业务层触发：告警影响核心交易，直接升级到技术总监。
4. SLA 达成率计算
SLA 达成率，就是考核周期内，达标告警数占总告警数的比例。
SLA 达成率 = (SLA 达成的告警数 ÷ 总告警数) × 100%
单维度计算
假设某月有 100 条 P0 告警，其中 85 条在 5 分钟内响应，那么响应时间 SLA 达成率为 85%。
多维度聚合
实际考核通常是打分的组合。例如：
- 响应时间权重：30%
- 解决时间权重：50%
- 升级次数权重：20%
我习惯这样加权去算。举个例子：
响应时间达成率 90%，解决时间达成率 80%，升级次数达标率 100%。
那么综合 SLA 达成率 = 0.9×0.3 + 0.8×0.5 + 1.0×0.2 = 0.27 + 0.40 + 0.20 = 87%。
指标关系速查
| 指标 | 缩写 | 起始点 | 终止点 | 核心关注 |
|---|---|---|---|---|
| 响应时间 | TTR | 告警产生 | 人工确认 | 响应速度 |
| 解决时间 | TTF | 人工确认 | 根本解决 | 解决质量 |
| 升级时间 | — | 告警产生 | 升级触发 | 升级时效 |
| SLA 达成率 | — | 统计周期起 | 统计周期止 | 整体达标 |
很多团队光盯着 SLA 达成率这个数字，忽略了背后的 TTR 和 TTF。其实你可以把它们看成一个漏斗：告警进来，经过响应、解决、升级几个关卡，最后才到达成率。哪个环节堵了，达成率都不可能好看。