3、告警响应SLA定义：MTTA、MTTR与SLA制定

聊到告警响应，绕不开三个核心指标：MTTA、MTTR，以及它们背后的SLA体系。我见过太多团队，一上来就拍脑袋定SLA——「我们承诺5分钟响应，30分钟修复！」结果呢？第一个月就崩了，运维同学天天被扣绩效。说白了，SLA不是喊口号，是算出来的。

3.1 MTTA：平均确认时间

MTTA（Mean Time to Acknowledge），平均确认时间。从告警触发，到有人确认「我看到了，我来处理」的时长。

我习惯把它拆成两段：

• 告警延迟：从故障发生到告警通知到达。嗯，这里要注意，如果你的告警通道是邮件，延迟可能高达5-10分钟。我个人建议用IM机器人或电话语音，延迟能压到秒级。
• 人工确认延迟：从收到通知到点击「确认」按钮。这取决于值班人员是否在岗、是否在摸鱼。

MTTA的计算公式很简单：

MTTA = 所有告警的确认时间之和 ÷ 告警总数

举个例子：

告警ID	触发时间	确认时间	确认耗时
A001	10:00:00	10:03:15	3分15秒
A002	10:05:30	10:08:00	2分30秒
A003	10:12:00	10:20:00	8分00秒

MTTA = (3.25 + 2.5 + 8) ÷ 3 ≈ 4.58分钟。你想想看，如果A003是值班人员去上厕所了，那这个指标就失真了。所以我建议，MTTA要剔除人为异常值，比如超过30分钟的确认，直接标记为「SLA违规」单独分析。

3.2 MTTR：平均修复时间

MTTR（Mean Time to Repair），平均修复时间。从告警触发，到服务完全恢复正常的时长。这是老板最关心的指标，也是运维同学最头疼的指标。

MTTR包含四个阶段：

1. 诊断时间：定位根因。我见过最夸张的，一个磁盘满的告警，排查了40分钟才发现是日志没轮转。
2. 修复时间：执行修复操作。比如重启服务、扩容、回滚版本。
3. 验证时间：确认服务正常。别急着关告警，先跑一遍健康检查。
4. 恢复时间：数据同步、缓存预热等。有些场景下，恢复比修复还慢。

MTTR的计算：

MTTR = 所有告警的修复时间之和 ÷ 告警总数

举个例子，某次P0故障：

阶段	耗时	说明
诊断	12分钟	查看日志、监控、链路追踪
修复	3分钟	回滚到上一个稳定版本
验证	5分钟	接口返回200，业务指标恢复
恢复	10分钟	缓存预热，数据一致性校验
合计	30分钟	这就是MTTR

你想想看，如果诊断时间占了40%，那优化方向就很明确了——建立知识库、自动化诊断脚本、甚至引入AI辅助定位。

3.3 SLA制定原则

SLA不是拍脑袋定的。我总结了一个「三三制」原则：

• 三分看历史：拉过去3-6个月的MTTA、MTTR数据，取P50、P90、P99。比如P90的MTTA是5分钟，那SLA定在5分钟是合理的。
• 三分看业务：核心交易链路和后台报表系统，SLA能一样吗？我建议按P0/P1/P2分级，P0的MTTR定在15分钟，P2可以放宽到2小时。
• 三分看成本：要达成1分钟MTTR，你需要7×24值班、自动化工具、冗余资源。老板愿意掏这个钱吗？

一个典型的SLA表格：

告警级别	MTTA	MTTR	适用场景
P0	5分钟	30分钟	核心交易、支付、登录
P1	10分钟	60分钟	重要功能、部分用户受影响
P2	30分钟	4小时	非核心功能、后台任务
P3	不承诺	下一个工作日	体验优化、低优先级告警

3.4 SLA违约处理

定SLA容易，违约了怎么办？我见过两种极端：一种是「违约了也没事，下个月补回来」，另一种是「违约一次扣500，扣到离职」。都不对。

合理的违约处理机制：

• 自动记录：系统自动计算每次告警的MTTA、MTTR，超标的自动标记为SLA违约。别让人工统计，你想想看，谁会主动上报自己违约了？
• 分级处罚：P0违约一次，触发事故复盘；P1违约三次，触发改进计划；P2违约，记录在案，季度回顾。
• 补偿机制：如果是外部客户SLA，违约了要赔钱。内部SLA呢？我建议用「改进积分」——违约一次，团队要提交一份根因分析和改进方案。

违约处理的流程：

1. 系统自动检测SLA违约
2. 发送违约通知给值班负责人
3. 24小时内提交根因分析报告
4. 48小时内提交改进方案
5. 下个迭代验证改进效果
6. 如果同一原因再次违约，升级处理

说白了，SLA违约不是用来扣钱的，是用来驱动改进的。我习惯把违约数据做成看板，每周回顾一次。你会发现，前三个月违约很多，但每处理一次，系统就稳定一分。半年后，违约次数会大幅下降——这才是SLA的真正价值。