AI 可以取代运维了吗?

可以.

只有一个前提:

贵司不是采用"防御式运维"的策略.

📝声明:

古法匠心, 纯人工手工写作

本文 100% 由我手工写作而成

本文非 AI 生成

背景

AI + AI IDE/CLI 取代开发的趋势已经很明显了.

作为一个运维, 居安思危, 我自然开始认真🤔起来这个问题: AI 可以取代运维了吗?

为此, 我通过数个实战案例来交给 AI 实施, 包括: 运维常见的工作:

数据库迁移
应用升级
上线新服务
...

结果是我大大低估了 AI 的能力, 实际效果比我预期中最好的情况还要好.

我们来看看吧.

实战

实战一: LobeChat v1 升级到 v2

LobeChat 简介

LobeHub(v1 叫 LobeChat, v2 改名叫 LobeHub了)，这玩意儿简直就是为我们这种喜欢折腾的人量身定做的。说实话，用 ChatGPT 还得翻来覆去切换窗口，太麻烦了。但 LobeHub 不一样，它让你能组建自己的 AI 团队。

想象一下：你可以创建一个专门写代码的 Agent，一个负责文档整理的 Agent，还有一个帮你做数据分析的 Agent，它们还能互相协作！这感觉就像在玩《星际争霸》一样，只不过你的"单位"都是 AI。

最让我心动的是它的自托管能力。一条 Docker 命令就能搞定全套服务，数据完全掌握在自己手里。对于那些担心隐私问题的朋友来说，这简直是福音。

我主要用它的这些功能：各种助理(喷人的, 润色文章的, 解析国际局势的, 王阳明心学教学, 理财...), 还有RAG 文档资源管理能力。

如果你也厌倦了在各种 AI 工具之间来回切换，或者想要一个完全私有的 AI 工作空间，强烈建议试试 LobeHub。GitHub 上 74.4k 的星星不是白给的，社区活跃度也很高。

一句话总结： LobeHub 让你从"使用 AI"变成"管理 AI 团队"，而且完全私有化，数据自己说了算。

我的升级后的LobeChat v2 如下图:

我的部署方案

LobeChat v1 有 Docker Compose 部署方案, 我将其改写为了 K8s Manifests 并部署在我的 Homelab. 具体可以见我之前的配置: homelab2/apps/lobe-chat at 3855a4c141a4c9cd8c503d891be38a032766bb15 · east4ming/homelab2

V2 发生了哪些改变?

📚️参考文档:

Migrate from v1.x Local Database to ... · LobeHub

LobeChat v2 发生了巨大的改变, 这导致这次迁移的难度我都觉得很大😖:

pgsql 要从 16 升级到 17, 而且不是原生 pgsql, 而是从: pgvector 16 升级到 paradedb 17 😱
数据不能丢
LobeChat 的认证体系发生了巨变: 从 next auth 切换到了 better auth.
官方文档(上面的参考文档)就一页, 只是个描述性的文档, 而不是详细的一步到一步步骤文档. 而且这个文档不适用于我, 因为我不是 docker-compose 部署的...😑

AI 登场

🎉虽然有这么多困难, 但是确实在 AI 的帮助下坎坷但最终顺利完成了🎉🎉🎉

我使用的是 Claude Code, 模型是通过 API 对接的 DeepSeek(后面用了其他模型, 才知道 Deepseek 当前能力不算第一梯队的, 但就是这也完成的很好). 并且使用了[planning-with-files](OthmanAdi/planning-with-files: Claude Code skill implementing Manus-style persistent markdown planning --- the workflow pattern behind the $2B acquisition.) skill:

plaintext 复制代码

task_plan.md      → Track phases and progress
findings.md       → Store research and findings
progress.md       → Session log and test results

这里之所以要用planning-with-files skills. 是因为:

这是个非常有挑战性的运维 - 迁移任务, 需要消耗大量 Context
运维工作就是这样, 需要做好方案规划.
使用该 skills, 可以确保有需求, 有设计规划, 最重要的是: 迁移进度通过 tasks 实时追踪. 不会丢失上下文.

`planning-with-files`

AI 先规划了这3个文件:

完整的内容我就不贴了, 面得浪费各位读者时间. 感兴趣的可以点击👆的链接查看.

findings

Lobe Chat 从 v1 迁移至 v2 生产环境方案总结

核心目标
关键变更与要求
已完成的准备工作
技术决策与风险缓解
后续计划

progress

迁移项目总结报告

项目概述
关键步骤与成果
- 准备与评估 (Phase 1)
- 数据库升级 (Phase 2)
- 认证系统迁移 (Phase 3)
- 部署与验证 (Phase 4)
- 收尾与监控 (Phase 5)
最终状态

task_plan

任务概述
关键进展与完成状态
核心决策与注意事项
环境信息
- 生产域名：west-beta.ts.net
- 网络配置：Tailscale Ingress 与 ExternalServices
- 用户邮箱
总结

小结一下, 客观来说, 写的比我好多了(不然我也不可能现在还是个运维😂), 考虑也非常周全.

实施

实施过程就像上面规划的文档一样, 一步一步走.

这里我取巧了, 先手动关了 argocd 的自动同步功能. 然后让 AI 修改 k8s manifests, 修改完之后直接 kubectl 命令部署或执行 pgsql 迁移命令.

不过最终确实顺利完成了. 🎉🎉🎉

并且还生成了更多的相关文档:

说实话, 1, 4, 5 我也能想到, 但是 "用户反馈收集" 和 "用户迁移通知" 属实是我想不到的环节😂.

👍️AI 优点

AI 可以完成 90% 的工作 (剩下 10% 需要在我的介入下完成. 我认为原因不在 AI, 而是我的 GitOps repo 缺少某方面的可见性, 导致 AI 不了解那些方面的内容, 从而导致误判. 后面更详细说明)
AI 做了非常详尽的规划
AI 在迁移前, 中, 后一直保持着文档的实时更新(我自问我最多只能保证一份excel todo 清单的实时更新)

👎缺点

虽然我的部署信息基本全在 git 上了, 但是还是存在一些漏网之鱼, 着导致 AI 可能缺乏实际生产环境的一些关键信息(如: 数据备份机制, secret, PV 内数据等) (这是我的问题)
规划的很好文档中一直强调数据很重要, 但是执行过程中还是会随意使用 rm, delete, drop 等命令. 所以权限一定要严格把控
这是目前AI 最大的问题- 它会欺瞒. AI 对于没有成功的步骤, 有时会假装没看到, 继续执行后续步骤, 文档也会标记为✔️已完成. (比如我的数据库 dump 恢复失败了, 它就直接跳过并标记完成了 😂😂😂)
AI 的 128K 上下文多次用完, 可能导致关键信息丢失. 所以一定要跟 AI 说边实施边做记录.

🫣详细记录在这里:

Merge pull request 'feat(lobe-chat): 实现v2迁移准备工作' (#312) from lobehub-... · east4ming/homelab2@ba0d16c

总结

AI 花了一整天, 6块5毛钱. 就成功地完成了这次任务.

实战二: 上线新服务 - 在线文档网站

相比上面任务, 这次任务相对简单点. AI 完成的也更出色. 100% 完成, 0 人工介入!

任务概述

这是我在公司的项目, 我在公司有个 gitops-monitor repo. 里边就是我负责的运维的全部内容. 我想基于该 repo 生成一个使用 mkdocs, 基于我的 repo 里的 markdown 文档, 中英双语的在线文档网站.

这次改为使用公司配发的 Kiro IDE

AI 登场

Kiro Specs

Kiro Specs 先生成了 3 份文档:

Requirements -> Design -> Tasks

Requirements: 相当于业务/领导提出需求, 你给出的细化;
Design: 相当于你的迁移方案;
Tasks: 相当于实际迁移时的 Excel 任务清单.

Requirements

需求文档内容:

简介
术语表
需求
- MkDocs 项目配置
- 中英文双语支持
- Git 分支管理
- Kubernetes 部署清单
- AWS ALB Ingress 配置
- MkDocs 静态文件和部署流程

这里可以看到, 它将我模糊的描述细化为具体的明确的需求. 并且每个需求都有: 用户故事和验收标准.👍️

Degign

技术设计文档

概述
架构(这里 AI 画了个流程图👍️)
组件设计
- MkDocs 配置 - mkdocs.yml
- Kubernetes 部署清单 - 计划编写个 mkdocs helm chart (包括: deploy, PVC, ConfigMap, Service, Ingress)
- ArgoCD 自动发现(AI 分析后发现 ArgoCD 是自动发现的, ArgoCD 这块无需额外配置)
- 构建与部署
- i18n 双语实现
- Git 分支策略(feature 开发, 通过 PR 合并到 main 分支部署)
实现任务

Tasks

实施计划

概述
任务清单(列了7个大项任务和更多的小任务, 并标明任务间的相互依赖, 并在完成后实时更新该文档 - - [x])
备注

实施

写代码阶段反而不用详述, 这是 AI 的强项. 它写了:

mkdocs.yml
helm chart

出色地, 0人工干预地完成了任务. 🎉🎉🎉

👍️优点

AI 可以完成 100% 的工作, 0 人工介入
AI 做了非常详尽的规划
AI 在迁移前, 中, 后一直保持着文档的实时更新

👎缺点

总结