从 PagerDuty 到 Flashduty：AI 正在重新定义 SRE 的工作方式，RCA 是第一个真正落地的场景
从 PagerDuty 到 Flashduty：AI 正在重新定义 SRE 的工作方式，RCA 是第一个真正落地的场景
每一个 SRE 的一天，几乎都是从被告警吵醒开始的。
手机嗡嗡一响，你爬起来，点开告警，然后面对熟悉的画面：
- 20 条 CPU 告警
- 15 条内存告警
- 10 条 5xx 错误告警
- 5 条数据库慢查询告警
- 3 条网络延迟告警
然后你花了一个小时，把这 53 条告警一条一条看完，最后得出结论：
哦，这其实是同一个故障。是那个新上线的缓存服务 OOM 了，把整个节点拖挂了，引发了一连串的连锁反应。
这 53 条告警，其实是 1 个事故。
但是你花了一个小时，才搞明白这件事。
然后你还得再花一个小时，写 RCA 报告：
- 故障时间线
- 根本原因
- 影响范围
- 改进措施
而这，就是全球几百万 SRE 工程师每天的日常。
今天，这件事正在被 AI 彻底改变。
先说说 PagerDuty：行业标准，但它有一个天生的局限
在聊 AI 之前，我们得先聊聊 PagerDuty。
如果你做过 SRE 或者运维，你肯定知道 PagerDuty。它是整个告警和事故响应领域事实上的行业标准。全世界几乎所有像样的科技公司，都在用它或者类似的产品。
它解决的问题非常明确：
- 把各种监控系统的告警收集起来
- 去重、降噪、聚合
- 按排班表通知到正确的人
- 追踪整个事故响应的流程
这套东西非常成熟，也非常有用。但是它有一个天生的、无法靠传统工程手段解决的局限：
它能告诉你"出事了"。但它不能告诉你"为什么出事了"，也不能告诉你"该怎么修"。
PagerDuty 的工作流是这样的：
告警来了 → 通知你 → 你自己去查原因 → 你自己去修 → 你自己去写 RCA它是一个非常优秀的"信使"。但信使不负责破案。
而 SRE 工作里最累、最花时间、最需要经验的部分，恰恰是"破案"。
- 为什么这个告警会出现？
- 这几个告警之间有没有关联？
- 真正的根因到底是什么？
- 我应该先做什么来止损？
- 以后怎么防止再发生？
这些问题，PagerDuty 回答不了。OpsGenie 回答不了。VictorOps 回答不了。所有传统的告警平台都回答不了。
因为回答这些问题，需要理解。需要对整个系统的理解，对故障模式的理解，对过去发生过的类似事故的理解。
而理解，恰恰是 AI 最擅长的事情。
AI 在 SRE 领域最落地的场景：RCA
现在所有人都在说 AI+SRE。各种概念满天飞：
- AI 自动排查故障
- AI 自动修复
- AI 自动优化性能
- AI 自动写 runbook
但是如果你真的去看，会发现 99% 的东西都还在 Demo 阶段。真正能大规模落地、真正能每天帮你省时间的，其实只有一个场景：
RCA——根因分析。
为什么是 RCA？因为它完美满足了"AI 能很好地解决，人解决起来特别痛苦"的所有条件：
✅ 有明确的输入输出 输入：告警信息、监控数据、历史事故、知识库。 输出：根因分析、时间线、修复建议。
✅ 有明确的对错标准 分析得对不对，是不是根因，SRE 一眼就能看出来。不需要主观评判。
✅ 数据量足够大 每个公司都有大量的历史事故、大量的告警数据、大量的 runbook。这些数据就是最好的训练材料。
✅ 人的时间成本非常高 一个高级 SRE 工程师花 2 小时写 RCA，人力成本可能就是几千块。AI 几秒钟就能做完，而且质量可能更好。
✅ 经验可以沉淀和复用 最好的 SRE 的经验，可以通过 AI，变成所有人都能用的能力。不再需要靠口口相传，不再需要新人踩一遍所有的坑。
所以说，RCA 不是 AI 在 SRE 领域"一个"应用场景。它是第一个，也是目前唯一一个，真正达到了生产可用级别的场景。
为什么"针对每条告警做 RCA"是个伪需求
现在很多做 AI RCA 的产品，思路都是这样的：
来一条告警，我就给这条告警做一个 RCA。
这个思路听起来很直接。但在真实的生产环境里，这是完全行不通的。
为什么？
因为告警太多了。
一个中等规模的公司，一天可能有几千甚至几万条告警。 你给每条告警都做一个 RCA？
- 第一，成本太高。每条 RCA 花 10 美分，一天就是几百上千美元。
- 第二，根本没人看。99% 的告警，甚至都不会被人点开。
- 第三，没有意义。单个告警本身就不是根因，它只是根因的一个症状。
你发烧了去医院，医生不会对着"发烧"这个症状写根因分析。 他会问你：还有什么其他症状？咳嗽吗？喉咙痛吗？头疼吗？然后把所有症状合在一起，诊断你到底是感冒了，还是肺炎，还是其他什么病。
告警也是一样的。
- CPU 高不是根因，是症状
- 5xx 错误不是根因，是症状
- 慢查询不是根因，是症状
所有这些症状合在一起，才能诊断出真正的病是什么。
这就是 Flashduty 最核心的洞察：先聚合成事故，再做 RCA。
Flashduty 的思路：先聚合，再 RCA
Flashduty 的整个产品设计，都是围绕着这个核心洞察展开的。
它的工作流是这样的：
┌───────────────────────────────────────────────────────────────┐
│ 第一步：告警收集和降噪 │
│ 从所有监控系统接告警：Prometheus、Grafana、Datadog、Zabbix... │
└────────────────────────────┬──────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ 第二步：智能告警聚合 │
│ 把相关的告警聚合成一个 Incident（事故） │
│ 53 条告警 → 1 个事故 │
└────────────────────────────┬──────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ 第三步：AI RCA 分析 │
│ 针对这一个事故，而不是 53 条告警，做根因分析 │
│ 拉取所有相关的可观测性数据，检索历史类似事故，查询知识库 │
└────────────────────────────┬──────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ 第四步：通知和响应 │
│ 把带有完整 RCA 分析的事故，通知给对应的 SRE │
│ 他收到的时候，已经知道：大概是什么原因，该怎么修 │
└───────────────────────────────────────────────────────────────┘这个思路和传统方案的区别，本质上是因果关系的反转：
- 传统方案：因为有告警，所以通知你，你自己去看是不是事故。
- Flashduty：因为聚合成了事故，所以通知你，而且我已经帮你把根因分析好了。
这不是简单的顺序调整。这是整个工作范式的转变。
AI RCA 真正需要的四大能力底座
做一个能跑的 RCA Demo 很容易。 做一个能真正在生产环境用，SRE 工程师愿意用的 RCA 系统，非常难。
因为它不是调用一下 GPT-4，把告警塞给它，说"帮我分析一下根因"这么简单。
一个真正好用的 AI RCA，需要这四大能力底座，缺一不可：
🧱 底座 1：可观测性数据层（O11y Data）
AI 要分析根因，首先得能看到数据。就像医生要给你看病，首先得能拿到你的验血报告、CT 片子。
AI 需要什么数据？
- 所有相关的告警内容和历史
- Metrics：CPU、内存、延迟、错误率这些指标的趋势图
- Logs：相关服务的错误日志、异常堆栈
- Traces：分布式调用链，看看请求到底卡在哪了
- Topology：服务依赖关系图，知道 A 挂了会影响谁
Flashduty 做了什么？ 它和市面上几乎所有主流的可观测性产品都做了原生集成。你不需要改你的监控栈，不需要迁数据，接进来就能用。
你在用 Prometheus + Grafana？接。 你在用 Datadog？接。 你在用 ELK？接。 你在用 Jaeger 做链路追踪？接。
它就像一个万能的适配器，把所有你的数据都拉到同一个地方，然后喂给 AI。
这是第一个门槛。90% 的 AI RCA 产品，死在了这一步。 它们只能看告警文本本身，看不到真正的可观测性数据。分析出来的东西，永远浮在表面。
🧱 底座 2：知识库（Knowledge）
如果说可观测性数据是"现在发生了什么"，那知识库就是"过去发生过什么"。
一个有经验的 SRE，看到一个故障，第一反应是：
这个我见过。上个月好像也出过一次类似的。当时是因为 xxx。
AI 也需要这个记忆。
知识库包括什么？
- 历史事故记录和 RCA 报告
- 内部 runbook 和操作手册
- 架构文档和服务依赖关系
- 过去的故障模式和解决方案
- 常见问题 FAQ
Flashduty 做了什么？ 它会自动把你所有的历史事故、所有的 RCA 报告，都变成 AI 可以理解和检索的知识。 遇到新的事故，它会先去找：
之前有没有类似的事故？当时的根因是什么？是怎么解决的？
这一下就把 RCA 的质量拉高了一个档次。它不再是对着几个指标干想。它是站在整个团队过去所有经验的肩膀上，来分析现在的问题。
这才是真正的经验沉淀。 最好的 SRE 踩过的坑，以后所有人都不用再踩一遍了。
🧱 底座 3：记忆层（Memory）
事故不是一瞬间的事情。它是一个发展的过程。
- 09:00 第一个告警出现
- 09:05 错误率开始上升
- 09:08 延迟开始飙升
- 09:10 服务开始雪崩
AI 做 RCA，也不是只看一个时间点的快照。它需要知道整个过程中发生了什么，什么先出现，什么后出现，它们之间有什么关联。
这就是记忆层的作用：记录整个事故的完整发展过程，记录 AI 自己的完整分析过程。
而且这个记忆不是一次性的。这个事故的完整分析，会自动进入知识库，成为下一次类似事故的参考。
🧱 底座 4：诊断运行时（Diagnose Runtime）
最后，也是最核心的一个底座：诊断运行时。
AI 不是拿到数据就直接给答案那么简单。真正的分析过程是一个动态的、多步的、探索性的过程：
"嗯，CPU 确实很高。让我看看是哪个进程导致的。哦，这个进程的 GC 次数异常。让我再看看 GC 日志。哦，最近确实有一个内存泄漏的修复合进来了。让我去查一下 Git 提交记录..."
这个过程，和一个人类 SRE 排查问题的过程一模一样。
这需要 AI 能：
- 自主决定下一步该查什么数据
- 动态调用各种工具来获取更多信息
- 根据新拿到的信息，更新自己的判断
- 多步推理，层层深入，直到找到根因
这就是为什么简单地把告警塞给大模型，出来的 RCA 永远都是泛泛而谈，说不到点子上。因为它没有这个动态诊断的过程。
Flashduty 的诊断运行时，就是专门干这个的。它给了 AI 一整套诊断工具，以及一个结构化的、可追踪的、可观测的诊断过程。
而且最重要的是，整个诊断过程是完全透明的。 你可以看到 AI 先查了什么，再查了什么，看到了什么数据，基于什么做出了什么判断。 不是给你一个黑盒的结论，让你盲信。
最终的价值是什么？
说了这么多技术细节，最终落到实处，这个东西到底能给你带来什么价值？
其实很简单，就两件事：
🎯 价值 1：故障恢复时间大幅缩短
传统流程：
告警来了 → 通知到人 → 人爬起来 → 人开始看各种监控 → 人花 30 分钟搞明白大概是什么问题 → 人开始修复 → 总共 MTTR（平均恢复时间）：1 小时
用 Flashduty 的流程：
告警来了 → 自动聚合成事故 → AI 花 30 秒做完 RCA → 通知人的时候，已经告诉你"很可能是 xxx 原因，建议你先做 yyy" → 人直接上手修复 → 总共 MTTR：15 分钟
故障恢复时间，直接降到原来的四分之一。
这个价值是可以直接换算成钱的。 你的服务每多宕机一分钟，就多一分钟的收入损失，多一分钟的用户抱怨，多一分钟的品牌损害。
🎯 价值 2：服务更稳定，客户少投诉
很多团队的 RCA，都是事故结束之后才写的。 事故发生的时候手忙脚乱，根本顾不上。等到事情过去了，大家开会复盘，才一起回忆当时发生了什么，然后写 RCA 报告。
这个时候的 RCA，其实已经是"事后诸葛亮"了。
而 Flashduty 的 RCA，是事故发生的那一刻就做的。 它不仅帮你更快地恢复，更重要的是，它强迫你在每一次事故之后，都有一个高质量的 RCA，都有明确的改进措施。
每一次事故，都变成了一次真正的学习和改进的机会。 而不是开完会就忘了，三个月之后同样的事故再发生一次。
事故越来越少，服务越来越稳定。 客户投诉越来越少，大家觉也睡得越来越香。
对比一下：PagerDuty vs Flashduty
| 维度 | PagerDuty | Flashduty |
|---|---|---|
| 核心定位 | 告警和事故响应平台 | 智能事故管理和 AI 根因分析平台 |
| 工作流 | 告警 → 通知人 → 人分析 → 人修复 | 告警 → 聚合成事故 → AI 做 RCA → 通知人（带分析结果）→ 人修复 |
| 聚合能力 | 基础的告警去重和降噪 | 智能告警关联和事故聚合 |
| AI 能力 | 有一些基础的 AI 功能 | 原生设计的 AI RCA，四大能力底座完整 |
| 给用户的价值 | 不会漏告警 | 知道为什么出告警，以及该怎么修 |
| 数据集成 | 主要是告警源 | 全栈可观测性数据集成：Metrics、Logs、Traces |
| 知识沉淀 | 靠人自己写 | 自动沉淀所有事故和 RCA 变成团队知识 |
这不是替代关系，是升级关系。 你可以继续用 PagerDuty 做告警通知和排班，然后用 Flashduty 做上层的事故聚合和 AI RCA。它们完美互补。
我的使用体验
我自己实际用了 Flashduty 一段时间，说说我的真实感受。
第一个感觉是：终于不用在 5 个监控系统之间来回切了。 所有的告警都在一个地方，所有的相关数据都在一个面板上，AI 已经帮你把重点都标出来了。
第二个感觉是：RCA 的质量超出预期。 很多时候，我还在看监控数据，AI 已经把根因分析出来了，而且说得八九不离十。 甚至有几次，它指出了我根本没有想到的关联关系。
第三个感觉是：它真的在学习。 用得越久，历史事故积累得越多，它的 RCA 质量就越高，对你们公司系统的理解就越深。
当然，它也不是完美的。
- 特别复杂的、涉及多个系统深层交互的故障，它还是搞不定，还是需要人来。
- 偶尔也会犯错，会误导你。
- 对非常小众的技术栈，支持还不是很好。
但是，对于 80% 的常见故障，它做得已经比一个中级 SRE 还要好了。
而且最重要的是，它永远不会累，永远不会发脾气，永远不会在凌晨三点被叫醒的时候带着起床气排查问题。
SRE 的未来是什么样的？
最后，我想聊得更远一点。
SRE 这个职业，从诞生到现在，本质上一直在做一件事：
把越来越多的、原来需要人来做的事情，自动化。
- 一开始，我们自动化了监控。不用人盯着屏幕了。
- 然后，我们自动化了告警和通知。不用人轮着守着了。
- 然后，我们自动化了扩容。不用人半夜起来加机器了。
- 然后，我们自动化了故障转移。不用人去手动切流量了。
每一次自动化，都把 SRE 从更枯燥、更重复的工作中解放出来，让他们去做更有价值的事情。
现在，轮到 RCA 了。
SRE 工作里最花时间、最重复、也最依赖经验的那部分工作，正在被 AI 自动化。
那 SRE 会失业吗？当然不会。
就像监控自动化了之后，SRE 没有失业。 告警自动化了之后，SRE 也没有失业。
他们只是去做更重要的事情了。 他们去做架构设计，去做容量规划，去做混沌工程，去做整个系统的可靠性保障，去做那些真正需要人类智慧和判断力的事情。
AI 不会取代 SRE。 但是会用 AI 的 SRE，会取代不会用 AI 的 SRE。
而 Flashduty，就是那个能帮你完成这个转变的工具。
行动建议
如果你是 SRE、运维、或者技术负责人，我建议你一定要试试这个方向。
不需要把整个监控栈都换掉。不需要大动干戈。 你可以：
- 先用十分钟，把你现有的告警接入 Flashduty。
- 让它跑一周，看看它聚合适故的效果怎么样。
- 出几次故障之后，看看它的 RCA 分析质量怎么样。
- 如果觉得好，再逐步深入用。
试错成本几乎为零。但如果真的能把你的 MTTR 降下来，那这个价值是巨大的。
写在最后
我在 SRE 这个领域做了很多年。我见过太多的产品，太多的概念，太多的银弹。
大多数的 AI 产品，你用了之后的感觉是："哇，好酷。但是好像也没什么用。"
但是 Flashduty 不一样。 你用了之后的感觉是："哦，原来 RCA 应该是这么做的。"
它不是那种看起来很炫、但是落不了地的东西。 它是那种你用了一个月之后，你就无法想象没有它的时候你是怎么工作的东西。
这就是好工具的标准。
AI 在 SRE 领域的应用，才刚刚开始。 RCA 只是第一个落下来的多米诺骨牌。后面还会有自动诊断、自动修复、自动优化，等等等等。
我们正站在这个变革的起点。 很幸运，能亲眼见证这一切的发生。
参考资源
Flashduty 官方网站 — https://flashduty.com 免费注册，14 天全功能试用
PagerDuty 官网 — https://www.pagerduty.com 传统告警和事故响应平台的行业标杆
SRE Book — Google Site Reliability Engineering SRE 领域的圣经，所有做可靠性的人都应该读一遍
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
