告警之后才是真正的故障响应
监控系统可以发现异常并发出告警，但故障响应还包括一系列后续动作：谁值班、告警是否重复、是否需要升级、影响范围有多大、需要谁协同、初步根因是什么、处理过程如何记录、后续如何复盘。
当这些动作分散在监控系统、IM 群、电话、工单和人工文档里时，团队很难持续降低 MTTA 和 MTTR。
典型问题包括：
- 告警发出后没有统一认领和升级流程。
- 值班人需要手工到多个系统里收集指标、日志、链路和变更信息。
- 故障影响范围不清晰，业务负责人和技术负责人看到的信息不同。
- 初步诊断依赖少数资深工程师经验，夜间和跨团队场景效率低。
- 复盘材料分散，处理过程和关键证据难以沉淀。
Flashcat 与 Flashduty 如何配合
| 阶段 | 主要能力 |
|---|---|
| 告警接收 | Flashduty 接收 Flashcat、Prometheus、Zabbix、Nightingale、云监控等告警源。 |
| 降噪分派 | 通过聚合、抑制、静默、路由、排班和升级减少无效打扰。 |
| 上下文收集 | Flashcat 提供指标、日志、链路、事件、RUM、北极星、灭火图等观测上下文。 |
| 根因初筛 | AI Agent 在受控权限内读取观测数据和诊断输出，生成初步排查报告。 |
| 协同闭环 | 值班人基于证据认领、处理、升级、协同，并沉淀 MTTA/MTTR 等数据。 |
推荐落地路径
- 先统一关键告警源，避免告警散落在多个系统和群聊。
- 按服务、团队、等级和时间段建立分派与升级策略。
- 对高频告警配置聚合、抑制、静默和风暴预警策略。
- 将故障相关指标、日志、链路、事件和变更信息接入统一观测视图。
- 选择高价值告警场景做 AI 根因初筛 POC，验证是否减少上下文收集时间。
- 用 MTTA、MTTR、告警压缩率、认领比例和升级次数持续优化响应流程。
适合什么团队
- 告警已经比较多，但告警之后的处理流程不稳定。
- 多套监控系统并存，需要统一响应中心。
- 值班人经常花大量时间收集上下文，而不是判断和止损。
- 需要电话、短信、IM、App 等多渠道触达和升级。
- 希望引入 AI 参与根因初筛，但不希望 AI 直接执行高风险生产变更。
