Google Cloud 的 AI RCA 路线：别急着猜根因，先把假设做扎实

Google Cloud Gemini Cloud Assist AI RCA 调查流程

看完 Google Cloud Gemini Cloud Assist investigations，最值得关注的不是“Gemini 会不会直接告诉你根因”，而是 Google 对 AI RCA 的产品克制：先把事实、资源、时间线和假设组织清楚，再谈根因判断。

这和很多 AI 排障产品的叙事不太一样。现在不少产品喜欢一上来就输出一个看似明确的结论，比如“根因可能是数据库连接池耗尽”“可能是最近发布导致”“可能是下游服务超时”。这些话听起来都合理，但一线工程师真正关心的是：你凭什么这么说？证据在哪里？相关资源有哪些？哪些步骤可以验证或推翻这个判断？如果解决不了，怎么把上下文交给更专业的人？

Gemini Cloud Assist investigations 给出的答案，是把 RCA 做成一个调查对象，而不是一个聊天结果。它围绕 issue description、start time、resources、observations、hypotheses、recommended fixes 和 support handoff 组织流程。这个方向对国内可观测性和 AIOps 产品很有参考价值：AI RCA 不应该从“根因答案”开始，而应该从“可验证假设”开始。

Google 没有把 RCA 包装成最终答案

Google Cloud 官方文档把 Gemini Cloud Assist investigations 定义为用于基础设施和应用排障的 RCA 工具，但它的核心语言很谨慎。它会产生 Observations，也就是和问题最相关的环境状态洞察；然后基于这些 observations 形成 probable root causes。当存在不确定性时，多个 root cause 会以 hypotheses 的形式出现。

这两个词很关键。Observations 是事实和信号，Hypotheses 是基于证据的根因假设。Google 没有让 AI 一上来“宣判”，而是先收集证据，再提出假设，并且在 observations 里提供 source data links，方便用户继续查看原始数据、做 fact check。这个设计比一句自信的根因结论更接近生产排障，因为真实事故里，错误的自信比承认不确定更危险。

对 AI RCA 来说，证据链比文案重要。一个好看的自然语言总结，如果不能追溯到日志、指标、配置、资源、事件和时间窗口，本质上仍然只是猜测。Google 这套设计提醒产品团队：先让 AI 说清楚“我看到了什么、这些证据来自哪里、我为什么形成这个假设”，再让它说“建议你怎么处理”。

Observations 到 Hypotheses 的调查链路

Investigation 比聊天更适合事故现场

Gemini Cloud Assist investigations 可以从 Logs Explorer、Cloud Monitoring alerts、Gemini Cloud Assist chat、Cloud Hub 的 Health & troubleshooting 页面、GKE workload、Dataproc failed batch、Cloud Composer failed Airflow task、Google Cloud mobile app 和 API 等入口启动。这个设计说明 Google 理解事故现场：工程师不一定从聊天框开始排障，他可能先看到一条 warning 级别以上的日志，可能先收到一个告警，也可能先进入某个 GKE workload 页面。

一个成熟的 AI SRE 不应该要求用户先把事故复制粘贴到聊天框。它应该出现在事故已经发生的地方，并继承当前页面、资源、时间和告警上下文。自然语言可以是入口，但不能成为唯一入口。

更重要的是，investigation 是一个可管理对象。它不是一轮问答，而是可以保存、修订和重跑的调查过程。用户可以修改输入，补充资源或时间，再通过 revision 查看不同轮次的结果。这个细节非常贴近真实排障：第一轮你可能只知道服务报错，第二轮知道从 10:32 开始，第三轮发现只影响某个 region，第四轮补充了发布变更，第五轮才定位到下游数据库或配额问题。如果 AI 只能回答第一轮问题，它很快会失去价值；真正有用的 AI RCA，必须能跟着事故上下文一起演进。

Start time 和 App Hub 是两个关键约束

Google 文档专门强调时间戳对 investigation 的重要性。这个看起来像小事，其实非常关键。RCA 不是在所有数据里找一个看起来异常的点，而是在正确时间窗口里判断哪些信号先发生、哪些信号后发生、哪些是原因、哪些是症状。时间窗口错了，AI 很容易把无关事件串起来：CPU 峰值、错误日志、配置变更、Cloud SQL 抖动、GKE Pod 重启、Pub/Sub backlog、Google Cloud service incident，都可能变成“看起来有关”的噪音。

国内做 AI RCA 时，也应该把 start time 做成一等参数。不要只让用户问“为什么服务挂了”，而要让用户确认什么时候开始、影响多久、哪个资源先异常、哪个告警先触发、哪个变更发生在前面。AI 排障的准确性，很多时候不是模型决定的，而是时间线决定的。

另一个值得关注的是 App Hub。云资源天然按 project、folder、resource、region、zone 组织，但业务系统不是这么理解的。一个应用可能跨多个 project，一个 project 里可能有多个业务系统，一个服务可能由 Cloud Run、Cloud SQL、Pub/Sub、BigQuery、GKE workload、Cloud Storage 共同组成。事故影响的是业务功能，不是单个云资源。

App Hub 的价值，是把 scattered resources 组织成 application、service、workload，并补充 owner、criticality、environment、dependencies、business context。Gemini Cloud Assist investigations 可以限定在单个 App Hub application 内，这意味着 AI 不只是看资源，而是开始有应用边界。没有应用边界，AI 很容易在一个 project 里查到一堆无关资源；没有 owner 和 criticality，AI 即使找到问题，也很难进入响应流程。

Start time 与 App Hub 让调查收敛

Google 的边界写得很清楚

我比较喜欢 Google 文档里的一点：它把限制写得很直。截至 2026 年 6 月的官方文档，Gemini Cloud Assist investigations 仍属于 Preview；从 2026 年 4 月 10 日开始，创建、运行和编辑 investigations 仅面向有 Premium Support 合同的用户，或已通过 account team 获取访问的用户。它也明确说明 investigation 主要用于 Google Cloud 环境内的目标排障，一次 investigation 限定在单个 Google Cloud project 或单个 App Hub application。

权限边界也写得很清楚。Investigation 使用 OAuth 2.0 token，但 token 的访问范围受运行用户或服务账号权限限制，而且不会用于修改数据。同一个 investigation 重新运行时，结果可能因为大模型概率性和 Google Cloud 状态变化而出现小差异。Google 也提醒用户验证 AI 输出。

这些边界不是减分项，反而增加了可信度。生产运维里，最不可信的产品往往是声称什么都能做的产品：全域自动调查、全自动根因分析、全自动修复、适配所有系统、无需配置、无需上下文、无需人工。听起来很强，工程师不会信。Google 这样的边界更像生产系统里的 AI：我能帮你查 Google Cloud 内的目标范围，我使用你的权限，我不会拿 token 去改资源，我可能给出多个假设，你需要验证。

Support handoff 是云厂商的独特优势

Gemini Cloud Assist investigations 还有一个很重要的能力：如果用户有 support package，可以从 investigation 页面发起 Request support，把 investigation results 作为上下文交给 Google Cloud support engineer。这件事看起来只是工单入口，其实很关键。

复杂事故最后经常会升级。升级到二线，升级到平台团队，升级到数据库团队，升级到云厂商支持，升级到中间件厂商。升级时最浪费时间的事情，就是上下文丢失：前面的人查了什么，哪些资源相关，哪些日志异常，哪些假设被排除，哪些证据支持当前判断，影响时间是什么，已经尝试过哪些动作。如果这些都要重新口头同步，事故响应一定慢。

Google 把 investigation 交给 support engineer，本质上是把 AI RCA 做成支持升级前的结构化证据包。国内厂商也应该学这一点。不要只想着 AI 一次性解决所有问题，更现实的是让 AI 减少升级成本：一键转工单，一键拉二线，一键生成专家摘要，把 evidence、hypotheses、timeline、resources、recommended fixes 带过去。专家处理完以后，再把最终结论回写到 knowledge base。

Support handoff 把调查结果变成证据包

国内厂商的机会在跨域上下文

Google Cloud 原生能力很强，但它的边界也很清楚：主要围绕 Google Cloud。国内客户现场通常不是这样。他们有公有云，也有私有云；有国产云，也有 IDC；有 Kubernetes，也有物理机和虚拟机；有托管数据库，也有自建 Oracle、MySQL、Redis、Kafka；有企业微信、飞书、钉钉、本地 ITSM、CMDB、网络设备、专线、防火墙、负载均衡、存储和中间件，还有大量历史系统。

所以国内厂商不能只照抄 Google Cloud Console 里的 investigation。真正要做的是跨域 investigation：从云资源到应用，从应用到 K8s，从 K8s 到主机，从主机到数据库，从数据库到网络，从告警到工单，从工单到变更，从变更到发布，从 IM 群到复盘。

Google 给了一个很好的产品形态：observations、hypotheses、revisions、support handoff。国内厂商要补的是跨环境、跨工具、跨团队、跨流程的上下文。更现实的应用模型建设路径，也不是指望客户一次性把 CMDB 补齐，而是自动发现一部分，从调用链和监控数据推断一部分，从 CMDB、工单、发布系统导入一部分，让工程师在 investigation 过程中修正一部分，再把修正结果回写到应用模型里。AI RCA 的过程，本身也应该反哺应用模型。