前两天凌晨三点，我正睡得迷迷糊糊，手机突然炸了——告警系统连发五条高优先级通知。登录一看，线上服务的延迟飙升到2秒以上，用户已经开始在社交平台吐槽‘这App卡成PPT’。这种场景对SRE来说太熟悉了，不是第一次，也不会是最后一次。
一次典型的线上事故复盘
那次出问题的是订单查询接口。表面看是数据库连接池被打满，但根因是上游一个新上线的服务没加缓存，每秒发起上千次无效查询。我们花了一个小时定位、降级、扩容，最后才稳住局面。
事后翻监控日志，发现其实在故障前40分钟，QPS就已经异常上涨，但告警阈值设得太高，没人收到提示。这就是典型的‘可观察性盲区’——系统明明有数据，却没能及时转化为行动信号。
我们怎么改的？
第一件事是重设告警规则。以前用固定阈值，比如‘CPU超过80%就报警’，现在改成基于基线的动态检测。比如：
ALERT HighRequestBurst\n IF rate(http_requests_total[5m]) > 2 * avg_over_time(http_requests_total[1h])\n FOR 3m\n LABELS { severity = "page" }\n ANNOTATIONS {\n summary = "请求量突增超过历史均值两倍",\n description = "{{ $labels.job }} 请求速率异常上升"\n }这个Prometheus告警规则的意思是：如果某服务5分钟内的请求数，持续超过过去1小时平均值的2倍，就触发告警。比起死板的数字，它更能捕捉异常波动。
把救火变成预防
光靠告警还不够。我们开始推行‘错误预算’机制。每个月给每个核心服务设定99.9%的可用性目标，换算下来每月最多允许43分钟 downtime。一旦消耗超过70%，就冻结新功能上线，优先修复技术债。
刚开始开发团队挺抵触，觉得被卡进度。但有次一个项目因为错误预算耗尽被拦下，结果在修复期间发现了潜在的数据写入冲突——要是强行上线，可能引发资损。后来大家慢慢接受了：这不是阻碍交付，而是帮我们避开深坑。
自动化才是终极工具
最实在的提升来自自动化脚本。比如数据库连接泄漏的问题反复出现，我们就写了个自动巡检工具，每天扫描慢查询日志，匹配特定模式后直接推送工单到负责人飞书，并附上最近提交记录链接。
再比如部署后的健康检查，不再靠人盯着Kibana看图，而是让CI流程自动调用验证接口：
curl -s http://service-health-checker:8080/validate \n -d '{"service": "order-api", "env": "prod"}' \n | jq '.status' \n | grep -q 'healthy'不通过就自动回滚。虽然初期要花时间写和调试，但一个月省下的半夜起床次数，足够回本了。
工具之外，关键是文化
SRE不是买套监控系统就能落地的事。我们每周开一次‘无责回顾会’，谁都不能甩锅，只聊‘系统哪里不够健壮’。有次连产品同学都来了，听完才发现自己提的一个‘小优化’会导致缓存雪崩，当场改需求。
真正的SRE实践，不是追求零故障——那不可能。而是让故障变得更便宜，恢复得更快，顺便推动整个团队更懂系统。