很多团队以为 On-call 的核心是“把告警发出去”。
这只说对了一小部分。
真正的线上故障处理，不是从一条通知开始，也不是在某个人看到消息后结束。它应该是一条完整链路：告警进入系统，被整理成可处理的故障；故障被分派给正确的人；没人响应时自动升级；处理过程中能协同、记录、补充上下文；需要对外沟通时有统一口径；结束后能复盘、归档，并把改进项继续跟踪下去。
如果这条链路断在任何一环，团队都会付出代价。
告警发到了群里，但没人认领。
一线值班看到了，但不知道该找谁协助。
故障恢复了，但没有记录根因和处理过程。
复盘会上大家只能翻聊天记录、监控截图和零散工单。
下个月相似问题再次出现，又从头排查一遍。
这不是某个通知渠道的问题，而是故障响应闭环没有设计好。
一套成熟的 On-call 机制，应该把“收到告警”变成“完成一次可追溯、可复盘、可改进的故障处理”。
第一步：把告警变成可处理的故障
故障响应的起点不是通知，而是对象建模。
监控系统上报的是事件。事件触发告警。告警再触发故障。多条相似的活跃告警，可以聚合到同一条故障中，一起分派、通知和处理。
这个模型很重要。
如果没有故障这一层，值班人面对的就是一堆离散告警。CPU 告警、接口超时、数据库连接异常、Pod 重启，每条都像一个独立问题。真正处理时，大家又要在群里人工判断这些告警是不是同一个故障引起的。
引入故障对象之后，响应系统的主语就变了。
团队不再处理“100 条告警”，而是处理“支付服务不可用”这一个故障。关联告警、事件、标签、处理人员、时间线、工单和复盘，都围绕这个故障展开。
Flashduty 的故障模型采用 事件 Event → 告警 Alert → 故障 Incident 的结构。故障可以由监控集成自动触发，也可以在控制台手动创建，或由外部人员通过提报链接提交。自动触发的故障会带上原始告警标签，标签后续可用于检索、路由、聚合和分析。
这一步的设计目标很明确：把监控系统产生的信号，整理成一个人可以负责、团队可以协作、管理者可以追踪的处理对象。
第二步：按规则分派，而不是靠群里喊人
故障创建后，最关键的问题是：谁负责？
很多团队在小规模阶段靠群消息解决。告警机器人往群里一发，谁看到了谁处理。这个方式有两个隐患。
第一，所有人都被打扰。
第二，没有人真正负责。
一旦团队变大，业务线增多，值班人轮换，群消息就会变成一种很不可靠的责任分配方式。大家都看到了，但没有人确认自己是处理人；真正值班的人可能被消息淹没；低级别告警和 Critical 故障混在一个群里，重要问题反而不突出。
更稳妥的做法，是让分派策略承担责任分配。
一条分派策略至少要回答六个问题：
- 这条策略在什么时间生效。
- 哪些故障会命中这条策略。
- 通知给个人、团队，还是当前值班表。
- 通过 App、语音、短信、邮件、IM 单聊还是群聊触达。
- 是否设置首次通知前的延迟窗口。
- 未认领或未关闭时如何升级到下一环节。
Flashduty 的分派策略按顺序匹配，匹配成功后停止继续匹配。触发条件可以按时间、服务日历、严重程度、标题、标签等维度筛选；通知对象可以选择值班表、团队、个人，也可以组合；通知方式既支持单聊，也支持飞书、钉钉、企业微信、Slack、Microsoft Teams 等群聊和机器人渠道。
这里最实用的配置通常不是复杂规则，而是清晰分层。
例如：
Critical 生产故障：立即通知当前主值班人，使用 App + 语音；10 分钟未认领升级给备值班；30 分钟未关闭升级给团队负责人。
Warning 级别故障：进入业务群和当前值班人 IM 单聊，不打电话；持续未关闭时再升级。
Info 级别提醒：只进群或邮件，不进入强触达链路。
这不是为了显得流程复杂，而是为了避免两种极端：所有告警都电话轰炸，或者所有告警都进群等人看见。
第三步：通知要能触达，也要能操作
On-call 通知的质量，不只看“发没发出去”。
更重要的是：值班人能不能及时收到，收到后能不能直接处理。
一个合格的通知链路，至少应该覆盖三类场景。
第一类是移动处理。值班人不一定坐在电脑前，手机端必须能查看、认领、关闭、升级故障。Flashduty App 支持核心故障处理操作；iOS 可使用 Critical Alerts 关键告警能力，Android 支持主流厂商系统级推送通道。
第二类是强触达。重大故障不能只依赖 IM 消息。语音电话、短信、邮件仍然有价值，尤其适合升级环节、IM 失效兜底和弱网络场景。语音通知还支持按键交互，播报结束时可以按键完成认领。
第三类是协作工具内处理。国内团队大量响应动作发生在飞书、钉钉、企业微信里。Flashduty 的 IM 应用集成支持交互式卡片，成员可以在消息卡片上认领、关闭、升级故障；账户与 IM 账户关联后，可以减少重复登录带来的操作摩擦。
这会直接影响 MTTA。
如果通知只是一个文本链接，值班人需要打开浏览器、登录系统、找到故障、再点击认领，很多人会拖到回到电脑前再处理。反过来，如果消息卡片、App 或语音按键就能认领，第一次响应会更快，也更容易被记录下来。
Flashduty 的 MTTA 统计也围绕认领动作计算：故障整体 MTTA 是故障触发到首次被认领之间的差值；个人 MTTA 则基于每个人的分派时间和认领时间计算。
这说明响应不是一个主观描述，而是可以被记录和衡量的动作。
第四步：无人响应时必须自动升级
On-call 机制里最危险的不是“告警没有通知”，而是“通知了但没人处理”。
这类问题在复盘时经常出现：
告警确实发了。
群里确实有消息。
值班人确实收到了。
但没有人认领，也没有人继续追。
如果系统不能自动升级，后续只能靠人工催促。凌晨场景下，人工催促本身就不可靠。
自动升级应该成为分派策略的一部分。
Flashduty 支持多级分派环节。升级条件可以配置为“未关闭”，也可以配置为“未关闭且未认领”。如果当前环节在指定时间内没有完成处理，系统会升级到下一环节。每个环节还可以开启重复通知，按设定间隔和次数继续提醒。
这里需要注意一个设计原则：升级条件要和团队责任边界匹配。
如果目标是避免故障无人响应，使用“未关闭且未认领”更合适。只要有人认领，说明故障已经进入处理状态，系统可以给处理人调查时间。
如果目标是确保故障在一定时间内真正解决，使用“未关闭”更合适。即使有人认领，只要超时未关闭，也要让更高层级或二线专家介入。
处理中还需要一个“暂缓”机制。处理人认领后，如果需要时间调查，可以暂缓升级。Flashduty 的暂缓操作会暂时停止故障按预期分派策略继续升级；暂缓到期后，如果仍未完成处理，故障会回退为待处理并重新发起分派通知。
这比简单的“我在看”更可靠。
因为系统不仅记录了有人在处理，还记录了这个处理承诺何时到期。
第五步：处理过程要沉淀在故障详情里
故障处理最容易丢失的是上下文。
真正排查时，信息会散落在很多地方：监控大盘、日志系统、群聊、工单、截图、值班人口头描述、临时会议纪要。故障结束后，再想还原“当时发生了什么”，往往很困难。
所以故障详情页不应该只是告警正文的展示页，而应该是故障上下文中心。
Flashduty 的故障详情包含故障标题、严重程度、处理进度、描述、标签、处理人员、关联告警、关键时间节点、外部工单、关联链接、自定义字段等信息。详情页的时间线会记录故障生命周期中的触发、分派、通知、认领、暂缓、关闭、评论等动作。
处理过程中，团队可以在时间线里添加 Markdown 评论，记录排查笔记、判断依据、临时处置动作，也可以粘贴或上传图片。评论会作为时间线记录追加到当前故障中，和系统动作并列展示。
这对复盘非常关键。
复盘不是事后凭记忆写报告。它应该从处理现场自然生成材料：谁在什么时候收到了通知，谁认领了故障，谁被添加为处理人，什么时候暂缓，什么时候关闭，期间做过哪些判断，哪些截图和链接支持这些判断。
如果这些信息都沉淀在故障详情中，复盘质量会高很多。
第六步：重大故障要有作战室
不是所有故障都需要多人协同。
但一旦进入重大故障，单靠一个告警群就不够了。
重大故障通常需要多角色参与：一线值班、业务研发、数据库、网络、平台、客服、管理者。大家需要共享状态、同步决策、减少重复沟通，并且在故障结束后保留关键讨论记录。
Flashduty 的作战室面向这种场景设计。它可以为活跃故障在飞书、钉钉、企业微信或 Slack 中创建专属沟通群组。故障处理人变更时，相关人员可以自动同步到作战室；作战室内可以接收故障状态更新，也可以进行认领、关闭、暂缓等操作。作战室相关操作会记录在故障时间线中。
作战室解决的是一个很具体的问题：把临时协同从“到处拉群”变成“围绕故障自动组织”。
处理人变化，成员同步。
故障状态变化，群内同步。
操作发生，时间线留痕。
故障关闭后，可以解散作战室。
这里也要注意边界。作战室是专业版及以上能力，并且同一时间系统仅支持为一个 IM 集成开启作战室功能。Microsoft Teams 集成目前不支持作战室；如果团队需要作战室，应优先选择飞书、钉钉、企业微信或 Slack 集成。
第七步：需要对外沟通时，用状态页统一口径
故障处理期间，技术团队最怕一边修问题，一边反复回答“现在恢复了吗”“影响哪些服务”“什么时候好”。
如果这些问题都通过私聊、群聊、邮件临时回答，很容易出现三个问题：
信息不一致。
更新不及时。
技术人员被重复打断。
状态页的价值，是给内部和外部受众一个统一的信息发布窗口。
Flashduty 状态页支持公开状态页和内部状态页。公开状态页面向客户和合作伙伴，无需登录即可访问，并支持邮件订阅事件更新。内部状态页面向组织内部成员，需要 Flashduty 账号登录，支持通过飞书、钉钉、企业微信、Slack 等 IM 集成接收事件推送。
状态页通过组件和分组组织服务，通过事件传达服务状态变化。事件类型包括故障和维护；故障影响状态可以区分为运行正常、性能下降、部分中断、完全中断。
这里需要写清楚一个现实边界：状态页不是监控探测工具，也不是自动替技术团队判断影响范围的工具。它的重点是正式沟通。当前向状态页发布事件需要在状态页管理页面中手动声明，可以通过事件模板快速发布故障或计划维护，并通过时间线更新持续同步进展。
这意味着，状态页应该纳入重大故障流程，但不要把它误解成“自动恢复通知机器人”。
一个实用流程是：
确认影响用户或跨团队依赖
→ 在状态页发布故障事件
→ 选择受影响组件和影响状态
→ 每次关键进展添加时间线更新
→ 故障恢复后关闭事件
→ 复盘时回看状态页沟通是否及时、准确
这能把“修复系统”和“同步信息”分开，让技术团队在统一口径下工作。
第八步：工单系统负责跟踪，On-call 平台负责响应
很多企业已经有 Jira、ServiceNow 或 ServiceDesk Plus。
这些系统适合做需求、缺陷、ITSM 流程和后续任务跟踪，但它们通常不是实时故障响应的第一现场。On-call 平台更适合处理告警触达、值班分派、升级、认领、协同和时间线。
更合理的关系不是二选一，而是联动。
Flashduty 支持通过 Webhook 集成与 Jira、ServiceNow、ServiceDesk Plus 等系统同步。Jira 同步可以把 Flashduty 故障关联到 Jira Issue，支持自动触发或在故障详情页手动触发；已创建 Issue 的故障在严重程度、状态更新时可以同步到 Jira，评论也可以同步过去，但 Jira 中的更新不会反向同步到 Flashduty。
ServiceNow 同步支持将 Flashduty 故障同步至 ServiceNow，也支持从 ServiceNow Incident 同步至 Flashduty，或配置双向同步。ServiceDesk Plus 也支持 To_ServiceDesk_Plus、From_ServiceDesk_Plus 和 Two-way 三种方向。
这些边界很重要。
如果团队使用 Jira 管理研发改进项，可以把故障同步为 Issue，便于后续排期和跟踪。
如果企业 ITSM 主流程在 ServiceNow，可以让 Incident 与 Flashduty 故障互相关联。
如果只是想在故障结束后沉淀行动项，也可以在复盘报告里记录跟进事项。
不要让工单系统替代 On-call 响应，也不要让 On-call 平台变成长期项目管理工具。两者职责清楚，闭环才不会变形。
第九步：故障关闭后，复盘才刚开始
很多团队把故障关闭当成终点。
对业务来说，服务恢复当然是第一优先级。但对稳定性建设来说，恢复只是进入复盘的起点。
一份有效的复盘报告，至少应该回答三个问题：
发生了什么。
为什么发生。
怎样避免再次发生。
Flashduty 的故障复盘能力可以从故障详情页创建复盘报告。创建时选择故障和模板，系统会提取严重程度、处理时间、响应人员等基本信息，生成草稿报告。报告支持在线协作编辑、自动保存、发布、重新编辑和删除；同一个故障目前只能对应一份复盘报告。
复盘报告通常包含关联故障、基本信息、报告正文、跟进事项和作者列表。正文可以按模板组织，例如综述、根因分析、影响范围、处理时间线、改进措施和经验教训。系统提供中英文内置模板，也支持团队创建自定义模板。
AI 生成可以降低复盘起稿成本。AI 会分析关联故障上下文，按模板章节生成初稿。可参考的数据包括模板结构、故障详情、处理时间线，以及在具备权限的飞书或 Slack 作战室中的聊天记录。AI 生成的内容应该作为起点，而不是最终结论；真正的根因共识和改进措施仍然需要团队确认。
复盘最关键的不是“写完报告”，而是形成改进闭环。
如果报告里有“优化数据库连接池配置”“补充熔断规则”“调整告警阈值”“完善 Runbook”这类行动项，就应该明确负责人和跟进方式。否则复盘只会变成一次文档归档。
一次完整闭环应该长什么样
把以上环节串起来，一次完整 On-call 闭环可以设计成这样：
监控系统上报告警事件
→ Flashduty 触发告警并聚合为故障
→ 根据标签、严重程度和服务归属匹配分派策略
→ 通知当前值班人，并在 IM 群或 App 中同步
→ 值班人认领，故障进入处理中
→ 超时未认领或未关闭时自动升级
→ 需要多人参与时创建作战室
→ 处理过程中记录评论、截图、链接和关键判断
→ 必要时同步 Jira / ServiceNow / ServiceDesk Plus 工单
→ 对内或对外通过状态页发布故障事件和进展更新
→ 故障恢复后关闭故障
→ 从故障详情创建复盘报告
→ AI 生成初稿，团队协作完善
→ 发布复盘，跟踪改进项
这条链路的重点不是“功能很多”，而是每一步都有明确责任。
监控系统负责发现信号。
On-call 平台负责响应编排。
IM 和作战室负责实时协同。
状态页负责统一沟通。
工单系统负责后续跟踪。
复盘报告负责沉淀经验和改进项。
职责分开之后，故障处理才不会靠临场发挥。
先从一条真实告警跑通
搭建 On-call 闭环，不需要一开始就把所有系统全部接入。
更务实的方式，是选择一个真实业务服务，先跑通一条 Critical 故障流程。
你可以从这几件事开始：
- 接入一个告警源，例如 Prometheus、Zabbix、夜莺或云监控。
- 确保告警带有稳定标签，例如
service、env、severity、team。 - 为该服务创建分派策略，配置主值班、备值班和升级规则。
- 配置 App、IM、语音或短信通知渠道。
- 验证值班人能在 App、IM 卡片或语音中完成认领。
- 打开故障详情，确认时间线记录完整。
- 模拟未认领或未关闭场景，检查升级是否生效。
- 对重大故障演练作战室和状态页发布流程。
- 故障关闭后创建复盘报告，检查时间线、评论、作战室记录是否能支撑复盘。
这个验证过程比看功能清单更有价值。
因为 On-call 闭环最终验证的不是“有没有某个按钮”，而是当真实故障发生时，团队能否更快找到负责人，更少打扰无关人员，更清楚地同步状态，并在事后留下可复盘、可改进的记录。
Flashduty 更适合从这里切入：不替换现有监控系统，先把告警接住、聚合、分派、升级、协同和复盘跑通。
先用一次真实故障验证完整闭环。
👉 现在注册试用
参考资料
- Flashduty 产品与文档：故障、告警和事件模型，故障生命周期，故障详情与时间线，分派策略，通知渠道，作战室，状态页，Jira / ServiceNow / ServiceDesk Plus 同步，故障复盘与 AI 生成复盘报告。
