凌晨两点，告警群突然刷屏。

CPU 高了，接口慢了，Pod 重启了，数据库连接数也不太对。你打开 Grafana，看见一堆曲线；再去翻日志，像在黑夜里找一颗掉在地上的螺丝。

最难受的地方在于：系统明明接了监控，图也有，告警也有，可真正出故障的时候，大家还是会在群里一句句问：

• “谁最近发版了？”
• “刚才是不是改过配置？”
• “数据库有没有慢查询？”
• “下游是不是又抖了？”
• “要不先重启一下？”

这种场景，我相信做过线上系统的人都不陌生。

这也是我想写这个系列的原因。不是为了追一个新词，也不是为了把“AI + 运维”包装得多热闹，而是想认真梳理一件事：当系统越来越复杂，我们到底该怎么理解它、观察它，并在它出问题之前，尽量少一点手忙脚乱。

我们不是没有监控，而是系统还不会“说人话”

很多团队不缺工具。

Prometheus 有了，Grafana 有了，日志平台有了，链路追踪也接了一部分。

稍微成熟一点的团队，还会有告警分级、值班轮转、故障复盘、发布审计。

这些东西当然重要。

但问题是，一到事故现场，工具经常只是把“哪里不正常”摊在你面前，并不会直接告诉你“为什么会这样”。

传统监控更像体温计。

它告诉你发烧了，但不会告诉你是感冒、炎症，还是昨晚没睡好。你还得结合咳嗽、血常规、病史、最近接触了什么人，才能判断大概原因。

系统也是一样。

CPU 高、接口慢、错误率上升，这些只是症状。真正要弄明白的是：一次请求经过了哪些服务？慢在哪一步？哪个版本开始出现异常？某个配置变更和故障时间能不能对上？

这才是可观测性想解决的问题。

它不是给系统多装几个仪表盘，而是让系统在出问题时，能留下足够清楚的线索。

云原生之后，故障很少只坏在一个地方

以前的系统相对简单。

一个应用，一台服务器，一个数据库。CPU 高了看进程，磁盘满了清空间，数据库慢了查 SQL。虽然也会焦头烂额，但排查路径至少比较直。

云原生之后，这件事变了。

一个用户请求可能先经过网关，再到鉴权服务，再到业务服务，再访问缓存、消息队列、数据库，过程中还可能跨集群、跨可用区，甚至依赖外部 SaaS 或第三方接口。

这时候故障不太像“某个点坏了”，更像一串反应。

比如一个接口突然变慢。

最开始你看到的是 P99 延迟升高。继续查，发现数据库连接池快被打满。再往前翻，发现半小时前发布的新版本里新增了一个查询路径。再看流量，刚好某类用户请求比例也变高了。

每个信号单独看，都像一块碎片。 碎片足够多，但没人把它们拼起来，排障还是靠经验。

这就是很多团队“监控做了很多，故障还是靠猜”的根源。

数据不是没有，关系没建立起来。

AIOps 不是自动重启服务这么简单

一提到 AIOps，很多人会马上想到自动处理告警、自动扩容、自动重启、自动修复。

这些能力不是不重要，但如果一上来就奔着“自动操作生产环境”去，风险很大。

因为自动化最怕的不是动作慢，而是判断错。

一个系统如果不理解上下文，它可能在错误的时间做一个看似正确的动作。比如明明是下游数据库慢，结果它不断重启上游服务；明明是新版本引入了问题，结果它只是在扩容，把故障规模越扩越大。

我更愿意把 AIOps 看成可观测性的下一层能力。

它首先要帮我们做的，不是“替人操作”，而是“帮人判断”：

• 这个告警是不是重要？
• 它和哪些日志、指标、链路、变更事件有关？
• 有没有类似历史故障？
• 影响范围大概在哪？
• 下一步应该先查数据库，还是先看发布记录？

这些问题，比“要不要自动重启一下”更接近一线工程师真正需要的帮助。

做得好的 AIOps，不应该像一个莽撞的脚本执行器，而应该像一个熟悉系统的老同事：它不一定替你拍板，但能快速把关键线索摆出来。

真正难的是从“看到异常”走到“理解异常”

传统监控关心的是状态：

• 红了没有？
• 超过阈值没有？
• 服务挂没挂？
• 磁盘是不是快满了？

这些都很重要，但还不够。

复杂系统里，真正有价值的是关系：

• 日志记录发生了什么。
• 指标记录系统趋势。
• Trace 还原请求路径。
• 事件记录发布、扩容、配置变更这类关键动作。

单独看，它们都只是线索。连起来，才可能接近答案。

比如某个接口 P99 延迟升高。

指标告诉你：它慢了。 Trace 告诉你：慢在某个数据库查询。 日志告诉你：某类请求触发了异常路径。 事件告诉你：15 分钟前刚发布过一个版本。

到了这一步，AI 才真正有用。

不是因为它会“看图”，而是因为它可以帮你把分散的线索放在一起，做初步关联，减少人在一堆 Dashboard 和日志窗口之间来回切换的成本。

这也是我理解的 AI 原生可观测性：不是把界面做得更炫，而是让系统从“展示数据”往“解释问题”靠近一步。

别急着上大模型，先把地基整理干净

现在很多团队聊 AIOps，很容易直接聊到大模型、智能体、自动修复。

但真实落地时，第一步往往一点都不酷：

• 日志字段是不是统一？
• request_id 有没有贯穿全链路？
• Trace 能不能跨服务串起来？
• 指标标签有没有统一口径？
• 发布、配置变更、扩缩容有没有沉淀成事件？
• 服务之间的依赖关系是不是清楚？

这些问题看起来基础，但它们决定了后面的智能化有没有意义。

如果日志里没有 request_id，Trace 里没有版本信息，指标标签一会儿叫 app，一会儿叫 service，发布记录只散落在群消息里，那 AI 看到的也只是一堆碎片。

它可能给出一个很像答案的判断，但你很难信它。

所以这个系列不会一开始就讲“如何做一个自动修复 Agent”。

我更想先把基础问题讲清楚：系统如何留下线索，线索如何互相关联，工程师如何基于这些线索判断问题，AI 又应该在哪些环节介入。

技术越往上走，越不能跳过地基。

比“稳定”更现实的目标，是“有韧性”

过去我们经常说系统要稳定。

但做过生产环境的人都知道，系统不可能永远不出问题。

节点会故障，依赖会超时，发布会引入 Bug，流量会突然变化，第三方服务也可能莫名其妙抽风。

所以我现在更喜欢用“韧性”这个词。

韧性不是保证系统永远不坏，而是坏了以后，能不能更早发现、更快定位、影响更小、恢复更快。

这也是 AI 原生可观测性真正值得期待的地方。

它不只是让 Dashboard 更智能，而是让团队逐渐从事后救火，往提前发现和主动预防靠近。

比如，在传统阈值触发之前识别异常趋势；把几十条重复告警合并成一个事件；根据服务拓扑推断影响范围；结合发布记录提示可疑变更；给出排查顺序，而不是让值班同学从零开始翻日志。

这些能力听起来没有“全自动修复”那么刺激，但对真实团队更实用。

因为多数时候，我们不缺一个替我们按按钮的机器人。 我们缺的是一个能在混乱现场帮我们理清线索的系统。

这个系列不想写成工具安装手册

这个系列不会从“怎么安装 Prometheus”开始。

不是工具不重要，而是工具永远会变。

Prometheus 会升级，Grafana 会换版本，OpenTelemetry 的生态会继续演进，模型和 Agent 框架更不用说，几个月就会冒出一批新东西。

但一线团队面对的问题，其实长期没怎么变：

系统越来越复杂，故障越来越隐蔽，告警越来越多，排查越来越依赖少数老同事的经验。很多事故处理完了，经验留在群聊里，留在某个人脑子里，真正沉淀到系统里的并不多。

所以我更想写的是一套运维思考方式。

它会讲工具，但不会停在工具。 它会讲 AI，但不会把 AI 神化。 它会从真实工程问题出发，讨论一个技术团队该如何理解系统、发现异常、定位问题，并一步步减少故障带来的影响。

后面会围绕这些问题往下写

这个系列大概会沿着几条线展开。

第一条，是重新理解可观测性。

监控和可观测性到底差在哪里？为什么 Dashboard 很多，事故现场还是靠猜？为什么日志、指标、Trace、事件必须放在一起看？

第二条，是把可观测性放回工程流程里。

可观测性不是上线后补几个探针，也不是平台团队单方面搭一套系统。它应该从代码设计、接口定义、错误码、日志字段、发布流程里就开始考虑。

开发写代码时多留一个关键字段，事故现场可能就少翻半小时日志。发布事件记录得清楚一点，根因分析时就少猜一个方向。

第三条，是讨论 AI 在运维里的边界。

AI 可以做异常检测、告警聚合、故障摘要、根因推断、处理建议。 但它不能替代混乱的数据基础，也不能保证每次判断都对，更不能在没有权限边界和回滚机制的情况下随便操作生产环境。

AI 应该先成为可靠的排障助手，再谈更进一步的自动化。

第四条，是从被动救火走向主动预防。

很多团队的运维模式，本质上还是事故驱动：出一次故障，加一个告警；再出一次问题，补一个 Dashboard；复盘写了很多，下次还是靠人盯。

更好的方向，是把问题从“用户已经感知”往前推到“系统刚开始不正常”。

第五条，是平台化和产品化。

成熟团队不能只靠几个专家会用工具。好的可观测性能力，应该变成团队内部的基础设施：开发能自助接入，新人能按标准排查，平台团队能持续沉淀经验，AI 也能基于统一数据给出更可靠的建议。

最后，它不应该只是一个“看图的地方”，而应该成为团队理解系统、运营系统、改进系统的入口。

我会尽量用工程现场的话来写

这个系列会尽量避开两种写法。

一种是堆概念。

把可观测性、AIOps、SRE、平台工程、智能体、根因分析这些词全摆上来，看起来很高级，但读完不知道明天能做什么。

另一种是工具流水账。

第一篇装 Prometheus，第二篇装 Grafana，第三篇装 Jaeger。这样的内容当然有价值，但如果没有整体认知，很容易变成“工具都装了，事故还是查不清”。

我更希望每篇文章都回答一个具体问题：

• 为什么监控越做越多，告警反而越来越吵？
• 为什么很多 Trace 接入后没人看？
• 为什么日志不规范会直接拖垮 AI 分析质量？
• 为什么根因分析不能只靠大模型猜？
• 为什么自动修复必须分级、限权、可回滚？
• 为什么可观测性应该从代码设计阶段就开始？

这些问题不一定宏大，但都很真实。

只要你做过线上系统，大概率都被其中几个问题折磨过。

开篇先做一个小检查

在进入后面的文章前，可以先找你们系统里最核心的一个接口，问自己几个问题：

• 它出错时，我能不能快速找到对应日志？
• 它变慢时，我能不能知道慢在哪个下游？
• 它经过了哪些服务，我能不能用 Trace 串起来？
• 最近一次发布、配置变更、扩容记录，能不能和异常时间对上？
• 如果半夜出问题，新同事能不能靠现有信息判断大概方向？

如果答案大多是否定的，你们缺的可能不是更多告警，而是一套真正可用的可观测性体系。

AI 很重要，但它不是起点。

起点是让系统留下清晰、可信、能关联的线索。

只有这样，AI 才能从“看起来很聪明”，变成真的能帮工程师少熬几个夜晚。

读后思考：你们团队现在的监控系统，是在帮助你理解问题，还是只是更快地通知你“出事了”？

欢迎在评论区留下你的答案。