在日常运维工作中，我们经常会听到“故障”这个词，比如：
- 基础网络故障：比如某个光纤被挖断了
- 云平台故障：比如认证体系不工作了
- 业务系统故障：比如订单系统不可用了
- 数据库故障：比如 MySQL 挂了不再提供服务
用大白话来讲，就是生产环境的 IT 系统出现了问题，影响了其他服务或客户。
核心要点
- 监控系统天然看到的是指标、日志、事件和告警；“故障”是为了处理和协作抽象出来的工作对象。
- 在 Flashduty 这类 OnCall 平台中，故障可以理解为一批相似活跃告警的聚合；没有降噪时，故障可能近似等于一条告警。
- 故障的严重程度来自关联告警的最高级别，故障状态来自关联告警是否恢复，处理进度则来自人的认领、关闭和自动恢复动作。
- 故障标签来自事件和告警上报内容，决定后续过滤、检索、聚合和自动化处理效果。
在监控系统中，只有监控指标、原始事件和告警，并没有天然存在的“故障”实体。不同数据之间虽然可能有关联，但仅凭告警事件和指标数据，系统很难稳定识别出“真正的业务故障”。这是监控系统持续演进的方向，但在工程实践中，我们仍然需要一个可分派、可通知、可认领、可关闭的对象来推进处理。
这个对象，就是系统里的“故障”。问题变成：监控平台应该怎样抽象故障？
Flashduty 中的故障
以 Flashduty 举例，来看系统中的一些考虑。Flashduty 作为一个告警事件 OnCall 中心，会接收各类监控系统推过来的告警事件。当 Flashduty 接收到告警事件（比如Zabbix的一条告警通知），系统会自动触发一条告警，而这条告警将会触发一条故障。多条相似的活跃告警，可能会被聚合到同一条故障中，一起分派、通知和处理。我们可以简单的理解为：故障，是相似告警的组合，在没有降噪的情况下，故障等同于告警。反过来，降噪的场景下，故障等同于其关联的多条告警。
Flashduty 是 Flashcat 旗下的一款告警事件 OnCall 中心，提供告警事件的自动分派、收敛降噪、排班、认领升级等功能。助力企业快速响应故障，降低故障对业务的影响。
我们自然很想把某个故障关联的所有告警都汇聚在一起，但从技术上基本是不可能的。比如某个网络故障是光纤被挖断了，产生了很多告警，有的告警是机器失联，有的是 mysql 连不上了，有的是服务请求超时，这些告警的标题、描述、标签都不一样，基本很难自动聚合在一起。
但是，告警的颗粒度通常比较细，我们在处理告警的时候，不想一次只处理一条，比如我要认领告警，是希望能够批量认领的，所以有很强的需求是把一批告警聚合在一起，至少让我方便的批量处理，即便这个告警集合和真正的故障并非一一对应，但是也有很大的价值。
所以，在 Flashduty 这种 OnCall 平台里，把一批告警聚合成一个故障，也就很容易理解了。但是一堆告警，其严重程度、状态、处理进度都不同，和故障的对应关系是什么呢？
事件、告警和故障的关系
| 对象 | 含义 | 主要来源 | 典型用途 |
|---|---|---|---|
| 事件 | 原始监控系统推送过来的告警事件或恢复事件 | Zabbix、夜莺、Prometheus 等集成来源 | 记录原始事实，提供严重程度、标签和恢复信息 |
| 告警 | Flashduty 根据事件生成的告警对象 | 事件触发 | 承接事件状态，参与聚合、降噪和恢复判断 |
| 故障 | 一条或多条相似活跃告警聚合后的处理对象 | 告警触发和聚合 | 分派、通知、认领、升级、关闭和协作处理 |
这个模型的关键不是把“真实世界里的所有症状”一次性聚合得完全准确，而是先给响应流程一个稳定对象：谁负责处理，当前是否有人认领，严重程度是什么，关联告警有没有恢复，后续通知和自动化动作是否应该继续执行。
故障严重程度、状态和进度
严重程度
- Info：轻微，服务本身仍然正常运行，仅做服务状态提醒，无需立即处理。
- Warning：警告，服务可能出错或者即将发生问题，应尽早介入避免问题升级。
- Critical：严重，服务大面积出错甚至中断，用户受到影响，必须立即介入处理。
故障、告警和事件，均使用以上三种严重程度。严重程度首字母大写，您在使用 api 时需要特别注意。三者的严重程度生成规则如下：
- 事件的严重程度：不同集成来源（如Zabbix和夜莺）的告警事件有不同的严重程度枚举值，Flashduty会按照一定规则映射为以上三种标准严重程度。具体映射关系，请您参阅具体集成的接入文档。
- 告警的严重程度：等于所关联的事件中最高级别的严重程度。
- 故障的严重程度：等于所关联的告警中最高级别的严重程度。
处理进度
- 待处理：故障触发后，处理进度默认为“待处理”，系统会发起自动分派，设置处理人员并进行通知。
- 处理中：任意人员点击认领故障，处理进度将立即变为“处理中”。在此情况下，故障的处理人员可能处于已认领或未认领状态，但至少有一个人处于“已认领”状态。当所有处理人都取消认领，故障处理进度将回退到“待处理”。
- 已关闭：任意人员点击关闭故障，或故障自动恢复后触发自动关闭，处理进度将立即变为“已关闭”。
故障状态
告警的状态代表的是故障在原始监控系统中的状态，即“已恢复”或“未恢复”。故障的状态完全由其关联的告警来决定。
- 已恢复：故障关联的告警均已恢复，故障将自动恢复。
- 未恢复：故障关联的告警至少有一条未恢复，故障将处于未恢复状态。
💡 故障自动恢复将导致（处理进度）自动关闭；但手动关闭故障，对故障的状态没有任何影响。
故障标签
标签（Labels）是 Flashduty 中很重要的一个基础概念，不同的标签描述了告警、故障在不同维度的信息，并被大量应用于过滤、检索、聚合等场景。
标签是如何生成的？
告警的标签提取自原始告警系统上报过来的事件消息体。不同来源有不同的提取方式，大致上，我们采取 应取尽取 的原则。比如对于 Prometheus 来源的告警事件，Flashduty 会提取 Payload 中的 Labels 和 Annotations 信息。
标签只能通过事件上报得到，不能手动修改或添加。一个自动触发的故障，其标签永远等于其关联的第一条告警的标签。一个手动触发的故障，其标签永远为空。
另外 Flashduty 也提供了标签增强方案，用于自动化生成标签。
如何判断故障抽象是否合理
一个故障抽象是否合理，可以从四个问题检查：
- 是否方便响应：值班人能否围绕一个故障对象完成通知、认领、升级和关闭，而不是在多条告警之间来回切换。
- 是否保留原始事实：故障聚合之后，仍然能回看关联告警和事件，避免把原始监控信息丢掉。
- 是否支持降噪：相似告警可以合并处理，减少重复通知，但不强求系统自动识别所有真实世界的因果关系。
- 是否支持后续分析：严重程度、状态、进度、标签和时间线足够清晰，后续可以用于统计、复盘和流程优化。
总结
在监控系统中，故障不是原始数据，而是为了响应和协作建立的处理对象。Flashduty 把一批相似活跃告警聚合成一个故障，让团队可以围绕故障完成分派、通知、认领、升级、关闭和复盘。
故障的严重程度来自关联告警的最高级别，故障状态由关联告警是否恢复决定，处理进度由响应人员和自动恢复动作推动。故障标签则来自事件和告警，是过滤、检索、聚合和自动化处理的基础。
FAQ
Q1：故障一定等于真实业务故障吗？ A：不一定。系统中的故障是一个处理对象，通常由一条或多条相似告警聚合而来。它不保证和真实世界里的故障一一对应，但可以显著降低响应协作成本。
Q2：为什么不直接处理告警，而要再抽象故障？ A：告警粒度通常较细，一次真实问题可能触发多条告警。抽象故障后，团队可以批量认领、批量通知和统一跟踪处理进度。
Q3：手动关闭故障会改变告警恢复状态吗？ A：不会。手动关闭影响的是处理进度，不改变故障状态。故障状态仍然由关联告警是否恢复决定。
