从裁员名单公布到我开始写第一行监控配置中间只隔了一个周末。我们公司第一次裁员运维岗被整体优化我这个后端开发被留下来理由居然是“你以前写过部署脚本”从此过上了一人身兼开发、运维、DBA、网管的日子。第一天上班打开工单系统未处理告警挂了四十多条业务群里的消息像雪崩一样往下滚。我坐在工位上盯着黑底白字的终端意识到一个特别残酷的事实手头连一张像样的系统拓扑图都没有别说快速定位故障我连服务是不是真的挂了都得靠业务方截图告诉我。所以我做了个决定与其天天救火不如花两周从0搭建一套可观测性平台而且一定要用上AI。毕竟作为一个刚转岗的“半路出家运维”我既没有几十年踩坑攒下的经验也没有时间把官方文档逐字啃完。AI正好能帮我补上这块短板——它可以帮我写配置、生成看板、解释指标含义甚至帮我设计整个架构。折腾完这套平台之后我感觉这不仅是给自己的“定心丸”更让我真正摸清了公司整个系统的家底。这篇文章就从头讲讲我是怎么用AI把一套可观测性平台从0搭起来的踩了哪些坑以及哪些经验是文档里不会写的。1. 光杆运维的第一周我为什么决定先搞可观测性1.1 没有统一监控的运维就是在盲人摸象其实接手第一天我并不是完全两眼一抹黑。公司服务器上装了Zabbix监控着十几台机器的基础负载。但问题在于这套Zabbix是当年一位离职的同事匆匆装的很多监控项早已失效触发器阈值还是默认配置一台8核16G的机器CPU连续超过1分钟大于90%就疯狂告警业务方半夜被震醒之后只能自己重启服务根本不敢等运维。日志散落在各个服务器上要用的时候一个一个SSH上去grep。线上接口卡了还是挂了全凭用户反馈。这种状态有个特别明显的特征不是“没有数据”而是“有数据但看不见”。数据散在角落里无法统一关联出了事只能靠人肉翻找。这正是传统监控monitoring和可观测性observability最本质的区别——监控告诉你系统当前是不是出问题了可观测性让你在没有预设问题的情况下也能通过指标、日志、链路数据反推出“到底发生了什么”。对于一个一个人运维全公司系统的光杆司令来说后者是唯一能让我睡得着觉的东西。1.2 可观测性到底在观测什么最早接触可观测性这个概念是在之前公司的技术分享会上当时听得云里雾里。真到自己搭的时候我才弄明白它实际上就是在做三件事采集指标Metrics、收集日志Logs、串联调用链Traces。业内叫“可观测性三大支柱”再加上事件Events合起来是MELT。Metrics数字形式的聚合指标比如CPU使用率、QPS、请求延迟、错误数。它回答的是“系统现在健康吗”。Logs应用和系统输出的日志记录具体发生的事件。它回答的是“出问题时细节是什么”。Traces一次请求从入口到下游所有依赖服务的完整调用链。它回答的是“这次请求到底慢在哪一环”。当时公司体量还没到必须上分布式链路追踪的程度所以我给自己定的目标很务实一个月内先把Metrics和Logs打通Traces作为二期储备。核心目标只有一个——任何人都能打开一个统一的面板看清楚全公司所有服务器的负载状态、核心业务的请求量和错误率出问题的时候能根据看板快速缩小范围再点进关联的日志里定位原因。1.3 为什么不用商业方案坚持从0搭有人可能会问现在商业可观测性平台一大堆直接采购不香吗非要自己搭不是给自己找活干这事我认真权衡过。商业SaaS方案最大的优点是省事装个Agent数据就上来了看板做得也漂亮。但缺点是我们这套系统涉及不少客户敏感数据日志全部传到第三方平台合规和法务那一关根本过不去。私有化部署的商业方案报价动辄大几十万在裁员降本的节骨眼上想都不用想。开源方案虽然要自己折腾但好处也很明显数据不出内网、无License限制、组件之间都是事实标准以后真要扩容或者接K8s路子都是通的。更重要的是一个人维护系统开源组件出了问题还能靠社区问答解决商业黑盒反而排除问题更难。所以我定下了完全基于开源自建的技术路线。最终选型结果是一套非常经典但足够稳的组合Prometheus Grafana Loki Alertmanager 各类Exporter。2. 技术选型Prometheus、Loki这一套组合是怎么定下来的2.1 指标监控Prometheus为什么能打赢Zabbix我承认接手第一天看到Zabbix的时候我的第一反应是“要不要接着用”。毕竟Zabbix已经装了数据也有一部分了。但在让AI帮我梳理完两种方案的对比之后我果断决定离开Zabbix拥抱Prometheus。原因有三点。第一Prometheus是“拉模式”PullZabbix默认是“推模式”Push。拉模式意味着监控系统主动去目标机器的Exporter上抓取指标目标机器不需要装复杂Agent只要开放一个HTTP端口就行。这对容器环境和云主机都非常友好新增一台机器只要在Prometheus配置里加一行job就搞定。第二PromQL这套查询语言太强大了配合Grafana可以做非常灵活的聚合、环比、预测。Zabbix的触发器表达式功能也不弱但写复杂业务指标的灵活度跟PromQL完全不在一个量级。第三Prometheus的生态已经成了云原生监控的事实标准社区Exporter多得数不过来后面跟K8s、Spring Boot、MySQL各类中间件都有现成适配。这套组合里的具体组件分工也很明确node_exporter负责采集服务器基础指标CPU、内存、磁盘、网络mysqld_exporter盯数据库blackbox_exporter做HTTP探测和ICMP pingcadvisor当时我们还没上容器暂时没用等将来做Docker监控再上。指标数据统一打到Prometheus里Prometheus负责存储和查询Grafana负责可视化Alertmanager管告警分发。2.2 日志方案Loki凭什么叫“轻量级ELK”日志这块最著名的开源方案是ELKElasticsearch Logstash Kibana功能确实全面但对当时只有几台服务器的我们来说实在太重了——Elasticsearch本身要吃好几个G内存还得单独维护一套集群。我需要的日志方案必须轻、快、能不费劲地和Grafana融合。Loki正是这个定位。Loki区别于ELK最大的设计特点是它只给日志建立索引标签比如hostname、job、level而不对日志内容做全文索引。这意味着Loki不需要把日志内容全部加载到内存建倒排索引磁盘占用和内存消耗因此比ES低一个数量级。查询的时候它是通过标签过滤捞出一批日志再在结果里做类似grep的过滤。功能上虽然没有ES那种“每天上亿条日志秒级搜关键字”的能力但对于我们这种每天几百万条日志的体量完全够用。部署Loki的时候我用AI辅助生成了配置跑起来后实测内存占用只有四五百M跟ES动辄几个G相比简直感人。配合PromtailLoki的日志采集器在每台机器上收集指定的日志文件把标签自动加上主机名然后在Grafana里通过标签选择器切主机看日志体验非常顺滑。Grafana一个界面同时看指标和日志排查问题的效率提升非常明显不用再一边开着Zabbix一边SSH到服务器黑框里翻日志了。2.3 最终敲定的整体架构与组件分工在我反复让AI模拟了多轮选型之后最终敲定下来这套结构每一层都有明确的分工层级组件职责数据采集node_exporter、mysqld_exporter、blackbox_exporter、Promtail采集服务器、数据库、探测点指标与日志指标存储与查询Prometheus抓取指标、存储时序数据、执行PromQL日志存储与查询Loki Promtail采集、存储、查询日志告警Alertmanager收敛规则、分组去重、分发到钉钉/企业微信可视化Grafana指标看板、日志展示、统一入口整体逻辑很简单一台Prometheus服务器作为“大脑”定期去各台机器拉取Exporter暴露的指标各台机器上面部署Promtail把Nginx日志、应用日志、系统日志持续推给LokiGrafana同时连接Prometheus和Loki两个数据源做看板展示和日志联查告警规则写在Prometheus里触发后发给Alertmanager由Alertmanager统一做分组、抑制再推到我的钉钉。整套平台跑下来Prometheus和Loki各占1个G内存左右Grafana占几百M一共3台机器完全扛得住对资源非常友好。3. 让AI当主力我是怎么用提示词“压榨”出整套配置的3.1 先把AI当顾问逼它给出部署方案刚开始的时候我对Prometheus这套体系的了解仅限于听说过名字。让我自己去看几百页官方文档再动手两周根本搞不定。所以我第一个想到的就是让AI先当我的“资深运维顾问”把问题拆细了问它。我的问题颗粒度非常细不是“怎么搭Prometheus”而是“我有3台Ubuntu 22.04服务器1台部署业务Java应用1台部署MySQL和Redis1台准备做监控。内网环境无法访问外网服务器上不装Docker帮我给出用二进制方式部署PrometheusGrafanaLokiAlertmanager的完整步骤包括下载地址、目录规划、systemd服务文件写法”。把背景写清楚AI给出的方案基本一步到位我照着操作十分钟就能跑起来一个基础的Prometheus。这里有一个特别重要的经验让AI干活背景信息越具体输出越可用。第一次问“帮我配置Prometheus”得到的回答全是套话等我把主机清单、端口规划、版本号都告诉它之后回答几乎可以直接抄作业。因为可观测性平台本质上是高度定制化的同样一个组件单机部署和集群部署、二进制部署和容器部署配置差异非常大AI只有知道你的具体环境才能给出贴合实际的答案。3.2 用AI批量生成采集配置与告警规则核心组件跑起来后最花时间的是采集配置细节。哪些指标要采、采集频率多高、哪些服务要做健康探测这些都需要根据公司实际业务情况定制。我的做法是把每类采集需求单独拎出来问AI然后结合自己业务情况微调。比如我要监控Nginx。传统的做法是去翻nginx_exporter的文档找到stub_status模块怎么开、Exporter怎么配、Prometheus怎么抓。有了AI之后我直接问“nginx_exporter需要Nginx开启stub_status模块请给出Ubuntu下Nginx开启stub_status的配置、nginx_exporter的systemd启动参数、以及Prometheus中对应的scrape配置”。几分钟就拿到了完整的三段配置贴上去稍微改改端口就能用。告警规则的生成更能体现AI的价值。我自己刚开始写PromQL的时候经常忘了怎么聚合、怎么算过去5分钟内的变化率。让AI写就快多了。我给它提需求“写一条PromQL监控MySQL的慢查询数量如果最近5分钟的慢查询数量比过去30分钟的平均值高出2倍就触发告警。”AI生成的规则可能有不精确的地方但作为底稿完全可用我再根据实际情况调整阈值和表达式细节比自己从零写快了一个量级。3.3 Grafana看板让AI生成JSON我再手动微调Grafana有一个特性所有看板Dashboard本质上是一个JSON文件可以导出、导入。这个特性让AI有了极大的施展空间。传统做法是在Grafana界面里手动拖拽图表一点点选数据源、写查询、调样式搭一个像样的看板怎么也得一两个小时。现在我的做法是让AI直接生成一个完整的Dashboard JSON。我给的提示词是“请生成一个Grafana Dashboard的JSON文件用于监控Linux服务器基础状态。要求包含以下面板CPU使用率、负载、内存使用率、磁盘空间使用率按挂载点区分、网络流入流出速率、TCP连接数。数据源类型是Prometheus指标来自node_exporter面板用英文名每个面板要有合适的unit和阈值颜色。”AI输出的是完整JSON我直接在Grafana里导入一次成功再改改个别查询语句就上线了。但这里要给大家提个醒AI生成的JSON也不是万能的。Grafana版本不同JSON的schema会有细微差异如果导入报错多半是版本兼容问题。我的经验是先跟AI明确“我的Grafana版本是v10.x请使用适配这个版本的dashboard schema”出错率会降低很多。另外不同公司用的指标名可能不太一样比如磁盘空间指标在node_exporter新版本里叫node_filesystem_avail_bytes旧版本叫node_filesystem_free_bytesAI如果不知道你用的Exporter版本生成的查询就可能查不到数据导入后图表是空的这时候要去查一下实际指标名让AI修正。3.4 我自己总结的三条AI辅助运维心得搭建这套平台前前后后用AI生成了几十段配置和代码踩了一圈下来我总结了三条心得我觉得对用AI搞运维的新手会很有用。第一给AI一个“角色和上下文”。每次提问开头先声明“你是一个有10年经验的SRE”再把我的系统现状复述一遍最后提需求。这样AI的回答会更具体、更贴身而不是泛泛而谈。第二让AI给出可选方案并说明取舍。不要只问“怎么做”要问“有哪几种做法各有什么优缺点你推荐哪一种”。AI在这种开放问题上能给出非常全面的分析帮我避开了很多坑。比如最开始时我想把Loki和Prometheus装在同一台机器上AI直接告诉我这两个组件的内存峰值可能撞在一起建议分开部署或限制内存使用避免高负载时互相拖垮。第三把AI当成“解释器”而不是“最终答案”。AI给的配置我几乎都会让它解释一下每段配置是干什么的如果你自己没搞懂生成的东西出了问题根本不知道从哪下手。这个环节很花时间但恰恰是它帮我快速补齐了运维知识。比如我第一次看到Prometheus的rate()函数不太理解AI用“计算每秒平均增量”这句话就让我秒懂了比看文档快得多。4. 告警规则与通知链路一个能睡安稳觉的关键设计4.1 告警不是越多越好要先生成再收敛刚开始搭告警系统时我的想法特别简单粗暴——所有指标异常了就告警CPU高就告警内存高就告警磁盘高就告警。结果“上线”当天晚上我的手机直接被震成了震动棒光是磁盘空间告警就刷了上百条。原因很简单我的告警阈值设得不合理比如磁盘使用率超过80%就告警但公司的备份任务每天早上都会把磁盘临时冲到82%跑完就又降下来还有一条根因告警会连带触发多个相关告警比如MySQL连接数太高同时触发了连接数告警、线程数告警、请求延迟告警三连轰炸。后来我根据AI帮整理的告警收敛策略对规则做了重新设计关键思路有三个。区分告警级别P0级服务不可用立即通知、P1级核心指标异常5分钟内响应、P2级资源水位偏高工作时间处理。配置for参数做持续校验一条告警不是一触发就通知而是持续异常超过指定时间比如5分钟再通知避免瞬时抖动造成误报。在Alertmanager里做分组与抑制相同告警名的通知合并成一条不同告警之间根据规则做抑制比如某台机器已经触发主机宕机P0那这台机器上所有P2级告警自动静默不再重复打扰。4.2 一批最值得抄作业的基础告警规则指标告警是搭建可观测性平台中最有性价比的一环。我让AI根据公司实际环境生成了一份适合中小型公司的Prometheus告警规则然后我根据自己的理解微调了阈值。大家如果搭Prometheus可以参考这套思路不用完全照搬但结构可以抄告警对象PromQL表达式阈值级别主机CPU使用率100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 90% 持续10分钟P1磁盘空间即将耗尽node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/} * 100 10% 持续5分钟P1MySQL实例存活up{jobmysql} 0持续1分钟P0MySQL慢查询突增increase(mysql_global_status_slow_queries[5m]) 前30分钟均值2倍P2HTTP探测失败probe_success{jobblackbox} 0持续3分钟P0这个列表第一版是AI根据“常见生产环境风险”生成的我看了之后最直观的感受是它的告警模板比我想得全面得多很多我完全没有意识到的风险点都被覆盖了。比如它提醒我监控systemd服务状态这个对排查服务进程存活问题特别关键传统做法大家只会盯进程但有时候进程在systemd服务已经failed了。后来我补上了node_systemd_unit_state{statefailed} 1这条规则确实帮我在一次服务崩溃时提前发现了一个潜在隐患。4.3 告警通知从钉钉机器人到值班轮转Alertmanager的配置是整套系统里AI帮了最多忙的地方。要让告警通知到手机上第一步是在钉钉群里创建自定义机器人拿到Webhook地址然后在Alertmanager配置里配置webhook接收器。这个配置文件如果不熟悉YAML语法非常容易踩缩进错误的坑。而AI生成YAML是它的强项把Webhook地址和告警分组方式告诉它它直接给出一段完整的Alertmanager配置复制粘贴就能用。比较值得一提的一点是Alertmanager支持消息模板。默认的通知内容非常干瘪只有告警名和标签业务方看了根本不知道是哪个服务、影响哪些用户。后来我让AI帮我写了一个自定义通知模板把告警名、级别、实例地址、当前指标值、开始时间、还有一句简单的“可能影响”说明全部塞进去。消息模板看起来可读性强多了业务方的同事半夜收到告警也不会打电话过来问“这到底啥意思”。4.4 别迷信默认阈值一定要根据业务调参这应该是整套搭建过程中最有感触的一件事。告警阈值这东西网上随处可见模板但每个公司的业务场景不一样阈值必须自己校正。比如我一开始照搬模板给磁盘设置了“使用率超过80%告警”结果前面说了被备份任务多次“误报”。后来我把阈值改成85%并且加了for: 10m误报基本消失。再比如MySQL的连接数阈值默认是“超过200告警”但我们的一台业务库本身就配置了500的最大连接数日常连接数稳定在150左右200告警等于天天报警。最终我让AI根据这台机器的历史数据分布给了一个建议把阈值调到300并且只在持续5分钟以上时才触发。这件事给我的教训是告警系统建好之后头两周不要急着润色看板先把每一条告警规则的阈值跟真实数据对照一遍宁可门槛高一点也不要天天被打扰否则所有人最后都会习惯性忽略告警那才是最大的风险。5. 部署阶段踩过的坑存储计算、Exporter权限、Grafana空数据5.1 Prometheus的存储占用估算没你想的那么可怕一个特别让我纠结的问题是Prometheus和Loki到底要吃多少磁盘网上说法五花八门有的说Prometheus一天能吃好几十个G有的说Loki对磁盘要求很高。我在部署前特意让AI帮我根据公司规模做了估算。公司当时大概十几台服务器要采集平均每台暴露几百个时间序列总共约一两万个序列采集频率设为15秒一次。按照Prometheus的压缩算法估算这样一天约产生几个G到十几个G的数据保留15天的话300G左右的磁盘就足够从容了。实测下来Prometheus数据目录一天的增长量在6~8G之间跟估算基本吻合。这里分享一个通用计算公式单个时间序列的存储开销 ≈ 每秒写入样本数 × 样本大小约1~2字节× 保留时间。比如1万个序列15秒采集一次那么每秒约产生667个样本一天就是5760万个样本按Prometheus压缩后每个样本约1.5字节算一天的存储约为86G。但这是最坏情况实际生产里很多序列是counter类型Prometheus的压缩率非常高实测会低很多。所以大家如果担心磁盘可以按“保留天数 × 每天预计数据量 × 1.5倍安全系数”来规划留点余量更稳妥。5.2 一个让我折腾到深夜的Exporter权限问题部署node_exporter的时候按教程解压、写systemd服务、启动一切都很顺利。结果到Prometheus里一看CPU、内存都能采到但磁盘的node_filesystem_avail_bytes这个指标是零。查了半天才发现是他默认Exporter配置里把某些挂载点过滤掉了虚拟文件系统、临时文件系统默认不采集。修改方法是在node_exporter的启动参数里加上--collector.filesystem.mount-points-exclude^(/dev|/proc|/sys|/var/lib/docker/.)($|/)这样一段排除规则。但问题是我一开始完全不知道有这个参数是AI帮我定位出来的。当时我做了这样一个操作在服务器上跑curl -s localhost:9100/metrics | grep filesystem然后把输出贴给AI告诉它“disk相关指标缺失”。AI很快分析出问题出在挂载点过滤直接给出了启动参数的修复方案。这个操作模式我后来又用了几次把异常现象指标为0、采集不到、看板为空的描述尽量精确地告诉AI最好附上相关命令输出它能非常快地给出定位方向。对新手来说这个“采集数据→贴给AI→获得排查方向”的闭环是上手最舒服的地方。5.3 Grafana常见空图数据源、Job名的“三连环”还有一个特别容易踩并且特别让人抓狂的坑Grafana导入模板后图表一片空白没有任何数据。这个问题我前后遇到三次每次原因都不太一样幸好最终都用AI排查解决了。总结下来导致Grafana图表空白的三个最常见原因是数据源不匹配导入的看板用的是“Prometheus”类型数据源但你Grafana里的数据源名字可能是“Prometheus-1”需要在看板设置里改数据源变量。Job名不匹配很多看板模板里查询语句硬编码了jobnode_exporter但你Prometheus配置里的job名可能写的jobnode一个单词对不上图表就是空的。指标名不匹配Exporter版本差异会导致指标名不同。比如某些老看板用的node_cpu新版Exporter已经改名为node_cpu_seconds_total。排查的时候我一般先在Grafana的Explore页面手动执行那条查询看有没有返回数据没有的话就逐层排查数据源连通性、job名、指标名。让AI看截图或者查询语句它也能快速指出问题。这里建议大家写一个“指标字典”文档把每类Exporter的关键指标名记录进去防止时间久了记不清。5.4 部署时候的一些“隐藏刚需”除了上面几个大坑还有几个小问题是文档里很少强调、但实际部署时一定会遇到的。一个是Promtail/Loki的版本兼容问题。Promtail和Loki需要保持版本一致否则可能出现日志推送失败。我一开始分别用了两个版本Loki那边一直报错日志里看是接口路径不匹配后来把Promtail升级到和Loki同一版本问题消失。另一个是Grafana的匿名访问和权限。公司内部看板我不想让每个人都要建账号登录但也不能完全公开数据。我的做法是Grafana开启匿名访问但匿名用户只能看指定的几个“只读”看板其他看板和管理功能需要登录账号。这个配置在Grafana的defaults.ini和看板权限设置里搞定AI给了详细步骤操作起来也很顺畅。最后是systemd服务的开机自启。所有采集组件都写成systemd服务比用nohup或者systemctl enable后开机自启要稳得多。当时AI生成的systemd文件里直接带了Restartalways这个参数很重要意思是服务异常退出后自动拉起。有一次node_exporter进程挂了系统几十秒内又把它拉起来数据只丢了短时间的一小截如果不是这个参数没人盯着的话可能监控空白一整天。6. 从可观测到自动化运维AI还能把人的活干到哪一步6.1 可观测性平台真正带来的改变整套平台上线的第一周我最大的感受不是“告警变少了”而是“心里有底了”。以前业务方反馈接口慢我只能先登录服务器再一路top、free、df -h、tail -f手忙脚乱地排查既慢又容易漏。现在直接在Grafana一个页面里看这个应用的CPU、内存、请求延迟曲线再往下翻一翻Loki里这台机器这个时间段的应用日志基本可以快速圈定问题范围。有一个真实案例特别能说明问题。上线后第二周的一个下午业务方反馈后台导出报表功能很卡。我打开Grafana看板发现导出服务所在主机的磁盘IO有一个非常陡峭的峰值同时Loki里的日志大量刷“临时文件写入失败”。前后花了不到5分钟定位到是磁盘满了顺着清理了临时文件服务立刻恢复。换做以前这种问题可能要翻一两小时日志才能猜出来。6.2 我给AI规划的第二阶段让它当“半个值班工程师”可观测性平台只是第一步。平台搭好之后数据每天都在积累我逐渐意识到这些数据的价值远不止看看实时曲线。当前我让AI帮我把日常巡检工作自动化了每天早上让AI生成一条PromQL例行查询自动汇总昨天全公司的核心指标趋势输出一份简短的“昨日运维日报”包括哪些机器CPU持续偏高、哪些接口延迟有上升趋势、磁盘空间环比消耗了多少。用cron定时执行一个脚本脚本调用Prometheus的API拉数据再交给AI生成摘要然后推送到飞书群里。这个思路再往前走一步就是AI Agent也是最近圈子里聊得最多的话题。我现在在研究的是当一条P0告警触发时AI能不能自动登录服务器执行几个诊断命令把结果汇总成一封包含“现象、初步原因、建议动作”的工单推给我而不是让我半夜被震醒之后还要自己跑命令。这个方向目前已经有初步的成本我给AI写了一个很粗略的“告警诊断Agent”用公司内网的API把Prometheus告警推给AIAI根据告警标签自动从Prometheus拿指标数据、从Loki拿相关日志再综合给出分析。跑通了一部分但它目前还不能自主登录服务器执行命令我的底线是可以让AI做分析和建议但涉及变更操作必须人工审批。毕竟运维这个行当出一次权限事故的代价远大于省下的那点人力。6.3 给同样“被迫上岗”的运维新人的几个建议如果有朋友和我一样是半路出家、被形势推着负责运维我想以自己的经历给你几条建议。第一先搭可观测性再谈优化。不要一上来就想搞K8s、搞微服务先把“看得见”的问题解决。服务器有哪些、跑什么服务、每天负载曲线是什么样这些是后续所有决策的地基。第二AI是油门不是方向盘。AI能帮你写出90%的配置但最后那10%的业务理解和判断必须由你自己完成。AI建议的告警阈值不一定适合你的系统AI生成的看板也可能有指标名错误本质上它是一本“会说话的文档”但不是一个“懂你业务的运维”。第三把所有配置都当成代码来管理。Prometheus的rules.yml、Alertmanager的配置、Grafana的Dashboard JSON、systemd unit文件我已经全部纳入Git管理改了配置就提交一个版本。这样即使哪天模式被改乱了回滚也是一行命令的事。第四记录你自己的运维手册。AI可以帮你写配置但写不了你自己系统中的“特殊地形”——哪些机器不能随便重启、哪个业务的流量高峰是几点、哪个服务之间有隐蔽的依赖关系。这些东西我每次遇到都记在文档里慢慢形成了一份只有自己看得懂的“公司系统地图”这份地图的可观测性比Grafana看板还重要。6.4 下一步给平台做一次“体检”和扩展平台已经跑了一个多月稳定性和使用体验都在逐步提升。我现阶段最想做的三件事按优先级排列是给整个平台加一层统一认证目前Grafana账号只有我和研发老大有后续要给其他需要看板的人开通权限就要考虑用LDAP来管把Traces链路追踪补上公司后端是Java Spring Boot为主接上Micrometer Tracing和Tempo配合现有Loki日志就能把“应用Trace-ID关联到日志”这条链路打通最后是给Prometheus和Loki各做一个本地备份策略毕竟监控系统自己挂了那才是真·“盲人摸象”。搭建这套可观测性平台的过程最核心的收获不是学会了几个工具的使用而是让我真正建立起了“系统可以被我理解”的信心。读到这里的朋友如果你也在经历类似的情况我希望你能记住一件事可观测性不是终点它只是让你从“天天被问题追着跑”变成“可以主动去看清楚问题”的一个起点。用AI辅助搭建不是为了偷懒而是把有限的时间留出来去做那些真正需要人类判断的事情——比如搞清楚业务指标为什么抖动比如决定下一阶段系统该朝哪个方向演进。这场被裁员“逼”出来的技术转型回头看反而成了我这段时间最有收获的经历。如果你也在用AI折腾运维相关的系统欢迎在评论区聊聊你的思路一起把那些“别人文档里不会写”的经验沉淀下来。
