我用Loop把告警处理做成了＂自动驾驶＂,半夜再没被叫醒过
我用Loop把告警处理做成了"自动驾驶"，半夜再没被叫醒过
运维群里有句老话：干这行，早晚得对手机震动产生应激反应。凌晨三点磁盘告警亮红，你从床上弹起来连 VPN，看了眼发现是应用日志没轮转；刚处理完躺下，四点半又来一个，这次是某台机器 Swap 飙了，原因是凌晨跑定时任务堆内存没设上限。一个晚上，两个故障，三条命已经去了半条。故障照出不误，但我把告警处理交给了 AI Loop。它自己巡检，自己定位，能搞定的事自己修，搞不定的才递到我面前。这不是什么高深的技术。看完你就会发现，这套东西搭起来比想象中简单，但效果却完全超出了预期。先说清楚概念。Loop Engineering，中文叫循环工程，说白了就是让 AI 自己形成工作闭环。以前的模式是手动挡：你给 AI 一条指令，AI 干一步活，停下来等你下一条。就像你拿着手机一条一条发消息让 AI 查服务器状态，查完磁盘查内存，查完内存看进程，每步都得你推。Loop 模式是自动驾驶：提前设好路线和规则，AI 自己跑，跑完一圈自动检查结果，决定要不要跑下一圈。你从发指令的操作员变成了设计规则的管理者。明确的目标和停止条件，而且这个条件必须是可验证的。比如"所有服务器磁盘使用率低于八成半"行，"优化一下系统性能"不行。反馈闭环，每轮跑完检查结果，判断继续还是停。最常见的是跑完巡检脚本后解析输出，有异常就继续处理，没异常就结束。状态记忆，把进度记在外部文件里，比如哪台机器巡检完了、第几轮循环在处理什么。AI 对话窗口一关就没了，靠谱的 Loop 要有持久化。公司有十几台服务器，以前每天早上的巡检流程是这样的：打开终端，连 VPN，SSH 上每台机器，跑一遍 top、free、df，看一眼应用日志，发现异常手动记下来。整个过程半小时起步，而且纯粹是体力活。后来我写了个巡检 Skill，把单机巡检自动化了。但问题是，每台机器还是得我手动触发，十几台点一遍也得十几分钟。而且巡检结果还得自己看，看出问题再手动处理。第一步：设定目标。每天自动巡检所有服务器，磁盘超过八成半报警，内存超过九成报警，CPU 负载超过核心数报警。发现异常自动诊断，简单问题自动修复，复杂问题汇总报告。第二步：搭反馈闭环。跑完巡检，解析输出，如果有告警项，AI 自动进入诊断模式。比如磁盘满了，它会自动找最大的日志目录、检查是否有僵尸进程、判断清理策略。修完再跑一轮验证。第三步：状态记忆。在项目根目录维护一个 PROGRESS.md，记录每台机器的巡检状态、当前循环轮次、上次发现的问题和处理结果。这套 Loop 跑起来之后，每天早上一杯咖啡还没喝完，巡检报告已经躺在电脑上了。异常项标红，处理结果写清楚，需要我拍板的列在最前面。从半小时压缩到扫一眼，时间省了九成不止。关键点：不要让 Loop 一轮巡检 50 台服务器，那样单轮跑太久，决策链路太长容易跑偏。拆成小批次，每批巡检完了验证通过再推下一批，效果稳得多。03）实战二：告警全自动闭环，从"弹窗"到"修好"第二个场景更进阶一些：告警触发后，AI 自动走完诊断、修复、验证的全流程，全程不需要人介入。拿磁盘空间满这个经典场景来说，我设计的 Loop 规则是这样的：# 告警自动闭环 Loop
## 触发条件
监控系统检测到磁盘使用率 > 80%
## Loop 流程（每轮自动执行）
1. SSH 登录目标机器，获取磁盘使用详情
2. 定位占用最高的目录（du -sh /data/* 2>/dev/null | sort -rh | head -10）
3. 判断文件类型：
- 日志文件 → 检查是否已轮转，旧日志自动压缩或清理
- 备份文件 → 自动同步到 OSS 后删除本地副本
- 应用缓存 → 暂停应用服务 → 清理缓存 → 重启服务 → 验证
- 未知大文件 → 跳过，汇总到报告待人工确认
4. 执行清理后重新检查磁盘
5. 磁盘使用率 < 75% → 报告完成，退出循环
6. 磁盘使用率仍 > 80% → 继续下一轮，上限5轮
## 防死循环
同一类别的清理操作超过3轮未解决 → 记录原因，挂起等待人工介入
同一台机器24小时内重复告警 → 升级到深度诊断模式
## 状态记录
维护 DISK_LOOP_STATE.md，记录每轮处理动作、结果、当前磁盘使用率第一条，判别逻辑分层次。有些大文件确实不能随便删。日志可以清，备份可以挪，但应用缓存删之前要停服务，未知文件绝对不能碰。这个分层决策链才是运维经验的价值，Loop 只是帮你执行，判断力还是你的。第二条，防死循环机制要前置。清理三轮还没解决，说明问题不是你想象的那样，可能是应用进程没关闭文件句柄、可能是软链接指错了地方。Loop 发现问题解决不了的时候，安静停下等你拍板，比闷头一顿乱操作强一百倍。⚠️ 踩坑提醒：千万别让 Loop 在没有白名单的情况下自动清理文件。我第一次跑的时候忘了限制清理范围，AI 觉得某个目录下有一堆"看起来没用的临时文件"，全清了。第二天开发找上门，说那是他们测试环境的测试数据。第一次搭磁盘清理 Loop 的时候没设循环上限，AI 一直在"清完再检查，检查发现还差一点，继续清继续查"的循环里磨。跑了快一个钟头，我回头一看，token 消耗已经超过平时一天的用量。后来学乖了，所有 Loop 必须设两个硬上限：单轮次数的上限和总时长的上限。坑二：Loop 会在"看起来成功了"的状态下报完成。有一次巡检 Loop 报告说所有服务器正常，我扫了一眼就关了。第二天用户投诉说某台应用服务器响应超时。细查才知道，Loop 上一轮巡检的时候那台机器刚好重启中没连上，AI 的判断是"连接超时，跳过"，但进度文件里只记了"已完成"，没有区分"跳过"和"通过"。修正方案也很简单：进度文件里把状态改成三态，完成、跳过、异常，每种状态都有明确的原因记录。下次喂给 AI 上下文的时候，跳过的项优先重试。社区里把这个叫 Overbaking（过度烘焙）。你让 AI"把服务器优化一下"，它可能会给你装上三个你不需要的监控 Agent、改一堆内核参数、甚至删掉你没让它碰的定时任务。目标越模糊，AI 的自由度越大，加戏就越离谱。一句话记住：告诉 Loop 要做什么，更要告诉它不准做什么。白名单永远比黑名单靠谱。一口气搞全套 Loop 系统不现实。建议分四步走，每步扎扎实实。第一步：把手动流程先文档化。把你现在每天手动做的事——巡检、日志清理、证书检查、备份验证——逐条写成流程文档。写清楚了，才能交给 AI 执行。第二步：做单步自动化。把每条流程变成一个 AI Skill 或脚本，先用单次调用跑通。比如先让 AI 能准确巡检一台机器，再考虑多台。第三步：用 /goal 跑单个闭环。给 AI 一个可验证的小目标，让它自己循环到完成为止。比如"处理这台机器上所有超过两周的日志文件，清理后磁盘使用率降到七成以下"。第四步：挂上定时调度。单次跑稳了之后，设置定时触发。每天固定时间跑巡检 Loop，监控触发后自动跑排障 Loop。逐步从"人盯着机器"过渡到"人设计规则，机器自己跑"。这个过程急不来。每一层跑稳了再搭下一层，比一上来就搞全套复杂系统效果好得多。01）停止条件必须可验证。用"磁盘使用率低于七成"这类量化指标，不用"优化性能"这种模糊表述。02）每轮循环结束后必须有反馈环节。巡检完不检查，等于没巡检。03）进度状态用三态标记：完成、跳过、异常。不要只用"已完成"糊弄自己。04）清理类操作必须配白名单。明确告诉 AI 哪些目录能碰、哪些文件类型能删。05）所有 Loop 设两个硬上限：单轮次数上限和总时长上限。钱包和理智都需要这层保护。06）同一问题超过三轮未解决，自动挂起。有些故障确实没法自动修，该认的时候就认。07）先跑单任务闭环，跑稳了再加定时调度。从 /goal 到 /loop，不要跨步。08）Loop 是放大器，放大你的经验，也放大你的疏忽。设计规则的人永远比执行规则的 AI 重要。工具升级到这个阶段，真正拉开差距的是你对运维的理解。哪些操作可以交给机器，哪些决策必须握在自己手里，这个判断力才是 Loop 时代的护城河。技术浪潮一波接一波，最后留下来的，是那些既会用新工具，又知道自己该在什么时候踩刹车的人。
