摘要：凌晨三点被告警叫醒，清日志、重启服务、Kill 进程——这些重复了无数遍的操作，能不能让 AI 自动干了？本文分享我们开源项目 VigilOps 的 AI 自动修复模块从设计到落地的实战经验，包括踩过的坑和安全机制设计。目前支持 6 个自动修复场景，dry_run 观察期中。
我给运维告警接了个 AI 大脑，它现在能自己修服务器了
先说结论
我们做了一个开源的 AI 运维平台 VigilOps，最近上线了自动修复模块——收到告警后，AI 自动诊断根因、匹配修复方案、执行修复。
目前支持 6 个场景：磁盘清理、日志轮转、服务重启、僵尸进程清理、内存压力处理、连接重置。
重要说明：模块刚开发完，正在 dry_run 观察期，还没有真实运营数据。下面聊的是设计思路和踩过的坑，不是吹效果。
为什么要做这个
做运维的都懂——不怕复杂故障，怕的是简单问题反复叫你。
凌晨三点被叫醒清日志，这事一个月来三次，每次操作一模一样。你写了脚本，但脚本需要人触发。配了 cron，但 cron 不知道什么时候该跑。
自动化做了 90%，最后 10% 还是人在跑。偏偏那 10% 在凌晨三点。
2025 年 DeepSeek 等大模型已经能理解上下文、做判断了。我们就想：能不能在监控和脚本之间加个 AI，让它来判断"现在该跑哪个脚本"？
整体架构
一句话：监控出告警 → AI 分析根因 → 匹配 Runbook → 自动执行 → 验证恢复。
内置告警引擎 → Agent 编排器 → DeepSeek 诊断 → Runbook 匹配 → 执行修复 → 验证
↓ 失败
升级人工介入
核心模块就四个文件：
agent.py：编排器，串整个流程ai_client.py：调 DeepSeek API 做诊断runbook_registry.py：6 个 Runbook 的注册和匹配command_executor.py：执行命令，默认 dry_run
踩过的坑
坑 1：大模型幻觉导致误操作
早期测试时 DeepSeek 会"编"根因——明明是日志撑爆磁盘，它诊断成"数据库锁竞争"，然后建议重启数据库。
解法：Runbook 白名单制。不管 DeepSeek 建议什么，最终只能执行已注册的 6 个 Runbook。大模型的角色是"建议"，不是"命令"。
def match(self, alert, diagnosis):
# AI 建议优先，但必须是已注册的 runbook
if diagnosis.suggested_runbook:
runbook = self._runbooks.get(diagnosis.suggested_runbook)
if runbook:
return runbook
# AI 建议了一个不存在的 runbook？忽略，走规则匹配
logger.warning("AI suggested unknown runbook: %s",
diagnosis.suggested_runbook)
# 退化到告警类型匹配 → 关键词匹配
...
教训：永远不要让大模型直接控制执行层。中间必须有一道"翻译 + 校验"。
坑 2：自动修复变成自动破坏
想象一下：AI 判断某个进程占内存太多，Kill 了它——结果那是数据库主进程。
解法：四道安全防线。
- 禁令列表：
rm -rf /、DROP DATABASE这种绝对禁止 - 白名单：只有 6 个 Runbook 里定义的命令可以执行
- 频率限流：同一台机器同一个 Runbook，N 分钟内不重复
- 熔断：连续失败达阈值，停止自动修复，通知人工
而且默认 dry_run——新部署不会真的执行任何命令，只记录"如果放开，我会做什么"。
class CommandExecutor:
def __init__(self, dry_run: bool = True): # 注意默认值
self.dry_run = dry_run
教训：自动化系统的默认状态应该是"不动"，而不是"动"。
坑 3：告警风暴下的连锁反应
一台机器挂了，瞬间来 20 条告警——CPU 高、内存高、服务不可用、连接超时...
如果每条告警都触发一个 Runbook，可能同时重启 5 个服务、清 3 次磁盘、Kill 一堆进程。
解法：限流 + 去重。同一台主机的告警在时间窗口内合并处理，同一个 Runbook 不重复触发。
六个 Runbook 详解
这是目前全部实际支持的场景，不多不少：
1. 磁盘清理 disk_cleanup
最高频场景。识别大文件/过期日志/临时文件 → 安全删除 → 验证空间释放。
2. 日志轮转 log_rotation
日志增长过快时自动调整轮转策略，压缩归档旧日志。
3. 服务重启 service_restart
服务异常时先查日志判断根因，简单问题（OOM等）自动重启，复杂问题标记给人。
4. 僵尸进程清理 zombie_killer
检测 Z 状态进程并清理，防止 PID 耗尽。
5. 内存压力处理 memory_pressure
内存告警时识别大内存进程，判断泄漏可能，必要时清缓存或重启服务。
6. 连接重置 connection_reset
连接数异常时清理问题连接。
没有的就是没有——比如 SSL 证书续签、数据库慢查询自动优化（如自动加索引、SQL 改写），这些在规划中但还没实现。不过数据库慢查询监控已经实现了——采集慢查询数量、Top 10 详情展示都有。我们不会把规划当功能写。
告警通知：推到你用的 IM
修复结果不会只躺在日志里。VigilOps 内置 5 种通知渠道：Webhook / 邮件（aiosmtplib）/ 钉钉 / 飞书 / 企业微信。告警、修复结果、升级通知——直接推到你团队日常用的沟通工具，不用盯监控面板。
一个完整的告警处理流程
以最常见的磁盘告警为例：
1. VigilOps Agent 检测到 /var/log 磁盘使用率 > 85%
2. 内置告警引擎触发告警
3. Agent 采集上下文：磁盘各目录大小、最近写入频率、历史处理记录
4. DeepSeek 分析："Nginx 访问日志 3 天未轮转，占用 12GB，建议执行 disk_cleanup"
5. RunbookRegistry.match() → 命中 disk_cleanup
6. 安全检查通过（白名单✓、限流✓、熔断✓）
7. 执行清理：删除 7 天前的压缩日志，清理 /tmp
8. 验证：磁盘使用率降到 62%
9. 写入 remediation_logs，通知运维
整个过程不需要人参与。但如果任何一步失败——安全检查不通过、清理后空间没释放、AI 诊断不确定——都会升级给人工。
部署体验
Docker Compose 一键拉起：
git clone https://github.com/LinChuang2008/vigilops.git
cd vigilops
cp .env.example .env # 填入 DeepSeek API Key
docker compose up -d
技术栈：FastAPI + React + PostgreSQL + Redis + DeepSeek API。面向中小团队（管理 5-50 台服务器的运维/SRE 团队），没有奇怪的依赖，标准 Python 项目。
当前状态和规划
坦诚说：
- ✅ 代码开发完成，6 个 Runbook 可用
- ✅ 安全机制完整（禁令 + 白名单 + 限流 + 熔断 + dry_run）
- 🔄 目前处于 dry_run 观察期，还没有在生产环境真正执行过自动修复
- 🎯 设计目标是覆盖 70% 的常见运维告警，但这需要实际验证
规划中（尚未实现）：
- 更多 Runbook：SSL 证书续签、容器编排异常等
- 从人工处理记录中自动学习生成新 Runbook
最后
AI 运维不是要替代运维工程师。它处理的是你做过十几遍、闭着眼都能做、但每次还得亲自来的事。
你做架构优化，它做告警值班。分工，不是替代。
如果你也在被凌晨三点的告警折磨，或者在探索 AI 运维自动化，欢迎来看看代码、提 Issue、一起讨论。
🔗 GitHub: github.com/LinChuang20… ⭐
你们团队现在的告警处理流程是什么样的？有没有试过自动化修复？欢迎在评论区聊聊。
作者：VigilOps 团队
