【背景】 做了 15 年运维，从 IDC 裸机到 K8s 集群，经历过上千次线上故障。有一个现象我观察了至少 5 年：同一个团队、同一个 P1，值班的 A 先翻 application.log 找异常堆栈，B 直接 kubectl top 看资源，C 第一句话是"先重启试试"。谁都没错，但 11 分钟的"犹豫期"就这么耗掉了。
去年我们团队做过一次复盘统计：12 个月内 47 次 P1/P2，告警触发到人工介入平均 3 分 12 秒，但"第一次有效操作"（真正定位到根因方向的那一步）中位数是 11 分钟。拆下来，大约 60% 的时间浪费在"该看什么、该先动哪个"的犹豫上。
【常见分歧：三种典型做法】
- Runbook 派：每类故障一篇 checklist，告警触发后按步骤走。好处是新人 3 天能独立值班；坏处是遇到"组合故障"（CPU 飙 + 连接池打满 + 下游超时同时发生）时，checklist 会把你带偏——我见过一次 OOM 的 runbook 让你先扩内存，但根因其实是上游突发流量，扩了反而把下游 DB 压挂了。
- 资深直觉派：核心靠 2-3 个老运维的"手感"，新人跟着学。好处是罕见故障反应快（我师傅遇到一次 DNS 解析抖动，30 秒内就定位到 resolver 配置问题，比任何工具都快）；坏处是知识在个人脑子里，人一走全没了。
- 自动化派：能自动化的全自动化——自动扩容、自动重启、自动限流，人只处理"机器搞不定"的。好处是 MTTR 低；坏处是自动化规则本身会引入新故障。我们见过自动 HPA 把 4 副本扩到 20 副本，直接把下游 MySQL 的 active connection 从 80 打到 500，触发锁等待雪崩。
【我的倾向与理由】 我倾向于"分层响应"，具体分三层：
- L0（机器处理，目标 0 人工）：资源水位 > 80% 自动扩容（但设上限，比如最多扩到 8 副本，超过就告警）、Pod 不健康自动重启、单接口 QPS 突增 3 倍自动限流到基线 2 倍。
- L1（SOP 处理，目标 5 分钟恢复）：有明确 runbook 的故障——OOMKilled、Connection refused、磁盘 > 90%——值班人按步骤走，每步有明确命令和预期输出。
- L2（专家介入，目标 30 分钟定位）：L1 步骤走完仍未恢复，或故障模式不在 runbook 里，升级给资深，同时拉群同步时间线。
关键数字：我们按这个分层跑了 6 个月，P1 的"第一次有效操作"中位数从 11 分钟降到 4 分钟，P2 平均 MTTR 从 22 分钟降到 13 分钟。但代价也真实：runbook 从 12 篇膨胀到 34 篇，每次架构变更都要同步更新，维护成本大约 2 人天/月。
【想听大家在什么场景下怎么选】
- 你的团队故障响应是"有 SOP 但没人看"还是"真按 SOP 走"？runbook 覆盖率大概多少（按故障类型算）？
- 你遇到过"按 SOP 走反而更慢"的案例吗？具体是什么场景、卡在哪一步？
- 自动化的边界你画在哪里？"自动重启"你敢在生产开吗？什么条件下敢、什么条件下绝对不敢？
- 那 11 分钟的"犹豫期"，你觉得主要浪费在哪——是信息不够（监控看不全），还是决策权不够（不敢自己拍板重启）？
- 一个很实际的问题：runbook 写完半年后还有多少人记得它存在？你们怎么保证 SOP 不过期？
0赞
0收藏
0楼层