三个月前，我还是一个纯后端开发。

公司给所有人配了Cursor，开发效率提升了，然后开始裁员。

部门重组之后，我和我的leader被划进了一个新的盘子：数仓 + 运维。

两个板块，都不是我的主业。

leader看着新的组织架构图，问我：

"可观测性平台这块，你来负责？"

我当时脑子里只有一个念头：

我连Prometheus和Grafana有什么区别都说不清楚。

但我说了"好"。

因为没有别的选择。

---

一、第一天：我到底不知道什么

接下来的事，比想象中要快。

原因只有一个：AI。

但在说AI怎么帮我的之前，我想先说第一天我做的一件事——

把自己不知道的东西，全部列出来。

可观测性平台，这个词我听过，但说不清楚。于是我直接问Claude：

我是一个Java后端开发，没有运维背景。
公司让我从0搭建可观测性平台。
请告诉我：
1. 可观测性平台到底是什么，解决什么问题
2. 行业里主流的方案有哪些
3. 一个非运维背景的人，应该按什么顺序学习这个领域

AI给了我一个我能看懂的解释：

可观测性平台的核心是三件事：

• Metrics（指标）：系统现在健不健康？CPU、内存、QPS
• Logs（日志）：系统发生了什么？错误日志、请求日志
• Traces（链路追踪）：一个请求经过了哪些服务，慢在哪里？

把这三件事做好，出了问题你才能快速定位。

三个词，我记住了。

然后AI给了我一张"知识地图"，告诉我行业里的主流方案：Prometheus + Grafana（指标）、ELK（日志）、SkyWalking / Jaeger（链路）、以及云厂商的一站式方案（阿里云云监控、腾讯云 CLS 等）。

第一天结束，我从"完全不知道"变成了"知道自己需要搞清楚什么"。

这是AI在这个阶段最大的价值：帮我把一个陌生领域快速结构化。

---

二、调研阶段：用AI读懂我读不懂的东西

接下来一周，是密集的调研期。

我们初步圈定了三个方向：

• 阿里云云监控 2.0：托管方案，接入成本低
• ELK（Elasticsearch + Logstash + Kibana）：日志方向成熟方案，开源自建
• SkyWalking：链路追踪主流选择，开源自建

每个方案，我都要搞清楚：能做什么、不能做什么、适合什么规模、成本怎么算。

这些东西，官方文档几十页，英文夹中文，充斥着我不熟悉的术语。

我的做法是：把文档喂给AI，让它帮我翻译成"Java后端能理解的语言"。

举个具体例子。

SkyWalking的官方文档里有一段关于存储后端选型的说明，涉及到H2、MySQL、ElasticSearch、TiDB几种存储，每种都有适用场景。

我直接把这段贴给Claude：

我是Java后端，没有运维背景。
以下是SkyWalking存储选型的官方说明，请帮我：
1. 用大白话解释每种存储的适用场景
2. 我们公司日活5万，数据量不大，你推荐哪种？为什么？
3. 有什么坑是文档没写但实际部署会遇到的？

AI的回答让我避开了一个真实的坑：

H2是内存存储，重启数据全没，只适合本地开发测试，生产环境绝对不能用。 你们日活5万，数据量不大，MySQL完全够用，而且你们团队肯定有MySQL运维经验， 不要为了"上ElasticSearch"而上，增加不必要的复杂度。

如果我自己读文档，大概率不会注意到H2的这个限制，或者觉得"存储选型是后面的事"先跳过了。

AI帮我把"文档里没写清楚的坑"提前挖出来了。

整个调研周，我用这个方法把三个方案全部啃完，还让AI帮我生成了一张对比表格的初稿：

+--------------+-------------------------------+------------------------+------------------------+
| 维度         | 阿里云云监控2.0               | ELK自建                | SkyWalking自建         |
+--------------+-------------------------------+------------------------+------------------------+
| 覆盖范围     | Metrics + Logs + Traces一站式 | 主打Logs               | 主打Traces             |
| 接入成本     | 低，有SDK直接接               | 中，需要配置Logstash   | 中，Java Agent自动注入 |
| 运维成本     | 极低，托管                    | 高，需要自己运维ES集群 | 中，需要维护OAP Server |
| 初期费用     | 按量付费，小规模便宜          | 主要是服务器成本       | 主要是服务器成本       |
| 规模化后费用 | 数据量大后成本高              | 相对固定               | 相对固定               |
| 定制化空间   | 有限                          | 高                     | 高                     |
+--------------+-------------------------------+------------------------+------------------------+

这张表格，后来成了汇报老板的核心素材。

---

三、选型决策：AI帮我想清楚一个关键问题

调研完，摆在我们面前的是一个真实的决策：

用阿里云，还是自建？

两个选择都有道理。

我把这个问题原原本本丢给了Claude：

我们公司情况：
- 日活5万，数据量不算大
- 团队没有专职运维，只有我们两个后端兼着做
- 公司希望尽快上线，最好1个月内有结果
- 预算没有明确限制，但老板关注长期成本

阿里云云监控2.0 vs 开源自建（ELK + SkyWalking），
请帮我分析：
1. 两种方案的实际落地周期差距有多大
2. 成本在什么规模下会出现拐点（自建比阿里云便宜）
3. 对于我们这种"没有运维背景的小团队"，各自的真实风险是什么

AI给了我一个我没想到的视角：

成本拐点不只是钱的问题，还有人的成本。 自建ELK，ElasticSearch集群出问题的时候，你们有能力快速修复吗？ 如果不能，业务中断的成本可能远大于你省下的服务器钱。 建议分两阶段：

• 初期用阿里云，1个月上线，先把监控体系跑通，积累经验
• 中后期当你们对这个领域熟悉了、数据量也上来了，再评估自建的时机

这不是"懒"，这是适合你们当前阶段的最优解。

这个"两阶段"的思路，不是我想到的，是AI提出来的。

但我们讨论之后觉得，这就是答案。

---

四、汇报老板：用AI把技术决策翻译成商业语言

选型确定之后，要给老板汇报。

这是我最没把握的环节。

老板不是技术出身，他不关心Prometheus和Grafana的区别，他关心的是：

• 要花多少钱？
• 什么时候能用？
• 出了问题怎么办？

我让AI帮我做了一件事：把技术选型报告翻译成老板能听懂的语言。

以下是我们的技术选型结论和理由，请帮我重新组织：
目标读者是非技术背景的老板，他关心成本、周期、风险。
请把技术细节转化为业务语言，去掉他不需要知道的术语。
格式：结论先行，理由支撑，风险说明。

[粘贴技术选型文档]

AI给出的版本，开头是这样的：

结论：初期采用阿里云云监控，预计3周上线；中后期视数据量增长评估切换自建方案。 为什么这么选： 初期我们团队没有运维经验，自建方案出问题修复成本高。 阿里云方案接入简单，可以让我们在1个月内把监控体系跑起来， 同时积累经验，为后续自建打基础。 费用预估： 初期月费约XXX元（按当前数据量估算），随数据量增长线性增加。 当月费超过YYY元时，自建方案更划算，届时我们也有足够经验支撑自建。

汇报当天，老板听完直接拍板：按这个方案走。

他说了一句话：

"你们想得比我预期的要全。"

---

五、落地执行：AI是我的"运维顾问"

选型通过之后，开始接入。

我没有运维基础，每遇到一个不懂的概念，就问AI。

几个真实的例子：

问题1：阿里云的Agent安装失败，报错看不懂

阿里云云监控Agent安装时报错：
"Failed to start cloudmonitor.service: Unit not found"
我是第一次装，不知道从哪里排查

AI给了我三步排查路径，第二步就找到了原因：系统版本和Agent版本不匹配。

问题2：Grafana看板怎么配置

我完全不会写PromQL（Prometheus查询语言），直接让AI帮我写：

我想在Grafana里展示：
- 过去1小时的接口平均响应时间，按接口分组
- 响应时间超过500ms的接口，用红色标注
请帮我写PromQL查询语句，并说明怎么在Grafana里配置

AI不只给了查询语句，还告诉我Panel类型选Time Series，阈值怎么设置颜色。

问题3：告警规则怎么定

我想配置告警：CPU使用率超过80%持续5分钟就告警。
但我不知道"持续5分钟"在云监控里怎么配，
也不知道告警应该发到哪里（钉钉群还是短信）

AI给了我配置路径，还提醒我：

建议设置两级告警：

• CPU > 80% 持续5分钟 → 钉钉群通知（低优先级）
• CPU > 95% 持续2分钟 → 短信通知（高优先级，需要立即处理）

很多团队只设一级，结果要么告警太多被忽略，要么反应太慢出事故。

这个"两级告警"的建议，是我自己不会想到的。

---

六、三周后的结果

三周，可观测性平台上线。

覆盖了：

• 所有后端服务的核心指标监控（CPU、内存、JVM、接口响应时间）
• 慢接口自动告警
• 关键业务链路的日志集中查询
• Grafana看板，一屏看清系统状态

上线第一天，监控就发现了一个问题：有个定时任务每天凌晨3点CPU会飙到90%，持续约8分钟。

原来一直有这个问题，只是没人知道。

---

七、我总结出来的方法论

这段经历之后，我把AI辅助学习陌生领域的方法整理成了五步：

第一步：结构化入门

不要直接看文档，先让AI给你画地图：这个领域有哪些核心概念、主流方案有哪些、一个外行应该按什么顺序学。

我是[你的背景]，完全不懂[陌生领域]。
请给我：
1. 这个领域的3-5个核心概念，用我能理解的语言解释
2. 主流方案有哪些，各自适合什么场景
3. 建议我按什么顺序学习

第二步：带着问题读文档

不要从第一页读到最后一页。先搞清楚自己的场景，再带着问题去读文档，遇到看不懂的直接喂给AI翻译。

以下是[方案]的官方文档片段，
我的场景是[描述你的具体情况]，
请帮我解释这段话对我意味着什么，有哪些坑要注意。

第三步：用AI做决策对比

面对多个方案需要选型时，不要让AI直接告诉你答案，而是把你的具体约束条件告诉它，让它帮你分析trade-off。

我的约束条件：[团队规模/预算/时间/技术栈]
需要在以下方案中选择：[方案A vs 方案B]
请分析各自的实际落地风险，以及适合我的选择。

第四步：翻译技术语言

需要向非技术人员汇报时，让AI帮你把技术结论翻译成业务语言。结论先行，去掉术语，重点说清楚：花多少钱、多久有结果、有什么风险。

第五步：AI做实时顾问

落地执行阶段，把AI当"随叫随到的领域专家"。遇到报错、不懂的配置、最佳实践的问题，直接问，比翻文档快得多。

---

写在最后

三个月前，我不知道可观测性平台是什么。

三个月后，我主导搭了一套跑在生产上的监控体系，还给老板汇报通过了技术选型。

不是因为我突然变成了运维专家。

是因为AI把"入门一个陌生领域需要的时间"，从3个月压缩到了3周。

但有一件事AI做不到——

它不知道你们公司的实际情况。

团队没有运维能力这个事实，是我告诉AI的。 老板关注长期成本这个信息，是我告诉AI的。 两阶段方案里"初期用阿里云"的决策，最终是我和leader拍的。

AI给你速度，但判断还是要你自己来。

---

你有没有被迫负责过不熟悉的技术领域？ 你是怎么快速上手的？

欢迎评论区聊聊。

---

后端AI实验室 不讲概念，只谈实战 代码开源，每周更新