我把服务器交给了 AI:一次零命令行的全托管运维实录 | Kto's Blog - Personal Blog

写在前面

我有一个个人博客,跑在三台低配云服务器上:一台做统一网关和数据库,一台跑博客本体和缓存,一台放私有 Git 和镜像仓库。机器不多,但麻雀虽小五脏俱全——域名解析、反向代理、跨机数据库、认证服务、定时任务,一样不少。

我面临一个尴尬的现实:我不想敲命令。不是不会,而是每次登录服务器排查问题、改配置、重启服务,都要回忆一遍上下文,生怕敲错一行。于是服务器慢慢变成了"能跑就不动"的状态:构建挂了半个月没人发现,新功能写在分支里躺着,明文密码在面板脚本里睡大觉。

直到我换了一种方式:把服务器交给 AI Agent,我只负责告诉它"要什么"和"拍板"。

这篇文章记录了真实的一天。这一天里,我没有敲过任何一行服务器命令。

我给了 AI 什么

交给 AI 的东西出奇地少,总共三样:

1. 一份运维档案仓库。 这是一个私有 Git 仓库,里面记录了每台机器的连接方式、SSH 密钥的位置、服务依赖关系图、历史事件(比如去年的一次安全事件复盘)。这份档案是过去踩坑攒下的,它相当于服务器的"病历本"。

2. 一个已登录的 GitHub CLI。 代码仓库在 GitHub 上,本地终端里 gh 命令可用,AI 可以直接查 PR、看构建记录、合并分支。

3. 一句话需求。 "你看看这些分支是怎么回事,服务好像在服务器上跑着。"

就这些。没有操作手册,没有命令清单,没有我手把手的指导。

AI 这一天做了什么

上午:诊断与修复

AI 先做的事情是搞清楚现状,而不是急着动手:

它梳理了本地和远程的分支关系,发现一个开了快三个月的功能分支一直没合并;
顺着部署链路查下去,发现这个分支从未被 CI 构建过——因为构建流水线只在主开发分支上触发,所以里面藏着的 TypeScript 类型错误无人知晓;
更有意思的是,它读完了那个功能分支的全部代码,发现两个"代码在但永远不会跑"的缺陷:数据库表缺迁移文件,以及定时任务调度器从来没有任何地方启动它。也就是说,如果直接合并上线,新功能会安静地失效,只有日志里每隔几分钟一条报错。

这些问题没有一个是"崩给你看"的,全都是静默的。这正是人工运维最容易漏掉的类型——你不主动去看,它们就不存在。

修复过程它做得比我预期的谨慎:类型错误逐个修掉、用离线方式生成数据库迁移(不碰生产库)、给调度器补上启动接线、顺手修了一个 cron 语义 bug(每周执行的任务实际会每天执行)。

中午:建立防线

修完不算完。它指出这个仓库一个测试都没有,然后:

引入了测试框架,给核心逻辑(定时任务表达式解析、监控数据持久化)写了二十个用例;
有个用例第一次跑就抓住了上面那个 cron bug——测试是真的在保护代码,不是摆设;
在 CI 里加了质量门禁:lint、类型检查、测试全过,才允许构建镜像。

从这以后,"合并即挂构建"这种事在这个仓库里绝迹了。

下午:全自动部署

原有的发布方式是:凌晨两点半定时任务拉一下新镜像——但只拉不重启,真正上线要手动重建容器。AI 把最后这一环补上了:

把博客容器迁移到声明式的 compose 管理,配置逐项对齐,站点无感切换;
写了一个部署脚本:拉取新镜像 → 重建容器 → 深度健康检查(不只看页面 200,还探测数据库和缓存连通性)→ 失败自动回退到稳定版镜像,并发邮件告警;
CI 构建完镜像后,通过一把"受限 SSH 密钥"远程触发部署——这把密钥被配置成只能执行部署脚本这一件事,就算泄露也做不了别的。

最后实测:合并一个 PR,九分钟后新版本自动上线,其中部署环节只花十几秒;它还真的把回退路径也演练了一遍——切到备胎镜像、确认服务健康、再切回来。

傍晚:安全加固

收尾时它主动指出几个隐患并处理:

面板的定时任务脚本里有明文密码,其中一个是弱口令——全部清理,凭证改为系统级持久化登录;
顺手把镜像仓库的密码轮换成强随机值,GitHub 密钥、服务器登录三处同步更新,并跑了一次完整发布验证轮换没有断链;
所有临时密钥文件用完即删。

关键设计:怎么把 AI"关进笼子"

把服务器交给 AI,最大的顾虑不是它能力不够,而是权限失控。这一天的实践里,几个设计让我很安心:

受限密钥。 自动化用的 SSH 密钥通过 forced-command 限制成"只能执行那一个部署脚本"。AI 触发部署时无论执行什么命令,服务器都只跑部署。权限的口子开得越小,AI 越可以放心用。

凭证不经过 AI 的"手"。 密码轮换时,新密码在一条命令的内存里流转,分别写入镜像仓库的认证文件、GitHub 加密 secret、服务器登录凭证,全程不落到屏幕、不进对话记录。AI 用完即弃,事后连它自己都不知道密码是什么。

兜底优先于激进。 每次改动前先备份(容器配置、面板数据库),每次上线都有回退路径,自动化最坏的情况是"退回稳定版并发告警",而不是"把网站搞挂"。

文档先行。 所有架构事实被沉淀成一份速查文档,下次会话 AI 没有上下文也能快速恢复认知——这其实是我作为"管理者"最重要的投资。

人的角色变了

这一天我的角色大概是这样:

描述需求("我想合并这个分支"、"部署能不能自动化");
拍板方案(比如"生产镜像要不要也自动部署"这种取舍);
收邮件(部署成功的通知里带着提交说明和构建链接,扫一眼就知道上了什么)。

我没有写一行代码,没有敲一行命令,但我比以前任何时候都更清楚我的系统在怎么运转——因为 AI 把每一步"为什么这么做"都讲给我听了。

运维从"操作技能"变成了"决策与验收"。 这可能是 AI 时代普通开发者管理自己基础设施的正确姿势:你不需要记得每条命令,你需要的是判断力——知道什么该做、什么不该做、出事了信谁。

如果你想试试

准备清单其实很短:

一份运维档案:连接方式、密钥位置、架构和依赖关系,写在私有仓库里(这是最有价值的一步,哪怕不用 AI 也值得做);
受限的自动化入口:forced-command 密钥、只读优先、能用 API 的地方给 API(比如 GitHub CLI);
回退兜底:稳定版镜像常备服务器,任何自动化失败都能退回来;
告警通道:邮件或推送,让 AI 做的事"看得见"。

然后,把你的服务器,也交给 AI 试一天。

结语

写下这篇文章的时候,博客的新版本正是 AI 在半小时前自动部署上线的——通知邮件安静地躺在收件箱里,写着提交说明和健康检查结果。

三台服务器还在原地,但我再也不是那个"能跑就不敢动"的人了。