告警是自己恢复，还是被规则关掉？复盘时不能混成一种状态

复盘从一句话卡住

晨会前二十分钟，运维负责人小周被问到一个很具体的问题：昨天下午那批接口超时告警，到底是业务恢复了，还是规则自动关掉了？

他手里有告警列表，也有关闭率。列表上红点已经消失，几条告警都不再活跃。可继续往下追，现场开始卡住：有的告警是值班同学点了关闭，有的是恢复事件推回来的，还有几条是聚合告警过了不活跃时间后自动关闭的。

这时，“都结束了”反而变成最没有用的答案。

告警复盘真正要追的不是红点还在不在，而是它为什么离开了现场。

病根：结束口径太粗

很多团队日常看告警，只会先盯未分派、待处理、处理中。这个动作没有问题，值班现场最怕的是活跃告警没人接。

但复盘不是值班大屏。复盘要回答的是另一组问题：

• 谁接过这条告警？
• 有没有人做过处置判断？
• 系统有没有收到恢复事件？
• 如果没有恢复证据，它是不是只是被规则超时关闭？

如果所有结束状态都被压成“已处理”，关闭率会很好看，诊断价值会很低。小周面对的正是这个问题：列表已经安静，但每条告警安静下来的原因并不一样。

一、人工结束

先看谁接手

告警进入多人协作后，状态不能靠口头约定。

未分派告警如果能直接关闭，复盘时就不知道谁接过。待处理告警如果没人认领却显示完成，责任链也会断。处理中告警如果被反复转派，事后很难判断到底是谁在什么阶段做了判断。

BK Lite 告警中心把告警状态拆成未分派、待处理、处理中、已解决、已关闭、自动关闭、自动恢复。状态迁移也有明确边界：分派从未分派到待处理，认领从待处理到处理中，转派从处理中回到待处理，关闭从处理中到已关闭，恢复从处理中到已解决。

非法前置状态下的操作会被拒绝。这个约束不是为了把流程做重，而是为了避免告警被随手改成一个看似完成的结果。

人工关闭要结合操作记录

人工关闭和人工恢复都说明有人做过判断，但它们仍然需要结合操作记录看。

一条告警被关闭，可能代表故障已经处理，也可能代表暂时不再跟进。小周在复盘里真正需要的，不只是“已关闭”三个字，而是这条告警什么时候进入处理中、谁认领过、有没有转派、最后是谁关闭。

只有这条处理链清楚，人工结束才有复盘价值。

二、自动恢复

恢复不是修复

自动恢复很容易被误解。

它不是平台替团队把故障修好了，而是告警链路里出现了恢复证据。外部告警源接入后会形成标准事件，再按指纹聚合为告警。恢复事件通过 external_id 关联历史创建事件；只有创建事件都被更晚的恢复事件覆盖时，告警才会进入自动恢复状态。

这意味着，自动恢复回答的是事件链路问题：异常和恢复是否都被标准化地送进来，二者能不能稳定关联。

自动恢复能反查事件质量

如果某类告警经常自动恢复，小周可以继续看恢复事件来自哪里、和创建事件是否共用稳定标识、时间关系是否合理。

如果某类告警很少自动恢复，也不能立刻判断是一线没有处理。更可能的检查方向是：外部告警源是否只上报告警事件，不上报恢复事件；或者字段变化导致恢复事件无法和创建事件稳定关联。

自动恢复不是根因结论，但它给复盘提供了一条很重要的证据线。

三、自动关闭

规则到点不是业务恢复

自动关闭和自动恢复只差两个字，语义却完全不同。

对聚合告警来说，相关性规则可以按 close_minutes 自动关闭，并通过定时任务兜底。默认口径里，close_minutes 为 120 分钟，自动关闭默认开启。

这个机制有必要。聚合告警本来就是把同类事件收敛成一个处理对象，如果长期没有新事件，继续挂在活跃列表里会干扰值班判断。

但自动关闭没有提供恢复证据。它只说明这条聚合告警满足了规则定义的关闭条件。

自动关闭多时要反查规则

当小周发现一批告警主要靠自动关闭结束时，复盘方向就变了。

这时不应简单说“告警都处理完了”，而要继续追问：

• 恢复事件是不是缺失？
• close_minutes 是否过短或过长？
• 聚合规则是否让同类告警过早退出？
• 外部告警源的上报口径是否稳定？

还有一个边界要单独看：即时告警不参与自动关闭。命中即时告警策略的事件会直接生成独立告警，不进入聚合主路径，事件数恒为 1，只能通过人工处置或自动恢复结束生命周期。

技术洞察：状态是复盘语言

告警状态不只是列表字段。它应该成为团队复盘时的共同语言。

复盘口径	对应状态	主要回答的问题
活跃状态	未分派、待处理、处理中	响应链路有没有卡住
人工结束	已解决、已关闭	有没有人做过处置判断
系统恢复	自动恢复	恢复事件链路是否可靠
规则关闭	自动关闭	聚合规则和关闭窗口是否合理

这张表能把小周面对的混乱拆开。不是所有结束都叫恢复，也不是所有关闭都代表有人处理。状态越清楚，复盘越少依赖口头解释。

BK Lite 的切入点

BK Lite 告警中心补上的，是告警生命周期里的状态口径断点。

多源事件先被标准化为事件和告警；告警列表支持按状态、级别、来源、资源、时间范围筛选；告警详情可查看原始事件、邻近告警等上下文；生命周期上保留分派、认领、转派、关闭、恢复，也保留自动恢复和自动关闭。

这些能力不是为了让页面多几个标签，而是为了让一条告警从进入现场到离开现场都有可解释的路径。

对复盘来说，这条路径比一个总关闭率更有价值。

上手前先问几句

如果要把告警状态真正用起来，可以先检查这几个问题：

• 值班看板是否区分未分派、待处理、处理中，而不是只看告警总数？
• 人工关闭和人工恢复是否能在操作记录里追到处理人和时间？
• 外部告警源是否同时上报告警事件和恢复事件？
• 恢复事件能否通过稳定标识关联历史创建事件？
• 自动关闭比例是否过高，是否需要回看关闭窗口和聚合规则？
• 即时告警是否被当成聚合告警来理解，误以为它也会自动关闭？

这些问题不需要一次性把告警治理做成大工程，但能帮助团队先把复盘口径立住。

结语

告警最终都会结束，但结束原因不能被抹平。

人工关闭说明有人判断过，自动恢复说明事件流里有恢复证据，自动关闭说明规则到了兜底条件。把这三件事分清楚，团队才知道下一步应该优化响应流程、事件上报，还是相关性规则。

复盘要的不是“红点消失了”，而是一条能解释清楚的生命周期。