看完 Datadog、Dynatrace、PagerDuty、ServiceNow、BigPanda，再看 AWS，会发现 AI SRE 还有一条非常重要的路线。
Datadog 的重点是：AI SRE 要能自动查生产数据。
Dynatrace 的重点是：AI RCA 要建立在因果图谱上。
PagerDuty 的重点是：AI 要进入事故响应现场。
ServiceNow 的重点是：AI 要进入企业运维流程。
BigPanda 的重点是：AI 要先把告警风暴变成可调查事故。
AWS 的重点是：云厂商不只拥有监控数据，它还掌握资源、变更、调用链、权限和标准修复动作。
这件事对 AI RCA 很关键。
很多产品做根因分析时，默认输入只有 metrics、logs、traces。
但真实事故里，最有价值的问题往往是：
刚才谁改了什么？
哪个资源配置变了？
哪个 Lambda 版本发布了？
哪个 ECS service 更新了 task definition？
哪个 EKS deployment 刚 rollout？
哪个 RDS 参数被改了？
哪个 IAM policy 变了？
哪个 target group health check 调整了？
哪个下游 AWS 服务正在异常？
有没有现成 runbook 可以执行？
这些问题，云厂商天然更容易回答。
这就是 AWS AI Ops 路线最值得研究的地方。
AWS 不是简单做了一个聊天框
AWS 现在的核心能力叫 CloudWatch Investigations。
这个能力在预览期叫 Amazon Q Developer operational investigations，后来 GA 之后进入 CloudWatch。这个命名变化很有意思。
预览期叫 Amazon Q，强调 AI 助手。
GA 后叫 CloudWatch Investigations，强调运维调查。
这说明 AWS 最终没有把它做成一个独立聊天框，而是把 AI 放回 CloudWatch 这个 operational troubleshooting 工作台里。
一次 investigation 可以从很多地方启动：
CloudWatch alarm。
CloudWatch metric。
Lambda 的监控页。
Application Signals 的 SLO。
Amazon Q chat。
AWS Console 里的 Investigate 按钮。
甚至可以配置成 alarm 进入 ALARM state 后自动启动。
这比“用户打开 AI 助手问一句”要成熟得多。
因为真实事故现场里，工程师不是总从聊天框开始。
他可能是被告警叫醒的。
可能是在 SLO 页面看到 burn rate。
可能是在 Lambda 监控页看到 duration 飙升。
可能是在日志查询里看到新错误。
可能是在 Slack 或 Teams 里和别人讨论。
可能只是问 Amazon Q：“为什么这个 alarm 在响？”
成熟的 AI SRE 应该能从这些入口接住问题。
Investigation 比问答更重要
CloudWatch Investigations 最值得借鉴的地方，是它把排障做成了一个 investigation object。
这个对象里可以有：
AI observations。
Suggestions。
Root-cause hypotheses。
相关 metrics。
相关 logs。
CloudTrail change events。
X-Ray traces。
Application Signals data。
Database Insights data。
AWS Health events。
Runbook recommendations。
人工 accept 或 discard 的 findings。
最后生成的 incident report。
这和聊天问答完全不是一回事。
聊天问答经常是一次性的。
问一句，答一句。
答完之后，证据在哪里？
谁确认过？
哪些假设被排除了？
哪些动作执行了？
报告怎么沉淀？
下一次类似事故怎么复用？
如果没有这些，AI 只是一个事故现场的临时文本生成器。
Investigation 对象的意义在于，它把 AI 的推理、证据、人工判断、动作和报告放在同一个工作流里。
这才接近真正的 AI SRE。
AWS 很谨慎地说 hypothesis，而不是 final root cause
我很喜欢 AWS 在文档里的一个措辞：root-cause hypotheses。
它说的是根因假设，不是最终根因。
这点很重要。
生产事故里，AI 最危险的地方不是不知道，而是假装知道。
一个自信但错误的根因，会浪费工程师时间，甚至诱导错误修复动作。
AWS 的设计更像这样：
这里有一个可能根因。
这些指标、日志、trace、变更事件支持它。
这些资源之间可能存在影响路径。
你可以接受这个 finding，也可以丢弃。
你可以继续补充数据。
你可以基于已接受的 hypothesis 生成报告。
你可以执行受控 runbook。
这个边界很成熟。
国内很多 AI RCA 产品太急着给答案：
根因为数据库连接池耗尽。
根因为 CPU 使用率过高。
根因为下游接口超时。
根因为某次发布。
但这些说法里，有些只是症状，有些只是相关，有些只是时间接近。
成熟的产品应该区分：
疑似根因。
证据。
影响。
促成因素。
已排除假设。
人工确认。
最终根因。
整改项。
AI RCA 不需要每次都装成神谕。它需要把调查过程变得更快、更清楚、更可检查。
云厂商最大的优势，是知道“谁改了什么”
AWS 路线最硬的地方，不是大模型。
是 CloudTrail。
CloudTrail 记录 AWS account 里的控制面操作。谁创建了资源，谁改了权限，谁更新了配置，谁调整了服务，什么时候发生。
CloudWatch Investigations 可以把 CloudTrail change events 纳入调查。
Application Signals 也能处理 CloudTrail events，把 deployment 和 configuration changes 放进应用分析上下文。
这件事对 RCA 太重要了。
很多事故最后都和变更有关：
代码发布。
配置修改。
数据库参数。
权限策略。
网络规则。
扩缩容策略。
Kubernetes workload。
负载均衡配置。
消息队列参数。
feature flag。
如果 AI 只看指标和日志，它很容易在症状里打转。
如果 AI 同时知道“异常前发生了哪些变更”，它就有机会从症状走向因果线索。
这也是国内厂商必须补的一课。
AI SRE 不能只接 Prometheus、日志和 trace。还要接：
发布系统。
配置中心。
云审计。
Kubernetes events。
数据库变更。
网络变更。
权限变更。
CMDB 变更。
工单审批。
自动化执行记录。
否则事故现场最关键的问题，还是要靠人在群里问。
Application Signals 让 RCA 从资源走向服务
云厂商做 RCA 还有一个天然问题：云资源很多，但业务服务不是资源本身。
一个服务可能涉及 API Gateway、Lambda、DynamoDB、SQS、Step Functions、RDS、ALB、ECS、EKS。
单看某个资源的指标，不一定知道业务是否受影响。
CloudWatch Application Signals 的价值就在这里。
它把服务、operation、dependency、SLO、SLI、latency、availability、faults、errors、trace 和 topology 放在一起。
工程师关心的不只是“某个 Lambda 是否慢”，而是：
哪个服务不健康？
哪个 operation 出问题？
哪个 dependency 拖慢了它？
哪个 SLO 正在被消耗？
有没有相关 trace？
有没有新部署或配置变更？
上下游影响范围是什么？
这让 AI investigation 不再只是围绕资源指标工作，而是围绕服务健康工作。
国内厂商也应该注意这个转变。
很多监控产品还停留在主机、容器、实例、接口、指标。
但 AI SRE 真正要服务的是应用、业务链路、SLO、团队责任和事故闭环。
没有应用语义层，AI 就很难判断什么重要、谁受影响、该找谁处理。
DevOps Guru 说明：AI Ops 不只是生成式 AI
AWS 早就有 DevOps Guru。
它不是最近这波大模型产品，而是基于机器学习的 cloud operations 服务。它会持续分析 AWS resources 的 operational data，发现异常行为，生成 insights，并给出 recommendations。
DevOps Guru 有两类 insight：
Reactive insight，处理正在发生的问题。
Proactive insight，提前提示未来可能发生的问题。
它会把 metrics、events、log anomalies、CloudTrail events、X-Ray、CloudFormation、AWS Config 等上下文聚合起来。
比如 Lambda 延迟异常，可能和冷启动、请求增加、下游限流、代码发布有关。
比如 DynamoDB consumed capacity 接近限制，可能需要调整 capacity mode 或提前扩容。
比如 RDS PostgreSQL 的 DBLoad 异常，可能需要看高负载 SQL、CPU、session 或 temporary tables。
这提醒我们一件事：
AI Ops 不等于 LLM Ops。
异常检测、模式识别、趋势预测、日志聚类、指标基线、资源领域知识，这些传统 ML / 统计能力仍然很重要。
大模型擅长解释、总结、组织证据、生成报告和驱动工具。
但它不能替代底层的异常检测和资源模型。
Runbook 是 AI 从建议走向动作的桥
CloudWatch Investigations 可以推荐 Systems Manager Automation runbooks。
这点非常实际。
很多 AI SRE demo 喜欢演示“AI 自动修复故障”。
但真实生产环境里，自动修复不是一句话能解决的。
谁有权限？
执行哪个动作？
动作风险多高？
能不能回滚？
要不要审批？
执行结果怎么审计？
失败了怎么办？
是否影响变更窗口？
AWS 把修复动作放在 Systems Manager Automation runbook 里。这比让 AI 直接随便调 API 要稳得多。
这对国内厂商很有启发。
先不要承诺 AI 自动修复一切。
更现实的路线是：
先让 AI 自动收集上下文。
再让 AI 自动跑只读诊断。
再让 AI 推荐 runbook。
再由人确认执行低风险动作。
高风险动作进入审批和变更流程。
执行结果进入审计和复盘。
这样 AI 才能从“会建议”走向“能安全行动”。
AWS 的路线也有明显边界
AWS 很强，但它不是万能 AI SRE。
首先，它主要服务 AWS 生态。
如果客户是多云、混合云、私有云、裸金属、国产云、OpenStack、VMware、Kubernetes 混合环境，AWS 原生能力只能覆盖一部分。
其次，它依赖前置数据质量。
如果没有 Application Signals、X-Ray、CloudTrail、Container Insights、Database Insights，AI investigation 的质量会下降。AWS 文档也明确建议启用这些能力。
第三，它有数据和权限边界。
CloudWatch Investigations 默认只读，增强模式需要 investigation group 和 IAM role。数据保留有期限，动作有 CloudTrail 审计，KMS 可以自管，但 cross-Region inference 和服务改进数据使用也需要客户理解和配置。
这些边界对国内政企客户尤其敏感。
国内 AI SRE 产品如果要进入金融、能源、运营商、政府行业，必须回答：
数据会不会出域？
模型推理在哪里发生？
日志是否脱敏？
prompt 和 response 保存多久？
谁能看 AI 查到的内容？
AI 是否可能越权？
自动化动作是否审批？
是否支持私有化和信创环境？
是否能完整审计？
这些问题不是销售后期才处理的“合规细节”。
它们决定产品能不能进生产。
对国内厂商的启发
如果把 AWS 路线翻译成国内产品判断，我觉得至少有七点。
第一，RCA 必须接入变更和审计。
发布、配置、权限、云 API、数据库、网络、Kubernetes、CMDB、工单审批，都应该成为证据。
第二，AI RCA 应该是 investigation，不是 chat。
要有触发入口、影响时间、证据、假设、人工确认、动作、报告和复盘回流。
第三，SLO 和应用拓扑必须进入 AI SRE。
不要只围绕资源指标分析，要围绕业务服务、operation、dependency 和用户影响分析。
第四，传统 ML 和规则仍然重要。
大模型不是异常检测器的替代品。指标基线、日志模式、变更关联、拓扑推断、历史相似事故，都要做扎实。
第五，runbook 是自动化的标准载体。
AI 推荐动作之前，先把诊断和修复动作产品化、权限化、审计化。
第六，权限和数据治理要从第一天设计。
AI 能看什么、谁能看 AI 输出、动作谁审批、报告保存多久，这些都要产品化。
第七，国内机会在跨云和本地化。
AWS 强在 AWS。国内客户强在复杂。
多云、混合云、私有云、国产 ITSM、CMDB、自研发布系统、飞书、企微、钉钉、蓝信、自动化平台，这些才是国内 AI SRE 的真实战场。
最后的判断
AWS 的 AI Ops 路线提醒我们一件事：
AI RCA 的核心不是让模型读日志，然后写一段像专家的话。
真正有价值的问题是：
资源是什么？
谁依赖谁？
哪个服务受影响？
哪个 SLO 正在失败？
异常之前发生了什么变更？
谁做的变更？
有没有相关 trace？
有没有类似历史？
哪个 runbook 可以执行？
执行动作需要谁批准？
结果如何写进复盘？
云厂商的优势，是这些问题中的很多答案本来就在云平台里。
国内厂商的机会，是把这些答案从更多系统里连接起来。
监控、日志、APM、云审计、CMDB、发布、工单、IM、自动化、知识库、复盘，都要进入同一个 investigation。
只有这样，AI SRE 才不是一个漂亮的聊天框。
它才会变成真正能减少人工排障、缩短 MTTR、沉淀组织经验的生产工具。
AWS 的启发很直接：AI Ops 的硬底座不是大模型，而是云资源、变更审计、服务拓扑和受控自动化。
SRE 工作模式巨变。我们创业做的就是监控、可观测性、AI RCA 相关的产品，欢迎与我们联络交流这条 cloud-native AI operations 路线。
参考资料：AWS 官方 CloudWatch Investigations、Amazon Q Developer operational investigations、CloudWatch Application Signals、CloudWatch AI Operations、Amazon DevOps Guru、Systems Manager Automation、CloudTrail、X-Ray、Database Insights 等文档与产品页。完整资料整理见同目录调研稿 2026-05-12-aws-cloudwatch-amazon-q-ai-sre-rca-research.md。
