告警 OnCall 错误实践，看看你中了几条
快猫运营团队
2025-02-24 16:17:52
在告警 OnCall 实践中，存在一些常见的错误做法，这些错误可能会影响故障处理的效率、团队的协作以及系统的稳定性。以下是一些典型的错误实践及其改进建议：
缺乏明确的告警分级和响应机制
配置告警规则时，没有仔细斟酌告警级别，最终整体都很混乱，导致所有级别的告警都不敢怠慢，导致高优先级问题被延误，低优先级问题占用过多资源。
改进建议：
- 一般建议把级别分成 P1、P2、P3 三个级别，级别太多了配置规则的时候心智负担太重，会草草选一个级别，导致级别划分混乱
- P1 是最高级别，最严重的告警，通常是影响了用户的核心主流程，需要立即处理，通常采用打扰性强的通知媒介，比如电话、短信等
- P2 是次高级别，影响了一些非核心功能，或者需要尽快处理要不然就会演变成故障，通常采用打扰性一般的通知媒介，比如短信、IM等
- P3 是最低级别，通常不影响用户使用，但是有潜在风险，比如如果一周不处理，可能就会导致问题，通常不需要立即处理，每天下班之前统一看看就行，可以不通知，也可以用邮件等打扰性较弱的渠道来通知
过度依赖个人经验，缺乏标准化流程
故障处理完全依赖个别资深成员的直觉和经验，缺乏标准化的 SOP（标准操作流程）。经验靠人口口相传，尤其是在团队成员变动频繁的情况下，容易出现问题。另外脑子里的东西在紧急情况下容易紧张、出错。
改进建议：
- 建立详细的故障处理手册和 SOP，确保即使是新人也能快速上手。同时，定期更新 SOP 以应对新的故障场景。
- 还要组织演练，做 SOP 保鲜，长时间不维护的 SOP 很可能已经过时了，演练的时候发现问题及时修正，保证 SOP 的实时性和准确性。
忽视故障复盘
故障解决后未进行复盘，导致类似问题重复发生。或者复盘时太过随意，头痛医头脚痛医脚。
改进建议：
- 通常可以连续问多次 Why，即可增加深度。但是也不能太深，如果问到极致，那都是组织的问题或者文化的问题，作为底层团队这就没法解决了
- 举一反三，这个能力太重要了，优秀工程师和普通工程师的巨大区别之一就是举一反三的能力
OnCall 压力分配不均
OnCall 任务集中在少数人身上，导致团队成员倦怠，甚至离职。名义上是整个团队都接告警，实际上是某个老实人接了大部分，压力不均。
改进建议：
- 制定公平的轮值制度，确保每个成员都能参与 OnCall，并给予适当的补偿（如调休或奖金）。
- 设置主备 OnCall 机制，避免单点压力过大。可以引入一些专门的 OnCall 工具提升效率，比如 FlashDuty，就内置了排班能力。
当然了，新人也不要太过抗拒 OnCall，以我个人经验来看，OnCall 其实是提升个人成长的很好的方式。不过 OnCall 的时候如果要做操作，新人一定要得到老人的指导，不要瞎操作，否则很容易引发更大的问题。类似有一个审批的流程，这样新人按照流程走，出了问题也没有责任。
忽视工具和自动化建设
故障处理依赖手动操作，效率低下且容易出错。尤其是一些老人，已经熟悉了手动操作的流程，不愿意去学习新的工具，不愿意去建立自动化流程。
改进建议：
- 投资建设监控、告警和自动化工具，减少手动操作。例如，通过自动化脚本快速回滚服务或切换集群。
- 一键止损工具，本质上是经验的沉淀，比 SOP 手册来得更可靠。
未建立有效的沟通和升级机制
故障发生时，信息传递不畅，导致响应延迟或资源调配不当。比如没有及时 involve 进来相关的人，没有及时通知业务和 leader。处理过程中的进展没有及时通报。
改进建议：
- 建立清晰的沟通流程（如 War Room 机制）和升级路径，确保故障信息能快速传达给相关人员，并根据严重程度及时升级。
- Google SRE 那本书有讲，对外沟通传递信息是很重要的一环，是由一个专人负责的。故障时，有人指挥统筹，有人负责处理，有人负责沟通，多人协作。
总结
OnCall 实践的核心在于快速响应、高效协作和持续改进。通过避免上述错误实践，团队可以显著提升故障处理效率，降低系统风险，同时减轻 OnCall 人员的压力。
