on-call

背景 先抛一个我自己被戳到的数字：我带过的团队里，P1 以上事故平均每月 1.2 起，每起复盘平均产出 6–8 条改进项；但半年后回看，真正"可验证地生效"的不到 40%。剩下的不是没人做，而是三类：a) 做了但没有对照数据证明有效；b)

背景 做了 15 年运维，从 2012 年写 crontab 脚本自动拉起进程，到今天在 K8s 里配 liveness 探针 + 自动驱逐重启，"自愈"这个词我们喊了十几年。但每次事故复盘，绕不开一个问题：这条自愈链路，到底是救了我们，还

背景 先讲一个我亲历、且至今还会被翻出来的场景。 凌晨 2:47，一条 P0 告警把 on-call 的值班同学（一位入职 9 个月的后端）从床上叫醒：支付接口 5xx 率从 0.3% 飙到 12%，持续了 4 分钟。按团队 SOP，回滚需

背景 最近几次复盘 P0/P1 故障，我发现一个挺尴尬的现象：故障根因明明在网关超时、DB 抖动、第三方 SDK 异常，但被拉进 on-call、被写进复盘文档「改进项」的，往往还是前端。原因是用户看到的是「页面卡了 / 白屏了 / 按钮点