看完 Datadog、Dynatrace、PagerDuty，再看 ServiceNow，会发现 AI RCA 还有一条非常重要的路线。
Datadog 关心的是：AI SRE 怎么自动查生产数据。
Dynatrace 关心的是：AI RCA 怎么建立在因果图谱上。
PagerDuty 关心的是：AI 怎么进入事故响应现场。
ServiceNow 关心的是：AI 怎么进入企业运维流程。
这四件事不一样。
ServiceNow 最值得看的，不是它也做了 Now Assist，也不是它也有 AI agents，而是它把 AI 放在了 incident、problem、change、CMDB、service mapping、workflow、approval、knowledge、runbook、audit 这些企业运维对象中间。
它的提醒很直接：
AI SRE 如果只会查指标、日志、链路，最后很容易停在“建议层”。真正要改变企业运维，AI 必须能进入流程。
生产事故不是一道单纯的数据分析题
很多 AI RCA 产品喜欢把问题讲得很简单。
指标异常了。
日志报错了。
链路超时了。
然后 AI 总结：疑似数据库连接池耗尽，建议扩容或重启。
这当然有价值。
但在真实企业运维里，这只是很小的一段。
一个事故来了，现场要回答的问题远不止“哪个指标异常”：
这个告警属于哪个业务系统？
对应哪个 CI？
影响哪个业务服务？
谁负责？
现在谁值班？
最近有没有变更？
有没有相关 incident？
历史有没有类似问题？
上次怎么处理？
要不要创建工单？
要不要升级？
要不要通知业务方？
回滚需不需要审批？
修复脚本谁能执行？
执行完怎么留痕？
事后怎么复盘？
问题怎么进入 problem 管理？
如果 AI 只在监控页面里给一段根因总结，它回答不了这些问题。
ServiceNow 的路线就是从这里切进去的。
它不是一个单纯的监控工具，而是企业运维的 system of action。它本来就掌握 incident、problem、change、request、CMDB、CSDM、approval、SLA、knowledge、workflow、automation、audit trail。
所以它做 AI RCA 的起点，不是“让模型看懂一段日志”，而是“让 AI 在企业运维流程里参与工作”。
Event Management 先把告警变成可治理对象
ServiceNow 的第一层能力是 Event Management。
它把来自外部监控、日志、云、网络、Agent Client Collector、REST、Splunk、CloudWatch 等来源的 events 接进来，然后变成 ServiceNow 里的 alerts。
这个过程里，它会做很多看起来不性感但很关键的事：
标准化字段。
映射 severity。
绑定 CI。
执行 event rules。
判断 maintenance。
识别 flapping。
计算 priority。
关联和分组。
计算服务影响。
创建 incident。
触发 remediation。
这些事情其实是 AI RCA 的地基。
很多国内监控系统的问题，不是没有大模型，而是告警对象本身太脏。
服务名不统一。
环境字段不统一。
severity 没有一致含义。
告警没有 owner。
没有业务影响。
没有 CI。
没有变更 ID。
没有 runbook。
没有历史处理记录。
告警关闭也不代表事故闭环。
在这种基础上做 AI RCA，模型只能猜。
ServiceNow 的提醒是：不要急着让 AI 输出根因。先让事件成为一个结构化、可治理、可流转的运维对象。
告警分组比“每条告警写总结”重要
ServiceNow Event Management 支持很多种 alert grouping。
有 rule-based grouping，让管理员定义 primary alert 和 secondary alerts。
有 CMDB-based grouping，根据 CI 关系把告警组织起来。
有 network traffic grouping，通过 ML Service Mapping 和进程间网络连接发现相关告警。
有 text grouping，根据描述、metric name、CI class 等文本相似性聚合。
有 tag cluster grouping，适配云资源和自定义标签。
有 Log Analytics grouping，把相关日志异常组织起来。
也有 manual grouping，让人工经验进入系统。
这背后是一个成熟判断：
企业运维里的“相关性”不是一种。
有些相关来自拓扑。
有些相关来自 CMDB。
有些相关来自网络流量。
有些相关来自标签。
有些相关来自文本。
有些相关来自历史模式。
有些相关来自工程师经验。
如果一个 AI RCA 产品只围绕单条告警写总结，很容易制造新的噪音。
真实事故往往同时触发 CPU high、latency high、error rate high、pod restart、database connection high、synthetic check failed、queue lag、SLO violation。
如果 AI 给每条告警都写一个“疑似根因”，你会得到一堆互相打架的结论。
更好的做法是先把 alerts 变成 alert group、incident、problem candidate，再让 AI 工作。
这点和 PagerDuty 的启发类似，但 ServiceNow 更进一步：它会把 alert group 和 CMDB、change、incident、problem、service impact、knowledge、automation 连起来。
CMDB 是优势，也是风险
ServiceNow 做 AI RCA 最大的优势之一是 CMDB / CSDM / Service Graph / Service Mapping。
如果这些数据是准的，AI 会很强。
它知道这个告警属于哪个 CI。
知道 CI 属于哪个应用服务。
知道应用服务支撑哪个业务服务。
知道上下游依赖。
知道 owner 和 assignment group。
知道相关 incident、problem、change。
知道服务健康和业务影响。
这时 AI RCA 就不只是“看哪个指标异常”，而是能把技术事实放进企业上下文里。
但这也是 ServiceNow 路线最大的风险。
CMDB 不准，AI 就会很快地产生错误判断。
服务关系不准，影响面就会误判。
owner 不准，分派就会错。
变更记录不准，根因候选就会偏。
知识库过期，建议动作就会误导。
所以 ServiceNow 的路线不适合被简单理解成“买一个 AI 功能就能自动 RCA”。
它更像是说：如果你愿意把 CMDB、CSDM、Service Mapping、ITSM、ITOM、workflow 治理好，那么 AI 可以在这个体系里发挥很大价值。
这对国内厂商尤其重要。
国内很多客户也有 CMDB、应用树、业务系统台账、云管平台、自研配置中心、发布系统、工单系统。问题是这些数据经常互相割裂、命名不统一、关系不可靠。
AI SRE 的基础工程，不只是模型和 prompt，而是 entity resolution、服务目录、依赖关系、owner、变更、工单、知识库的治理。
Service Observability 说明它不想替代所有监控工具
ServiceNow 也在做 Service Observability。
但它的思路不是彻底替代 Datadog、Dynatrace、New Relic、Prometheus、Splunk Observability。
它更像是把这些工具里的观测数据映射到 ServiceNow 的服务和 CI 上。
管理员先确定要监控的服务。
连接已有 observability vendor。
用 tag 把外部指标映射到 ServiceNow 的 service CI。
操作员在 Service Operations Workspace 里看服务健康、相关 alerts、incidents、changes。
需要更深证据时，再进入 Observability tab 看外部指标和相关实体。
Now Assist 可以分析 dashboard 和 service health。
这个设计很现实。
大型企业通常已经有很多监控工具。你很难让客户一夜之间把所有 telemetry 迁到一个新平台。
ServiceNow 的答案是：我不一定拿走所有数据，但我要成为这些数据进入企业处理流程的地方。
这对国内 AI SRE 产品也很有参考价值。
并不是每个厂商都必须做全量可观测性平台。另一条路线是做流程层、上下文层、自动化层，把已有监控、日志、APM、云管、CMDB、ITSM、发布、IM、审批系统连接起来。
Now Assist 不只是聊天框，而是嵌在工作台里
Now Assist for ITOM 的基础能力，是给 alert、incident、alert group 做生成式 AI 分析。
它可以生成 human-readable alert brief。
可以提供技术分析信息。
可以分析 alert group。
可以把 AI summary 保存成 alert group description。
可以基于 alert 创建带 AI 描述的 incident。
可以总结 past related incidents。
可以分析 Service Observability dashboard。
可以分析 service health。
可以分析 Agent Client Collector 错误。
这些能力本身并不神秘。
真正值得看的是它出现的位置。
它出现在 Service Operations Workspace。
出现在 Express List。
出现在 alert record。
出现在 alert group。
出现在 incident 创建。
出现在 service dashboard。
出现在 Now Assist panel。
这说明 ServiceNow 很清楚：企业用户不会为了 AI 改变所有工作习惯。
AI 要在原来的工作流里出现。
操作员正在看 alert，AI 就解释 alert。
操作员正在看 alert group，AI 就解释 group。
操作员要创建 incident，AI 就帮他写描述。
操作员要查历史事故，AI 就总结 past incidents。
操作员要看服务健康，AI 就分析 dashboard。
这比做一个孤立的“问 AI 根因是什么”按钮更实际。
AI agents 的价值在于受控执行
ServiceNow 已经不满足于 Now Assist summary。
它在 ITOM 里引入 AI agents 和 agentic workflows。
AI agents for AIOps 的目标，是帮助 IT operations 自主分诊告警、评估业务和技术影响、调查根因、推荐或执行修复步骤。
AI agents for Observability 的目标，是评估 business / application service impact，形成 probable cause theories，并与第三方 APM 和 observability vendor 的 AI agents 协作。
Analyze alert impact workflow 里，ServiceNow 会调用不同 agent：
Alert impact summary agent。
Alert information retrieval agent。
Dynatrace analysis agent。
Kentik analysis agent。
New Relic analysis agent。
这个方向很有意思。
ServiceNow 承认自己不拥有所有底层证据。Dynatrace、New Relic、Kentik 这些工具各自有自己的深度数据和分析能力。
ServiceNow 要做的是把这些 agent 的洞察带回 ServiceNow 的工作流里。
事故可能在 ServiceNow 里流转。
服务和工单在 ServiceNow 里管理。
审批和自动化在 ServiceNow 里执行。
但证据可能来自 Dynatrace、New Relic、Datadog、Prometheus、Splunk、云厂商、网络工具。
未来 AI SRE 很可能就是这种跨系统协作。
没有任何一个系统能独占全部上下文。
LEAP 把历史事故变成 playbook
ServiceNow 还有一个值得看的方向，叫 LEAP。
它的重点不是再生成一段“根因分析”，而是从历史 incident 里挖掘自动化机会，生成 resolution playbooks，甚至生成知识库文章和命令片段。
这件事非常实用。
很多企业真正的排障知识不在指标里。
它在历史工单里。
在复盘里。
在知识库里。
在值班记录里。
在专家写过的脚本里。
在一次次重复 incident 的处理过程里。
如果 AI 能把这些经验重新拉回现场，并进一步变成 playbook，价值会很大。
国内很多公司做 AI RCA 时，太迷恋“实时根因判断”。但很多问题其实不是没人见过，而是见过的人不在现场，文档没人查，脚本没人敢跑，处理步骤没有产品化。
AI SRE 很重要的一件事，是把组织记忆变成可执行资产。
变更是 AI RCA 不能绕开的硬证据
ServiceNow 的另一个优势是 change。
很多生产事故都和变更有关。
应用发布。
配置调整。
数据库变更。
网络策略变更。
云资源变更。
证书更新。
权限调整。
feature flag。
扩缩容。
可观测性厂商现在也都在补 change tracking。
但 ServiceNow 不一样。Change 本来就是它的核心流程对象。
它能看到 change request、approval、affected CI、planned window、implementation plan、rollback plan、related incident、CAB、policy、audit trail。
这让它在 AI RCA 里天然能问：
这次事故前有哪些变更？
这些变更影响哪些 CI？
是否覆盖当前受影响服务？
是否有失败变更任务？
是否需要回滚？
回滚是否需要审批？
是否要自动创建 problem 或 follow-up change？
这对国内厂商是一个非常明确的提醒：
AI RCA 必须把发布和变更接进来。
只看监控数据，很容易把症状当根因。
治理是 ServiceNow 的核心卖点
ServiceNow 2026 年的 AI 叙事已经从 Now Assist 走到 Autonomous Workforce、AI Specialists、AI Control Tower、Action Fabric。
这些词听起来很营销，但背后有一个真实企业需求：
AI 不能裸奔。
ServiceNow 强调 role-scoped permissions、ACL、domain separation、audit trail、AI Control Tower、policy、kill switch、cost tracking、agent observability。
这对 AI SRE 尤其重要。
一个能执行修复动作的 agent，权限必须受控。
一个能读取日志和工单的 agent，数据范围必须受控。
一个能发起变更的 agent，审批必须受控。
一个能关闭告警的 agent，操作必须留痕。
一个能调用外部工具的 agent，成本和失败率必须可观测。
国内政企客户更是如此。
他们不会接受一个“模型觉得可以，所以自动重启了数据库”的系统。
更现实的路径是分阶段：
先 read-only 分析。
再生成建议。
再生成诊断步骤。
再由人确认执行。
再执行低风险自动化。
再进入审批和审计。
最后才谈高自治。
ServiceNow 的启发不是“马上做全自动运维”，而是“自动化必须运行在治理边界里”。
对国内厂商的启发
如果把 ServiceNow 的路线翻译成国内产品建设，我觉得至少有八点。
第一，AI RCA 要进入工单和流程。
不要只在监控平台里做一个 AI 总结。要打通告警、事故、工单、问题、变更、审批、知识库、值班和自动化。
第二，事件语义要先治理。
service、env、cluster、CI、owner、severity、business impact、change id、runbook、maintenance 这些字段要结构化。
第三，先构造事故对象，再做 AI。
围绕 alert group、incident、problem candidate 做分析，不要围绕每条告警生成一段 RCA。
第四，CMDB 和应用树要变成 AI 底座。
国内客户的 CMDB、应用树、业务系统台账、资源池、云管平台、自研配置中心都要进入实体和关系层。
第五，变更必须是一等公民。
发布、配置、数据库、网络、权限、证书、云资源、feature flag 都要进入根因候选和证据链。
第六，历史事故要活起来。
复盘、工单、群聊、知识库、脚本、修复记录，应该在下一次事故中自动召回，并转化为 playbook。
第七，自动化必须可控。
支持 read-only、人工确认、审批、命令白名单、回滚、审计、权限隔离，而不是一上来就宣传 self-healing。
第八，生态入口要本地化。
ServiceNow 接 Slack、Teams、Jira、Confluence、ServiceNow、AWS、Azure、Google Cloud。国内要接飞书、企微、钉钉、蓝信、国产 ITSM、自研流程系统、国产 CMDB、云管平台、堡垒机、发布系统和审计系统。
最后的判断
ServiceNow 的路线不适合所有厂商照搬。
它太重。
它依赖 CMDB。
它依赖流程治理。
它交付复杂。
它的 SaaS 和授权模型也不一定适合国内私有化客户。
但它给 AI SRE 的提醒非常重要：
生产事故不是只有技术证据。
它还有组织、流程、权限、审批、历史、责任、沟通和审计。
Datadog 告诉我们，AI SRE 要会查生产数据。
Dynatrace 告诉我们，AI RCA 要有因果图谱。
PagerDuty 告诉我们，AI RCA 要把告警变成可处理事故。
ServiceNow 告诉我们，AI SRE 最终要进入企业运维流程。
很多时候，企业客户缺的不是一个更会聊天的 AI。
他们缺的是一个能把告警、服务、CMDB、变更、工单、知识库、审批和自动化真正串起来的系统。
AI RCA 的终点不是写出根因，而是让企业能更快、更稳、更可控地完成事故处理。
参考资料：ServiceNow 官方 ITOM、Event Management、Now Assist for ITOM、Service Operations Workspace、Service Observability、AI product tiers、AI Control Tower、Action Fabric、Autonomous Workforce 等文档与新闻稿。
编者：秦晓辉，ToB 软件创业者，长期关注监控、可观测性、RCA、SRE 方向。曾主导 Open-Falcon、Nightingale 等开源项目建设。极客时间专栏《运维监控系统实战笔记》作者，公众号 SRETALK 主理人。
觉得有用？望不吝转发点赞 :)
