平凉市网站建设_网站建设公司_网站制作_seo优化

本文字数：12964；估计阅读时间：33 分钟

作者：Manveer Chawla

本文在公众号【ClickHouseInc】首发

TL;DR

• AI SRE 出问题，原因在于数据缺失，而不是智商不够。大多数系统之所以无法定位根因，是因为它们构建在传统的可观测性技术栈之上：数据保留时间短、缺乏高基数数据，而且查询速度缓慢。

• 一个 AI SRE 本质上是：大语言模型（Large Language Model） + 构建在丰富可观测性与上下文层之上的 SQL 能力。一个真正有效的副驾驶，需要一个快速、可扩展的数据底座，能够在较长时间内保留全保真遥测数据，同时还要有一个上下文层来补齐信息缺口。

• 以 ClickHouse 为代表的 OLAP 是构建 AI SRE 副驾驶基础的理想数据库。ClickHouse 让长期保留、高基数的可观测性在实践中可行，因此成为构建 AI SRE 副驾驶的完美选择。

• 最终收益在于：AI 作为人类专业能力的放大器。真正的 AI SRE 会负责搜索、关联和总结信息，让值班工程师把精力集中在决策本身。

此刻是凌晨 2:13。

你的 AI SRE 副驾驶自信地给出了结论：“结账链路的错误率上升，是因为 Payment 服务变慢了。”

二十分钟后，你才发现真正的原因是一项错误的特性开关（feature flag）发布。这个所谓的“副驾驶”，不过是在复述你的仪表盘内容。这不是副驾驶，而只是给图表套了一层聊天界面。

AI SRE 工具曾承诺要彻底改变事故响应方式，但现实中的大多数实现都令人失望。它们无一例外地把大语言模型对准可观测性数据，试图解释哪里出了问题、为什么会出问题，而事实证明，这条路走不通。

在我于 Confluent 负责平台和存储团队、并将可用性 SLA 从 99.9 提升到 99.95 的过程中（https://www.confluent.io/blog/making-apache-kafka-10x-more-reliable/），我学到了一件颇为反直觉的事：绝大多数事故，最终都归结为三种非常直接的纠正动作之一——回滚一次错误变更、重启一个不健康的组件，或是通过扩容来承载更高负载。

真正执行修复往往只需要几分钟，难点始终在于搞清楚问题的根本原因。

到底是配置错误、吵闹的邻居（noisy neighbor）、控制平面死锁，还是一次细微却致命的存储回归？回答这些问题，需要的是深入调查，而不是简单照着操作手册（runbook）执行。

很多 AI SRE 工具正是在这里力不从心。它们要么倾向于自动化修复，要么把自己包装成自愈系统，而在大多数真实生产环境中，这既危险，也没有必要。另一些工具则把重点放在关联分析、信息摘要和告警降噪上。

无论是哪一类，背后都面临同一个约束：它们试图在一个并非为 AI 优先调查而设计的可观测性底座之上进行大规模推理。因此，大多数 AI SRE 产品的实际效果都差强人意。

说到底，我们的目标并不是打造一个自动帮你重启数据库的机器人。AI SRE 应该是一名调查员，负责分析数据，把决策权交还给值班的人类。

AI 负责追踪线索，人类负责做出决定。

这种人类在环（Human-in-the-Loop）的方式，直击真正的瓶颈——平均理解时间（Mean Time to Understand，MTTU），同时规避了自动化修复所带来的风险。

ClickHouse 工程团队最近验证了一个问题：前沿模型是否能够基于真实的可观测性数据，自主找出事故根因。结果既令人不安，又极具启发性。即便是 GPT-5，在能够访问详细遥测数据的情况下，也无法稳定、可靠地完成这一任务。真正的限制在于：

“瓶颈不在于模型有多聪明，而在于上下文缺失、缺乏扎实的数据锚点（grounding），以及没有领域专长。”

决定性因素是数据底座，而不是大语言模型。模型确实能读取日志和指标，但它们面对的往往是保留周期很短的数据、不完整的维度，以及割裂的上下文信息，本质上是在用不完整的信息进行推理。

现在，我将这个问题拆分为两个层面来看。第一，构建一个真正捕获 AI 调查员所需信息的可观测性基础，同时具备合理的成本结构和查询特性。第二，把 AI 用在它最擅长的地方：减少工程师在关联分析、模式匹配和叙事整理上的时间消耗，同时确保行动决策仍然掌握在人类手中。

本文将展示，如何在坚实的可观测性基础之上，为值班工程师构建一个真正有价值的 AI SRE 副驾驶，从而弥补这一关键差距（https://clickhouse.com/resources/engineering/best-open-source-observability-solutions）。

是什么导致 AI SRE 工具在生产环境中频频失效

许多 AI SRE 产品，本质上只是叠加在老旧可观测性平台之上的一层薄封装。它们不可避免地继承了这些系统在成本模型和架构设计上的限制，并且几乎都会以三种可预期的方式触及同样的瓶颈。

问题一：保留周期不足

大多数基于“搜索优先”、倒排索引架构发展起来的传统可观测性平台，主要按照数据摄入量计费。在大规模使用时，这种定价模式会迫使团队极端压缩数据保留周期。实践中，日志通常只保留 7 到 14 天，指标数据的保留时间稍长一些。虽然更早的数据可能会被放入所谓的“冷层”，但这些存储层几乎无法提供智能体分析所需的查询响应速度。

对于 AI SRE 副驾驶而言，短暂的保留周期意味着没有历史记忆。一个正在调查今天结账失败问题的模型，无法看到六周前在一次类似部署之后曾出现过相同模式，因为那时的日志已经被清理掉了。

季节性变化、极少发生的边缘情况，以及长尾事故，都会因此彻底消失在视野之外。

从可靠性角度看，每一次事故都仿佛是第一次发生。模型无法利用组织自身的历史经验进行学习，而无论多么精巧的提示工程，都无法弥补根本不存在的数据。

如果你的日志只能记住两周，那么你的 AI SRE 也注定如此。

问题二：高基数维度缺失

为了控制成本和性能，在搜索优先的系统中，团队往往会主动丢弃高基数维度。用户 ID、会话 ID、请求 ID、细粒度错误码以及更精细的标签，经常会因为会显著增加倒排索引引擎的索引体积和查询延迟而被移除。

但正是这些字段，才是 AI SRE 进行事件关联时最关键的线索。

根因分析往往需要把某个症状精确关联到特定的用户群体、地理区域、部署版本或特性开关。如果这些维度没有被保留下来，模型能看到的就只剩下汇总后的趋势曲线和模糊的错误信息。它或许可以描述“错误率上升了”，却无法回答“影响了哪些客户”“是哪一次变更导致的”“问题沿着哪条路径扩散”。

全栈层面的可见性盲区

在 Confluent，高基数问题叠加复杂的系统架构，形成了更加棘手的局面。我们的系统同时包含数据平面、控制平面以及底层云基础设施层。真正能够完整理解“磁盘延迟峰值如何一路传导，并最终影响数据层持久性”的工程师，在整个组织中也屈指可数。

事故响应因此常常演变为协作难题。我们不得不把五个不同的团队拉进同一个电话会议，只为拼凑出一幅完整的系统图景。每个团队都只能在各自的工具中看到局部的指标和日志，真正的诊断过程发生在人们的脑海中，以及临时的交流之中。

只有当所有层级的数据集中存放在同一个地方，AI SRE 才有可能真正弥合这一断层。

当控制平面、数据平面、云指标以及应用遥测全部汇聚到 ClickHouse 中时，副驾驶就不再受制于团队边界。它可以从负载均衡器一路追踪请求，穿过 API 层，直达磁盘层，跨越人类在高压故障处理中难以跨越的可见性鸿沟。

问题三：查询速度瓶颈

在 ClickHouse 的实验中，工程团队量化了 AI 智能体在真实事故中的行为方式。AI SRE 是在一个循环中工作的：提出假设、查询数据、修正理解、再次查询。在一次调查过程中，模型往往需要迭代执行 6 到 27 条数据库查询。

一个典型的流程可能是：

1. 检查受影响服务的最新错误情况。

2. 按版本和区域拆分错误分布。

3. 与部署记录和特性开关进行交叉验证。

4. 拉取最慢端点的追踪数据。

5. 关联客户影响或业务指标。

如果在传统可观测性平台上，每个查询都需要 20 到 30 秒，那么整个反馈循环几乎无法成立。当每一步都要等待数分钟才能返回结果时，基于 AI 的工作流会变得异常迟缓，反而不如直接使用原生仪表盘高效。

问题四：按查询计费的成本放大效应

人类分析师与 AI 智能体在调查方式上存在本质差异。人类通常只会写一条或少量查询，等待结果，再进行分析。

而 AI 智能体则会进入“思维链（Chain of Thought）”循环，在短时间内连续发出多达 27 条查询，用来梳理依赖关系、识别异常点并验证假设。

如果你的可观测性数据存放在按查询收费的系统或数据库中（例如 New Relic 或 BigQuery），AI 智能体会迅速放大成本。如果使用的是并发能力受限的传统数据库，智能体花在查询队列中等待的时间，甚至可能超过真正用于分析问题的时间。

这正是核心限制所在：许多 AI SRE 工具试图在并非为高并发、高基数、长保留分析查询而设计的平台之上进行推理。无论是提示工程还是模型微调，都无法彻底弥补一个无法存储或高效提供关键数据的数据底座。

你无法指望用“AI”来绕过存储与查询层面的现实约束。

为什么 ClickHouse 是构建 AI SRE 副驾驶的理想数据库

ClickHouse 从根本上解决了三个关键问题：存储成本、高基数处理能力以及查询延迟。

在可观测性场景中，现代解决方案（例如以 ClickHouse 作为核心数据引擎的 ClickStack），相较于基于倒排索引构建的传统可观测性平台，通常可以实现数量级的成本与性能提升。

从整体上看，差异体现在以下方面：

真正的经济性来自架构设计，而不是市场话术。

列式存储与压缩，带来更长的“记忆”。机器生成的日志和指标在按列存储时具有极高的压缩效率。在真实部署中，相比倒排索引引擎，相同体量的原始遥测数据，存储占用往往可以降低 10 到 15 倍。这种差异直接转化为更长的数据保留周期，也为副驾驶提供了更丰富的历史背景。

面向分析场景的向量化执行，让副驾驶的反馈循环保持交互性。事故分析依赖聚合、过滤和时间范围操作。ClickHouse 在压缩数据之上，通过高效的向量化执行完成这些操作。在现代硬件上，它可以在几毫秒内扫描并聚合数十亿行数据，即便模型连续发起数十次查询，反馈依然足够迅速。

稀疏主键索引替代全局倒排索引，使高基数维度得以保留。ClickHouse 的 MergeTree 表采用有序主键和轻量级索引，而不是为每个字段维护昂贵的倒排索引。这种设计能够在模式中自然容纳请求 ID、用户 ID 等高基数维度，而不会导致索引规模失控。

标准 SQL 带来零样本流畅性。大语言模型是在互联网上海量 SQL 语料中训练出来的，却往往难以适应 SPL、KQL、PromQL 等专有查询语言。使用 ClickHouse 这样的 SQL 原生数据库时，你无需在上下文窗口中教模型一门新语言，也不必针对自定义语法进行微调，模型的注意力可以完全聚焦在数据本身，而不是语法细节。

当这样的存储引擎成为现代可观测性解决方案的核心时，AI SRE 副驾驶将建立在一个截然不同的基础之上：数据保留从“几天”延伸到“数月”，维度信息完整保留，查询速度足够快，模型可以反复迭代。正是这样的基础，为 AI 提供了沿着技术栈向下追踪问题所需的关键线索。

如何通过 SQL 解决上下文窗口受限的问题

这里有一个常见的问题：“在只有 128k Token 上下文窗口的情况下，AI 智能体要如何读取数月的日志数据？”

答案是：它并不会把这些日志直接读进来。数据会先在数据库中被压缩处理，智能体通过 SQL 扫描 PB 级的历史数据，只把真正有价值的结果（通常只是 KB 级别）送入上下文窗口。

传统的可观测性工具通常只有两种使用方式：“搜索”（直接列出日志）以及“聚合”（用于折线图的时间序列指标）。而 ClickHouse 提供的是完整的 SQL 能力。

完整的 SQL 让智能体可以在数据库层执行复杂逻辑（例如 JOIN、窗口函数和子查询），在海量数据中筛选信号、排除噪声，从而避免把大块原始数据直接塞进上下文窗口。

注意：构建 AI SRE 副驾驶并不一定非要使用 ClickHouse。任何能够提供类似成本结构和查询特征的数据库都可以胜任。我们之所以更看好 ClickHouse，是因为已经验证它能够在 PB 级规模下稳定运行，但真正关键的是整体架构模式，而不是某一个具体产品。

参考架构：面向 SRE 的 AI 副驾驶

当数据底座就绪之后，AI SRE 副驾驶就可以被抽象为一种清晰、可描述的架构模式。

从整体来看：

核心组成部分包括：

1. OpenTelemetry collector

通过 OpenTelemetry collector，将应用、基础设施和服务产生的日志、指标以及追踪数据统一采集并写入 ClickHouse。Fluent Bit、Vector 和 OpenTelemetry Collector 等不同的摄入工具，都可以最终汇聚到同一个数据库中。

2. ClickHouse 与可观测性层

• 日志存储在 MergeTree 表中，包含时间、服务、环境等基础字段，以及 user_id、request_id 等高基数字段。

• 指标以原始事件形式存储，以确保完整保真度，仅在需要加速常见查询和仪表盘时才使用物化视图（Materialized Views）。这意味着你可以随时按新的维度重新聚合数据，而不像某些系统那样必须提前做汇总。

• 追踪数据以 span 树的结构存储，包含 trace_id、span_id、parent_span_id、service_name 以及相关属性。

• 同时还维护用于部署、特性开关、事故以及客户信号的上下文表。

3. 一个简单的日志表示例可能如下：

CREATE TABLE otel_logs ( Timestamp DateTime64(9), ObservedTimestamp DateTime64(9), -- Trace context TraceId FixedString(32), SpanId FixedString(16), TraceFlags UInt8, -- Severity SeverityText LowCardinality(String), SeverityNumber UInt8, -- Body Body String, -- Common resource attributes ServiceName LowCardinality(String), ServiceNamespace LowCardinality(String), DeploymentEnvironment LowCardinality(String), -- Remaining resource attributes ResourceAttributes Map(String, String), -- Log attributes LogAttributes Map(String, String), -- Scope ScopeName String, ScopeVersion String ) ENGINE = MergeTree PARTITION BY toDate(Timestamp) ORDER BY (ServiceName, Timestamp);

4. ClickHouse MCP server

MCP server 负责将 ClickHouse 安全地暴露给大语言模型。模型不会直接接触原始凭证，而是通过一个受控的中介通道，获取表结构目录、受限的 SQL 接口，以及发起查询的能力。

在 ClickHouse 的实验中，模型在一次事故调查过程中通常会发出 6 到 27 条 SQL 查询。这之所以可行，是因为 ClickHouse 能够在不发生超时的情况下，对数十亿行数据进行高频、交互式查询。

5. AI 副驾驶层

副驾驶负责把自然语言问题转化为结构化的分析流程。最简单的实现形式，就是一个大语言模型加上 SQL。更复杂的方案可能会引入检索增强生成（retrieval-augmented generation）和基于智能体的路由机制，但核心逻辑始终一致：模型不断向 ClickHouse 发送查询、检查返回结果，并在此基础上逐步修正和完善自己的假设。

例如，一名值班工程师可能会提出这样的问题：

“为什么在过去 20 分钟里，us-east-1 区域的结账错误率突然飙升？”

传统工具往往只能展示最近一小时的数据。而一个由 ClickHouse 驱动的副驾驶，则可以生成一条查询，直接扫描数月的历史数据，用来判断这是否是一次新的回归问题。

SELECT min(Timestamp) AS first_seen, max(Timestamp) AS last_seen, count() AS errors FROM otel_logs WHERE Timestamp >= now() - INTERVAL 30 DAY AND ServiceName = 'checkout' AND SeverityText = 'ERROR' AND body ILIKE '%PaymentTimeout%' AND ResourceAttributes['cloud.region'] = 'us-east-1'

如果查询结果显示 first_seen 出现在 10 分钟前，AI 就能判断这是一次由最近变更触发的全新回归；如果 first_seen 早在 20 天前就已经出现，那么调查方向就应该转向其他可能原因。之所以能做到这一点，前提只有一个：数据库能够在亚秒级时间内扫描整整 30 天的日志数据。

高性能的执行能力，加上足够丰富的数据模式（schema），让这样的分析闭环真正跑得起来。

如何构建提升根因判断准确性的上下文层

TL;DR：大语言模型（Large Language Model，LLM）不需要更多“玄学”，它们需要的，是一名资深 SRE 在排障时会亲手收集的同样上下文。

在那次 ClickHouse 实验中，工程团队刻意使用了非常简单、甚至有些“天真”的提示，去回答一个高度聚焦的问题：一个大模型，是否能够仅凭当今大多数组织已经存储的遥测数据，直接推断出事故根因？这样做的目的，是模拟许多 AI SRE 集成在开箱即用状态下的真实表现，而不是展示一个带有自定义检索层、经过精细调优的理想化系统。

这个基线非常关键。当然，更好的提示工程和更复杂的编排机制确实能带来提升，任何严肃的生产部署也都应该采用它们。但它们解决不了短保留周期、关键维度被丢弃或上下文缺失的问题。如果数据库从一开始就没有存下相关的历史数据或系统拓扑，那么无论提示写得多巧妙，都无法把不存在的信息“问”出来。

*虽然可以基于 ClickHouse 中的追踪数据动态生成服务拓扑，但一个真正面向生产的副驾驶不应只依赖遥测数据。在真实事故中，遥测系统本身往往会失效或出现缺口。一个权威的拓扑“事实来源（Source of Truth）”，可以在追踪链路中断时，帮助 AI 继续保持正确的系统认知。

在真实系统和生产实践中，当模型获得的上下文结构与人类 SRE 的思考方式高度一致时，其可靠性会显著提升。这些上下文完全可以，也理应，与遥测数据一起存放在 ClickHouse 中。

部署上下文：刚刚发生了哪些变化

副驾驶首先需要清楚系统最近发生了什么。

• 最近的代码提交及对应作者

• 按服务和环境记录的部署事件

• 特性开关的变更及发布状态

• 配置项更新

一个部署表示例可能如下所示：

CREATE TABLE deployments ( Timestamp DateTime64(9), -- Service identification (matching otel_logs) ServiceName LowCardinality(String), ServiceNamespace LowCardinality(String), ServiceVersion String, -- Deployment context DeploymentEnvironment LowCardinality(String), DeploymentName String, -- VCS/Git information VcsRepositoryUrl String, VcsCommitSha String, VcsCommitAuthor String, VcsCommitMessage String, VcsBranch String, -- Deployment metadata ChangeType LowCardinality(String), -- e.g., 'rollout', 'rollback', 'hotfix' DeploymentStatus LowCardinality(String), -- e.g., 'success', 'failed', 'in_progress' -- Additional attributes DeploymentAttributes Map(String, String) ) ENGINE = MergeTree PARTITION BY toDate(Timestamp) ORDER BY (ServiceName, Timestamp);

有了这些信息，副驾驶就可以将错误率的异常峰值，精确关联到具体的版本和提交作者。

服务拓扑与归属关系：系统之间是如何关联的？

拓扑结构和归属关系对于避免“拓扑失明”至关重要。所谓拓扑失明，是指智能体只盯着当前报错的服务，却忽略了真正出问题的上游依赖。##

• 服务依赖关系图，例如调用方（caller）、被调用方（callee）以及通信协议

• 从服务映射到对应团队或值班组（pager group）的归属关系

• 按服务和具体端点定义的 SLA/SLO

在 ClickHouse 中，这些信息可以用简单的关系表来表示；当需要多跳上下文时，还可以结合追踪数据，通过递归公共表表达式（recursive common table expressions）在依赖链路上进行遍历。

历史模式与事故：我们是否遇到过类似问题？

当提供足够具有代表性的案例时，大模型在识别模式方面的能力非常强。

• 指标和日志特征相似的历史事故

• 按服务整理的已知故障模式与操作手册（playbook）片段

• 从根因到修复动作之间的映射关系

这些数据都可以按 service_name 和标签建立索引，并在模型生成总结或建议之前，通过 SQL 进行检索。

超越追踪和仪表盘的上下文：专家经验在哪里？

在 Confluent 的真实事故处理中，我们从来不只依赖仪表盘。我们会持续在 Slack 以及其他系统中搜寻各种“软信号”。

工程师们经常会问：

• 这种情况以前发生过吗？

• 最近是谁改动了这个服务？

• 上个季度那次类似故障的复盘文档在哪里？

我们高度依赖过往的事故记录、部署公告，以及在聊天工具中记录的其他正在发生的事故。这些经验性的部落知识至关重要，但它们以非结构化文本的形式，零散地分布在不同工具中。

对于 AI SRE 来说，ClickHouse 中的上下文层并非可有可无。只存日志和指标远远不够，你还需要摄入：

• 包含提交信息和发布说明的部署历史

• 事故归档以及事后复盘文档

• Slack 讨论线程或事故频道的摘要信息

实现说明：数据摄入 vs. 联邦访问（MCP）

你并不需要把所有数据都通过 ETL 管道导入 ClickHouse。借助模型上下文协议（Model Context Protocol，MCP），智能体可以直接查询外部系统（例如 ArgoCD、GitHub 或 Incident.io）。

这种联邦式方式非常适合权限模型复杂的数据（例如 Slack 历史记录），或者变化频繁的数据（例如“当前谁在值班？”）。

但在核心的关联分析闭环中（例如把某次指标飙升与具体的部署时间戳对应起来），将数据直接存放在 ClickHouse 中可以显著提升性能。模型只需执行一条 SQL，就能把数百万行日志与部署事件 JOIN 在一起，而无需对五个不同系统发起缓慢的 API 调用，再在上下文窗口里费力地做人工关联。

理想的搭配是：使用 MCP 获取“软”上下文（Slack、文档、PagerDuty 状态），而将需要高性能 JOIN 的“硬”上下文（日志、指标、部署事件）交给 ClickHouse。

当 AI SRE 拥有这些上下文之后，它的行为就开始接近一名资深工程师——那种还记得六个月前发生过一次诡异存储回归的人。副驾驶自动化地检索这些部落知识，而这些信息原本会随着人员轮换而逐渐流失。

丰富上下文如何带来更准确的洞察

在缺乏上下文的情况下，一次事故查询往往只是：

“用户在反馈结账失败，请找出根本原因。”

一个真正有效的 AI SRE 并不会简单地把这段原始文本交给模型。首先，编排层会查询 ClickHouse，收集最近的部署信息、依赖健康状况以及历史上的相似事件。随后，它会构建一个有据可依的提示（grounded prompt），也就是一组高度数据化的指令，使大语言模型（Large Language Model，LLM）在零样本（Zero-shot）条件下也能给出可靠的判断：

有据可依的提示（由副驾驶引擎合成）：

“用户在反馈结账失败。Payment 服务在 47 分钟前完成了一次部署，提交为 abc123，作者 engineer X，版本 2.3.7，区域 us-east-1。Payment 服务依赖 Fraud 服务，而 Fraud 服务在过去 50 分钟内出现了延迟升高。2025-03-15 曾发生过一次类似事故，错误码为 PAYMENT_TIMEOUT，其根因是 Fraud 服务中的缓存饱和。请调查最可能的根本原因。”

差别不在于表达方式，而在于信息密度。第二个提示中编码了来自 ClickHouse 表的具体事实——部署、追踪、历史事故和指标。模型基于与资深 SRE 手动排查时几乎相同的信息进行推理，从而显著提高给出正确解释的可能性。

值班工程师的工作流：引入 AI SRE 之前与之后

这个系统并不是用来取代值班工程师的。当工程师在凌晨 2 点被不停震动的寻呼器叫醒时，它的作用是为工程师提供支持。

事后阶段：自动化 RCA 与知识沉淀

可靠性工作的终点，并不止于把故障处理完。在 Confluent，值班团队有相当一部分精力投入在事后工作上：撰写根因分析（RCA）文档、还原完整时间线，并确保经验教训能够在规模庞大、共享的值班轮换体系中传播开来。

这些工作非常重要，但同时也高度重复。工程师需要反复翻查 shell 历史、查询记录、Slack 频道以及各种仪表盘，才能拼凑出事情真正发生的经过。

而在一个基于 ClickHouse 的副驾驶体系中，这些信息大多已经被系统掌握。

• 它清楚事故期间执行过哪些查询，以及它们的先后顺序。

• 它能够看到哪些服务、区域和客户受到了影响。

• 它可以把采取的缓解措施，与指标逐步恢复正常的过程关联起来。

由于副驾驶会实时跟踪整个调查过程，它可以直接为你起草 RCA。工程师不再需要花上两个小时从头还原事故，而是由副驾驶生成一份结构化报告，其中包含时间线、促成因素、影响分析以及指向相关数据的链接。

值班工程师要做的，是审阅并修正这份草稿，而不是面对一张空白文档从零开始。

这同时也缓解了我反复观察到的一个问题：经验教训在工程师之间传播得并不好，尤其是在采用共享值班轮换、且一线防守团队不断变化的组织中。

当每一次事故都会生成一份格式一致、机器可读的 RCA，并存储在 ClickHouse 中时，整个组织都会变得更容易搜索，也更容易传承经验。下一位值班工程师可以直接询问副驾驶：“我们以前遇到过类似的问题吗？”系统会立刻返回相关的历史事故、对应的时间线以及最终的修复方案。

针对生产系统的独立研究（例如 Microsoft 的 RCACopilot）已经证明，只要检索层设计得当，并且扎根于最新的遥测数据，这种模式就能显著提高根因分析的准确性，并缩短调查时间。

我的看法与这些结论一致：让大语言模型协助调查过程、总结发现、起草更新和提出下一步建议，同时通过一个快速、可搜索的可观测性技术栈，确保工程师始终掌握最终控制权。

数据库负责保存实时与历史数据，副驾驶负责关联分析与叙事整理，而最终决策仍然由人类完成。

副驾驶并不会取代值班工程师，它只是让工程师直接从“第 5 页”开始工作，而不是从“第 1 页”翻起。

向上游推进：从更快的 RCA 到更少的事故

当日志、指标、追踪、部署上下文、系统拓扑以及客户信号都汇聚到一个统一、快速、可查询的数据层中，一些关键变化就会随之发生。支撑 AI SRE 副驾驶进行事故处理的这套数据基础，同样也能推动更上游的可靠性改进工作。

多项能力因此成为现实。

合并前风险分析。通过将历史事故与具体的代码模式、服务以及部署特征进行关联，团队可以构建模型，在 Pull Request 合并之前就标记出潜在高风险变更。这些信号直接来源于存储在 ClickHouse 中的真实生产历史，而不是依赖通用的经验规则。

主动式模式检测。那些今天只在事故发生时才运行的查询，可以持续在后台执行。当某种历史上曾引发故障的模式再次出现时，系统能够在事故真正发生之前就通知工程师，为干预争取宝贵时间。

以客户为中心的可靠性。由于客户和业务影响与遥测数据共存于同一个数据库中，可靠性工作的优先级可以基于真实的用户痛点来确定，而不是仅仅依赖抽象的错误数量。副驾驶能够回答诸如“本季度哪些可靠性问题影响了我们的前十名客户？”或“哪些服务产生了最多的支持工单？”之类的问题。

这种向上游延伸的视角，正是当下许多 AI SRE 产品所缺乏的。如果系统唯一的发力点是事故响应，那么它注定只能被动应对。而当可观测性基础本身就是 AI 原生的，并且由 ClickHouse 作为核心认知基础设施时，组织才有可能开始减少事故发生的数量，而不仅仅是更快地处理事故。

结论：打好基础，掌控运维的未来

这一模式已经非常清晰。

1. 在 ClickHouse 上构建一个高性价比、高保真度的可观测性存储层。

2. 为部署、拓扑、事故和客户建立一个丰富的上下文层，涵盖目前散落在 Slack 和文档中的各种软信号。

3. 通过 MCP 和经过严格约束的 SQL，将这一数据底座安全地暴露给大语言模型副驾驶。

4. 从值班辅助入手，然后将这些能力逐步扩展到代码评审、测试和规划阶段。

完成这一架构转型的团队，不只是会拥有更好的 AI SRE 工具，还会形成一种全新的可靠性姿态——事故响应将退居兜底角色，而不再是默认的运行方式。

如果你的 AI SRE 项目陷入停滞，不要先换一个新模型，而是先换一个新数据库（https://auth.clickhouse.cloud/u/signup）。一旦可观测性变得低成本、高保真、且易于查询，副驾驶才真正有了可以发挥“智能”的空间。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com