告警 OnCall 做不好，问题通常不是“没人愿意值班”，而是告警分级、响应流程、复盘机制、压力分配和工具建设没有设计清楚。结果就是：低价值告警打扰所有人，真正重要的问题反而被淹没；故障处理靠少数老同学经验；事故结束后没有改进，下次继续重复。
本文梳理几类常见错误实践，并给出可落地的改进方向。
核心要点
- 告警必须分级，否则所有问题都会挤进同一条响应链路。
- OnCall 不能依赖个人经验，需要 SOP、Runbook 和演练机制。
- 故障复盘不是写报告，而是推动告警规则、流程、工具和系统设计改进。
- 值班压力需要被度量和分摊，不能长期压在少数人身上。
- 工具和自动化不是锦上添花，而是降低误操作、缩短响应时间的基础能力。
缺乏明确的告警分级和响应机制
第一个常见错误，是配置告警时没有认真区分严重级别。所有告警都差不多，所有告警都要通知，最终会出现两个后果：高优先级问题被低价值告警淹没，低优先级问题占用过多响应资源。
改进建议是把级别设计得足够简单，并且和通知方式、响应时限绑定：
- P1：最高级别，通常代表用户核心流程受影响，需要立即处理，可使用电话、短信等强触达方式。
- P2：次高级别，影响非核心功能，或可能演变成故障，需要尽快处理，适合短信、IM 等中等打扰方式。
- P3：最低级别，通常不直接影响用户，但存在潜在风险，可以进入待办、邮件或工作时间统一处理。
级别不要设计太多。级别越多，配置规则时心智负担越重，最后反而容易乱选。
过度依赖个人经验，缺乏标准化流程
第二个错误，是故障处理完全依赖个别资深成员的直觉和经验。经验靠口口相传，一旦人员变动、夜间处理、多人协作或新人值班，就容易出错。
改进建议：
- 为高频故障建立 SOP 和 Runbook，明确判断步骤、止损动作、升级对象和注意事项。
- 定期组织演练，验证 SOP 是否仍然有效。
- 复盘时更新文档和自动化脚本，避免手册长期不维护。
忽视故障复盘
第三个错误，是故障解决后不复盘，或者复盘只停留在“这次怎么修好”的层面。这样会导致类似问题重复发生，团队看似忙于救火，实际上没有积累系统改进。
改进建议：
- 复盘时可以连续追问多个 Why，找到更靠近根因的改进点。
- 追问要适度，最终要落到团队能执行的改进项上。
- 要举一反三：同类告警、同类服务、同类配置、同类流程是否也存在风险。
- 改进项要有负责人和截止时间，否则复盘只是记录。
OnCall 压力分配不均
第四个错误，是 OnCall 任务集中在少数人身上。名义上是整个团队都接告警，实际上是少数人接了大部分电话、处理了大部分夜间问题，时间久了很容易倦怠。
改进建议：
- 制定可执行的轮值制度，确保成员长期承担的中断成本接近。
- 对夜间、周末、节假日响应给予适当补偿，例如调休或奖金。
- 设置主备 OnCall 机制，避免单点压力过大。
- 使用专门的 OnCall 工具提升排班、通知和升级效率，例如 Flashduty 内置了排班能力。
新人也不必过度抗拒 OnCall。OnCall 是理解系统、提升排障能力的好机会。但新人执行高风险操作时，应该有老同学指导或审批机制，不能在紧急场景下盲目操作。
忽视工具和自动化建设
第五个错误，是故障处理长期依赖手动操作。手工登录机器、复制命令、切换集群、清理磁盘、回滚服务，在压力大的事故现场都容易出错。
改进建议：
- 投入监控、告警和自动化工具建设，减少手动操作。
- 把高频止损动作沉淀为脚本或工具，例如回滚服务、切换集群、清理磁盘。
- 对高风险自动化动作设置权限、审批和审计。
- 一键止损工具本质上是经验沉淀，很多时候比只写在 SOP 里的步骤更可靠。
未建立有效的沟通和升级机制
第六个错误，是故障发生时没有清晰的沟通和升级机制。相关人员没有及时参与，业务方和负责人不知道当前状态，处理进展也没有固定节奏同步。
改进建议：
- 建立清晰的沟通流程，例如重大故障作战室机制。
- 设计升级路径，明确无人认领、超时未恢复、影响扩大时通知谁。
- 故障时明确角色：有人指挥统筹，有人负责技术处理，有人负责对内外沟通。
- 处理过程要记录关键时间点、判断依据和处置动作，方便复盘。
总结
OnCall 实践的核心是快速响应、高效协作和持续改进。避免这些错误实践，团队才能提升故障处理效率、降低系统风险，同时减轻值班人员压力。
最小可行动作可以从三件事开始：重新梳理告警分级，建立主备值班和升级规则，把最近几次故障的复盘改进项落到告警规则、SOP 或自动化工具里。
FAQ
Q1：告警级别是不是越细越好？ A：不是。级别太多会增加配置负担，也容易选错。多数团队先用 P1、P2、P3 三档就够了，关键是每档绑定明确响应方式。
Q2：新人适合参与 OnCall 吗？ A：适合，但要有指导、Runbook 和审批机制。新人可以从观察、低风险处理和白天值班开始，逐步承担更复杂场景。
Q3：复盘最重要的产出是什么？ A：不是报告本身，而是可执行改进项，例如优化告警规则、补充 Runbook、建设自动化止损工具、修正升级路径或明确服务 owner。
