企业官网建设流程全解析

网站开发一般要哪些开发工具,做前端开发需要学什么,seo个人优化方案案例,免费ppt模板下载app本文字数#xff1a;12964#xff1b;估计阅读时间#xff1a;33 分钟作者#xff1a;Manveer Chawla本文在公众号【ClickHouseInc】首发TL;DRAI SRE 出问题#xff0c;原因在于数据缺失#xff0c;而不是智商不够。大多数系统之所以无法定位根因#xff0c;是因为它们构…本文字数12964估计阅读时间33 分钟作者Manveer Chawla本文在公众号【ClickHouseInc】首发TL;DRAI 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 UnderstandMTTU同时规避了自动化修复所带来的风险。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 条数据库查询。一个典型的流程可能是检查受影响服务的最新错误情况。按版本和区域拆分错误分布。与部署记录和特性开关进行交叉验证。拉取最慢端点的追踪数据。关联客户影响或业务指标。如果在传统可观测性平台上每个查询都需要 20 到 30 秒那么整个反馈循环几乎无法成立。当每一步都要等待数分钟才能返回结果时基于 AI 的工作流会变得异常迟缓反而不如直接使用原生仪表盘高效。问题四按查询计费的成本放大效应人类分析师与 AI 智能体在调查方式上存在本质差异。人类通常只会写一条或少量查询等待结果再进行分析。而 AI 智能体则会进入“思维链Chain of Thought”循环在短时间内连续发出多达 27 条查询用来梳理依赖关系、识别异常点并验证假设。如果你的可观测性数据存放在按查询收费的系统或数据库中例如 New Relic 或 BigQueryAI 智能体会迅速放大成本。如果使用的是并发能力受限的传统数据库智能体花在查询队列中等待的时间甚至可能超过真正用于分析问题的时间。这正是核心限制所在许多 AI SRE 工具试图在并非为高并发、高基数、长保留分析查询而设计的平台之上进行推理。无论是提示工程还是模型微调都无法彻底弥补一个无法存储或高效提供关键数据的数据底座。你无法指望用“AI”来绕过存储与查询层面的现实约束。为什么 ClickHouse 是构建 AI SRE 副驾驶的理想数据库ClickHouse 从根本上解决了三个关键问题存储成本、高基数处理能力以及查询延迟。在可观测性场景中现代解决方案例如以 ClickHouse 作为核心数据引擎的 ClickStack相较于基于倒排索引构建的传统可观测性平台通常可以实现数量级的成本与性能提升。从整体上看差异体现在以下方面数据问题基于倒排索引的传统可观测性技术栈基于 ClickHouse 的可观测性保留周期完整日志仅保留 7–14 天随后进行激进采样或汇总在 PB 级规模下完整保真日志、指标和追踪可保留数月基数处理为控制索引体积而丢弃或预聚合高基数维度通过稀疏索引与压缩原生支持数十亿唯一值查询速度多维聚合查询需要数秒甚至数分钟针对典型事故查询可在数十亿行数据上实现亚秒级扫描与聚合大语言模型兼容性依赖少样本Few-shot提示或针对自定义 DSL 微调通过标准 SQL 实现零样本Zero-shot直接使用真正的经济性来自架构设计而不是市场话术。列式存储与压缩带来更长的“记忆”。机器生成的日志和指标在按列存储时具有极高的压缩效率。在真实部署中相比倒排索引引擎相同体量的原始遥测数据存储占用往往可以降低 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 serverMCP 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 ModelLLM不需要更多“玄学”它们需要的是一名资深 SRE 在排障时会亲手收集的同样上下文。在那次 ClickHouse 实验中工程团队刻意使用了非常简单、甚至有些“天真”的提示去回答一个高度聚焦的问题一个大模型是否能够仅凭当今大多数组织已经存储的遥测数据直接推断出事故根因这样做的目的是模拟许多 AI SRE 集成在开箱即用状态下的真实表现而不是展示一个带有自定义检索层、经过精细调优的理想化系统。这个基线非常关键。当然更好的提示工程和更复杂的编排机制确实能带来提升任何严肃的生产部署也都应该采用它们。但它们解决不了短保留周期、关键维度被丢弃或上下文缺失的问题。如果数据库从一开始就没有存下相关的历史数据或系统拓扑那么无论提示写得多巧妙都无法把不存在的信息“问”出来。上下文类型能够回答的关键问题存储在 ClickHouse 中的示例数据部署上下文“系统刚刚发生了哪些变化”包含 commit_sha、version、author 和 timestamp 的 deployments 表。服务拓扑“我们的系统之间是如何相互依赖的”描述服务依赖关系、SLO 以及团队归属的表。*事故历史“这种情况我们以前遇到过吗”通过 SQL 可搜索的历史事故记录、根因分析RCA以及已知故障模式归档。部落知识“资深专家的经验结论是什么”将复盘文档、Wiki 页面和关键 Slack 对话生成向量化嵌入用于语义搜索。*虽然可以基于 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 ProtocolMCP智能体可以直接查询外部系统例如 ArgoCD、GitHub 或 Incident.io。这种联邦式方式非常适合权限模型复杂的数据例如 Slack 历史记录或者变化频繁的数据例如“当前谁在值班”。但在核心的关联分析闭环中例如把某次指标飙升与具体的部署时间戳对应起来将数据直接存放在 ClickHouse 中可以显著提升性能。模型只需执行一条 SQL就能把数百万行日志与部署事件 JOIN 在一起而无需对五个不同系统发起缓慢的 API 调用再在上下文窗口里费力地做人工关联。理想的搭配是使用 MCP 获取“软”上下文Slack、文档、PagerDuty 状态而将需要高性能 JOIN 的“硬”上下文日志、指标、部署事件交给 ClickHouse。当 AI SRE 拥有这些上下文之后它的行为就开始接近一名资深工程师——那种还记得六个月前发生过一次诡异存储回归的人。副驾驶自动化地检索这些部落知识而这些信息原本会随着人员轮换而逐渐流失。丰富上下文如何带来更准确的洞察在缺乏上下文的情况下一次事故查询往往只是“用户在反馈结账失败请找出根本原因。”一个真正有效的 AI SRE 并不会简单地把这段原始文本交给模型。首先编排层会查询 ClickHouse收集最近的部署信息、依赖健康状况以及历史上的相似事件。随后它会构建一个有据可依的提示grounded prompt也就是一组高度数据化的指令使大语言模型Large Language ModelLLM在零样本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 作为核心认知基础设施时组织才有可能开始减少事故发生的数量而不仅仅是更快地处理事故。结论打好基础掌控运维的未来这一模式已经非常清晰。在 ClickHouse 上构建一个高性价比、高保真度的可观测性存储层。为部署、拓扑、事故和客户建立一个丰富的上下文层涵盖目前散落在 Slack 和文档中的各种软信号。通过 MCP 和经过严格约束的 SQL将这一数据底座安全地暴露给大语言模型副驾驶。从值班辅助入手然后将这些能力逐步扩展到代码评审、测试和规划阶段。完成这一架构转型的团队不只是会拥有更好的 AI SRE 工具还会形成一种全新的可靠性姿态——事故响应将退居兜底角色而不再是默认的运行方式。如果你的 AI SRE 项目陷入停滞不要先换一个新模型而是先换一个新数据库https://auth.clickhouse.cloud/u/signup。一旦可观测性变得低成本、高保真、且易于查询副驾驶才真正有了可以发挥“智能”的空间。征稿启示面向社区长期正文文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出图文并茂。质量合格的文章将会发布在本公众号优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至Tracy.Wangclickhouse.com