很多 SRE 团队都有一个很微妙的变化。
过去大家最焦虑的是“没有监控”。
机器有没有指标？
服务有没有大盘？
接口有没有成功率？
日志能不能查？
链路有没有 Trace？
告警能不能发到群里？
这些问题在很多公司已经基本解决了。
Prometheus 有了，Grafana 有了，日志平台有了，APM 有了，云监控有了，Zabbix 可能也还在，告警也能通过飞书、钉钉、企业微信、短信、电话触达到人。
看起来，SRE 应该比以前轻松。
但真实情况往往相反。
告警更多了。
大盘更多了。
系统更多了。
链路更长了。
排障时要打开的页面也更多了。
值班的人还是会在半夜被叫醒。故障发生时，大家还是会在群里问：谁负责这个服务？最近有没有发布？先看日志还是看 Trace？这个告警是真故障还是派生告警？有没有人接？
这就是今天很多 SRE 团队真正的困境。
问题已经不再是“有没有监控”，而是“监控信号能不能变成有效行动”。
监控越多，SRE 未必越轻松
这几年，可观测性建设的方向很清晰：采集更多数据，接入更多系统，覆盖更多维度。
这件事当然有价值。
没有指标，你不知道系统是不是慢了。没有日志，你不知道错误发生在哪里。没有 Trace，你看不到一次请求经过了哪些服务。没有告警，你可能只能等用户投诉。
但问题在于，数据增加之后，人的负担不一定下降。
很多团队建设可观测性之后，会进入一个新的阶段：数据不缺了，判断更难了。
一个接口成功率下降，可能同时伴随几十条告警：
接口错误率升高。
P99 延迟升高。
某个服务实例 CPU 升高。
Redis 超时增加。
MySQL 慢查询增加。
Kubernetes Pod 重启。
网关 5xx 增加。
下游依赖连接池耗尽。
每条告警都不是假的。
但它们也不一定都是独立故障。
如果这些信号没有被组织起来，值班人看到的不是“一个需要处理的故障”，而是一堆同时扑过来的碎片。
这就是告警疲劳的根本原因。
不是通知渠道太吵，而是系统没有把信号压缩成可理解、可判断、可分派的故障对象。
Grafana Labs 2025 年的观测性调研里，alert fatigue 依然是影响事故响应速度的核心障碍之一。Splunk/Cisco 的 2025 年观测性报告也提到，很多 ITOps 和工程团队同时受困于工具过多和误报过多。Catchpoint 的 SRE 报告则显示，toil 没有因为 AI 热潮自动消失，反而在一些团队里继续上升。
这些报告说的是同一件事：工具越来越多，但人的操作负担没有同步下降。
SRE 的累，通常来自三类负担
我不太喜欢把 SRE 的压力简单归因为“系统复杂”。
系统复杂当然是事实，但这个说法太大，落不到行动上。
更具体地看，SRE 今天的疲劳通常来自三类负担。
第一类，是告警噪声负担。
同一个问题触发多条告警，派生问题触发更多告警，恢复和触发来回抖动，维护窗口里仍然不断通知。一个服务抖一下，群里几十条消息。一个机房网络异常，几百台机器各自发告警。
这些告警看起来都在“提醒风险”，但在事故现场，它们会消耗人的注意力。
注意力是 On-call 最稀缺的资源。
半夜三点，一个人被叫醒之后，最需要的不是更多消息，而是一个明确判断：这是不是需要我处理的故障？影响面有多大？我应该先看哪里？
第二类，是上下文拼接负担。
很多团队有完整的指标、日志、链路和事件系统，但这些系统之间没有形成排障路径。
告警里只有指标名。值班人要打开大盘看曲线，再去日志平台复制服务名，再去 APM 里查 Trace，再去发布平台看变更，再去 CMDB 或服务目录里找负责人。
每一步都不难，但每一步都要靠人记住。
这类工作很消耗经验。
老同学知道某个 label 代表哪个服务，知道某个仪表盘在哪里，知道某个错误日志应该搜哪个字段。新同学可能只看到一堆不熟悉的页面。
监控数据在那里，但理解数据的知识藏在人脑里。
第三类，是组织协调负担。
故障响应从来不只是技术问题。
谁接手？谁判断影响？谁联系研发？谁通知业务？谁同步客户？谁决定回滚？谁记录时间线？谁复盘行动项？
如果这些事情没有流程支撑，就会全部落到群聊里。
群聊很适合沟通，但不适合管理事故生命周期。
消息刷得很快，关键信息被淹没，责任人不清楚，状态没人更新，处理动作没有结构化记录，事故结束后复盘还要重新翻聊天记录。
结果就是，故障恢复了，但组织没有真正学习。
下一次类似故障，还是靠同一批人、同一套经验、同样的疲惫感。
真正的问题，是从信号到行动的链路断了
我们可以把一次故障响应拆成五个环节。
第一，发现异常。
系统要能尽早发现业务指标、服务指标、资源指标或用户体验异常。
第二，理解异常。
值班人要知道这是不是故障，影响哪个业务，涉及哪些服务，是否和最近变更有关。
第三，触达正确的人。
不是把消息扔到一个大群里，而是根据服务、团队、严重级别和值班表，通知到真正应该处理的人。如果没人响应，要自动升级。
第四，协同处理。
故障期间要有明确负责人、状态、时间线、处理动作、沟通渠道和外部同步方式。
第五，复盘改进。
事故结束后，要沉淀根因、证据、时间线、改进项、责任人和截止日期，并反哺告警规则、runbook、知识库和平台能力。
很多团队不是某一个环节完全没有，而是环节之间断开了。
监控系统负责发现异常。
日志系统负责查证据。
APM 负责看链路。
发布平台负责记录变更。
IM 负责沟通。
工单系统负责记录事项。
文档系统负责放 runbook。
复盘模板负责事后总结。
每个系统都能解释自己的价值。
但事故发生时，SRE 需要的是一条连贯链路，而不是一堆孤立工具。
如果异常信号不能变成故障对象，告警就会变成噪声。
如果故障对象不能带上上下文，排障就会变成人肉拼图。
如果上下文不能进入响应流程，协同就会变成群聊混战。
如果响应过程不能沉淀为知识，复盘就会变成文档归档。
这就是为什么很多团队“监控越来越完善”，但 SRE 仍然越来越累。
第一件事：把告警变成故障对象
告警治理最容易走偏。
很多团队一听到告警太多，就开始删规则、调阈值、降低通知级别。
这当然能减少通知量，但也可能带来漏报。
更好的做法，是先把对象分清楚。
原始监控系统发出来的是事件。比如一次触发、一次恢复、一次状态变化。
多个相关事件可以组成一条告警。比如同一个实例、同一个检查项，在一段时间里的触发和恢复。
多条相似或相关告警，应该被压缩成一个故障。这个故障才是人真正要处理的对象。
也就是说，响应系统里不应该只有“告警列表”，还应该有“故障对象”。
故障对象要回答几个问题：
这是什么问题？
影响哪个服务或业务？
严重级别是什么？
合并了哪些告警？
当前谁负责？
是否已认领？
是否需要升级？
是否需要开战情室？
处理进展是什么？
当团队从“处理每一条告警”转向“处理每一个故障对象”，告警疲劳才有可能真正下降。
这也是 Flashduty 这类告警响应平台的核心价值所在。
它不应该被理解成“把告警发到手机上”的工具，而是一个把多源告警统一接入、降噪、分派、升级、协同和复盘的响应系统。
Prometheus、Zabbix、Nightingale、Grafana、云监控都可以继续存在。关键是不要让它们各自把告警直接打到人身上，而是先进入统一响应层。
先接住，再降噪，再分派，再闭环。
第二件事：把观测数据变成排障上下文
告警变成故障对象之后，还不够。
故障对象必须带上下文。
否则值班人只是从“看一堆告警”变成“点开一个故障，再去一堆系统里找证据”。
可观测性平台真正应该做的，是把排障上下文提前组织好。
这里至少有三类上下文。
第一，时间上下文。
异常从什么时候开始？持续多久？和哪些发布、配置变更、扩容、运营活动、依赖异常发生在同一时间？
第二，资源上下文。
这个异常属于哪个业务、哪个接口、哪个服务、哪个组件、哪个实例、哪个集群、哪个机房？上下游关系是什么？
第三，请求上下文。
某次慢请求对应哪些日志？有没有 TraceID？经过哪些服务？在哪个调用阶段耗时异常？错误集中在哪类用户、区域或版本？
如果这些上下文没有被产品组织起来，就只能靠人现场拼。
这正是 Flashcat 这类全栈观测平台要解决的问题。
Flashcat 的重点不只是把指标、日志、链路、事件接进来，而是通过北极星、灭火图、事件墙、下钻规则和 FlashAI，把数据组织成排障路径。
北极星回答业务是否异常。
灭火图回答哪个观测对象异常。
事件墙回答异常前后发生了什么。
下钻规则把指标、日志、Trace、仪表盘和外部系统连接起来。
FlashAI 在这些上下文之上辅助分析。
这样，事故现场就不再是从零开始搜索，而是沿着系统已经沉淀好的路径排查。
第三件事：让 AI 进入正确的位置
现在很多人谈 AI SRE。
这件事有价值，但也很容易被讲空。
如果 AI 只是一个聊天框，问它“为什么服务慢了”，它大概率只能给出通用建议：检查 CPU、内存、数据库、网络、依赖服务、最近发布。
这些建议不算错，但对事故现场帮助有限。
真正有用的 AI SRE，至少要具备四个条件。
第一，它要带着事故上下文进入现场。
它要知道当前故障是什么，告警内容是什么，影响哪个服务，当前处理人是谁，战情室里讨论了什么。
第二，它要能调用工具。
只靠语言模型本身不能排障。它需要查询指标、检索日志、分析 Trace、读取事件、调用内部工具，必要时执行受控命令。
第三，它要有长期知识。
服务目录、架构说明、runbook、历史故障、负责人、常见处理动作，都应该成为 AI 可使用的知识。
第四，它的过程要可审计。
AI 查了什么、基于什么证据得出结论、哪些是确定事实、哪些只是推测，都应该可见。
这也是为什么 AI SRE 不应该被理解成“替代 SRE 的机器人”。
更准确的定位是：带工具的调查员。
它帮助人更快收集证据、更快压缩上下文、更快生成初步判断，但最终的根因确认、修复授权和改进承诺，仍然应该由人负责。
Flashduty 的 AI SRE 更适合从故障响应现场切入，比如从事故、战情室或 IM 群里直接唤起，让 AI 带着当前故障上下文开始调查。
Flashcat 的 FlashAI 更适合从观测上下文切入，比如围绕灭火图、北极星、事件墙、指标、日志和链路，分析异常对象和可能根因。
两者结合起来，AI 才不会停留在“会聊天”，而是进入真实故障流程。
第四件事：把复盘变成系统改进，而不是写报告
很多团队事故结束后，会补一份复盘报告。
这当然比不复盘好。
但如果复盘只是为了归档，那它对下一次故障帮助有限。
真正有价值的复盘，应该反向改造系统。
这次事故有没有漏报？
有没有误报和派生告警？
告警是否触达了正确的人？
MTTA 为什么这么长？
MTTR 卡在哪个阶段？
排障时缺了哪些上下文？
是否缺 runbook？
是否缺负责人信息？
是否需要新增下钻路径？
是否要把某类变更事件接入事件墙？
是否要把某个故障案例沉淀到知识库？
如果复盘能回答这些问题，它就不只是文档，而是下一轮稳定性建设的输入。
AI 在这里也很适合发挥作用。
它可以整理时间线、归纳战情室讨论、提取告警上下文、生成复盘初稿、整理行动项。
但它不能替团队承担责任。
根因是否成立，影响范围是否准确，改进项是否有 owner 和截止日期，这些仍然需要人确认。
SRE 的未来，不是少看一个工具，而是少做无效拼接
SRE 不会因为工具更多而自动轻松。
也不会因为接入 AI 而自动轻松。
真正能减轻负担的，是把原来靠人脑临时完成的工作，沉淀到系统里：
把告警压缩成故障对象。
把数据组织成排障上下文。
把响应流程变成可度量链路。
把事故过程沉淀成知识。
把 AI 放在有上下文、有工具、有审计的位置。
这才是从“监控建设”走向“稳定性工程”的关键变化。
过去，我们花了很多时间解决“有没有数据”。
接下来，更重要的问题是：
信号来了以后，系统能不能帮人更快判断？
判断之后，能不能触达正确的人？
处理过程中，能不能把上下文和协同组织起来？
事故结束后，能不能把经验沉淀回系统？
如果这些问题没有解决，监控越多，SRE 只会越累。
如果这些问题被系统性解决，监控和 AI 才会真正变成生产力。
对已经有 Prometheus、Zabbix、Grafana、日志平台、APM 和云监控的团队来说，下一步不一定是再买一个监控工具。
更现实的路径是：
用 Flashcat 把观测数据组织成业务健康视图、故障排查路径和 AI 可理解的上下文。
用 Flashduty 把多源告警变成可分派、可升级、可协同、可复盘的故障响应闭环。
先选一个核心系统，接入一条真实告警链路，复盘最近一次真实故障。
你很快就能看出来，团队累在什么地方。
也能看出来，哪些工作应该继续靠人判断，哪些工作早就应该交给系统完成。
参考资料：
- Grafana Labs Observability Survey 2025：https://grafana.com/observability-survey/2025/
- Splunk / Cisco State of Observability 2025：https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2025/m10/splunk-report-shows-observability-is-a-business-catalyst-for-ai-adoption-customer-experience-and-product-innovation.html
- Catchpoint The SRE Report 2025：https://www.catchpoint.com/press-releases/the-sre-report-2025-highlighting-critical-trends-in-site-reliability-engineering
