前言 2026年，AI运维（AIOps）是个热词。大模型能写代码、能分析日志、能做决策。很多人问我：ServerGuard为什么不用AI？
今天不绕弯子，直接回答：我用过，然后我放弃了。
先说一个真实的反面案例 去年我尝试把GPT接进告警处理流程。思路很直接：告警触发时，把系统指标、日志、进程列表打包发给模型，让它判断“该不该自动修复”。
第一周，效果很好。
磁盘告警，模型说“清理/tmp目录下的临时文件”——正确。 内存告警，模型说“重启占用内存最高的PHP进程”——正确。 服务告警，模型说“检查端口占用并重新启动”——正确。
第二周，出问题了。
一次磁盘告警，模型说：“检测到/var/log目录下有大型日志文件，建议清理。”我信任了它，直接执行。
结果删掉了正在写入的MySQL binlog。 从库同步断了，花了两个小时才恢复。
我问模型为什么删这个文件，它说：“该文件大小超过1GB，且最后修改时间超过7天，符合清理条件。”
但MySQL binlog不能被清理——它正在被从库实时读取。 这个约束，模型不知道。
核心问题：不可解释 AI做决策最大的问题不是“会不会错”，而是“错了你不知道为什么”。
如果系统自动杀了一个进程，你问它为什么，它说“我判断它可能有问题”——这个答案在运维场景下是不可接受的。
运维需要的是：每一步操作都能追溯到具体的判断条件。 出了问题，你能复盘，能改规则，能防止下次再犯。
确定性规则可以做到。大模型做不到。
ServerGuard的做法 确定性统计 + 规则引擎。每一个决策都能追溯到具体的代码行。
磁盘清理： 只清30天以上的.gz/.1/.old文件，排除正在被进程持有的文件，排除数据库目录、配置目录、网站源码目录、会话文件目录。6层安全检查，每一层都有明确的代码逻辑。
内存管理： 检测到进程内存1小时增长超过30%，触发重启。重启前拍快照，重启后观察60秒。白名单进程不杀。
告警收敛： 同一条告警10分钟内重复3次自动静默，同一个IP 5分钟内的多种攻击合并成一条。滑动窗口计数，逻辑不到80行。
这些规则不“智能”，但可解释、可预测、可回滚。
那AI用在哪了 不是完全不用。ServerGuard在根因分析里用了启发式规则——不是大模型，是if-else。
比如磁盘告警触发时，它会自动扫描空间占用TOP3目录，附在告警后面。这个“扫描+排序+展示”的逻辑是确定性的，不是AI猜的。
用AI做辅助分析可以，用AI做决策不行。
总结 自动运维的核心矛盾不是“够不够智能”，是“错了怎么办”。
大模型解决不了“可解释性”问题。确定性规则 + 多层安全阀，才是可落地的工程方案。
项目地址：
GitHub：suoten/ServerGuard
Gitee：suoten/ServerGuard
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70050062/viewspace-3183905/ ，如需转载，请注明出处，否则将追究法律责任。
