AI 可以取代运维了吗?

东风微鸣

发布于 2026-04-02 15:10:23

1230

文章被收录于专栏：东风微鸣技术博客东风微鸣技术博客

字数 3344，阅读大约需 17 分钟

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 v2

我的部署方案

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

V2 发生了哪些改变?

📚️参考文档: Migrate from v1.x Local Database to ... · LobeHub[2]

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

1. pgsql 要从 16 升级到 17, 而且不是原生 pgsql, 而是从: pgvector 16 升级到 paradedb 17 😱
2. 数据不能丢
3. LobeChat 的认证体系发生了巨变: 从 next auth 切换到了 better auth.
4. 官方文档(上面的参考文档)就一页, 只是个描述性的文档, 而不是详细的一步到一步步骤文档. 而且这个文档不适用于我, 因为我不是 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.[3]) skill:

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个文件:

• homelab2/apps/lobe-chat/docs/migration/v2/findings.md at master · east4ming/homelab2[4]
• homelab2/apps/lobe-chat/docs/migration/v2/progress.md at master · east4ming/homelab2[5]
• homelab2/apps/lobe-chat/docs/migration/v2/task_plan.md at master · east4ming/homelab2[6]

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

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 迁移命令.

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

总结报告

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

• homelab2/apps/lobe-chat/docs/migration/v2/生产环境监控检查清单.md at master · east4ming/homelab2[7]
• homelab2/apps/lobe-chat/docs/migration/v2/用户反馈收集模板.md at master · east4ming/homelab2[8]
• homelab2/apps/lobe-chat/docs/migration/v2/用户迁移通知模板.md at master · east4ming/homelab2[9]
• homelab2/apps/lobe-chat/docs/migration/v2/紧急回滚计划.md at master · east4ming/homelab2[10]
• homelab2/apps/lobe-chat/docs/migration/v2/迁移总结报告.md at master · east4ming/homelab2[11]

说实话, 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[12]

Migration PR

总结

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 在迁移前, 中, 后一直保持着文档的实时更新

👎缺点

• 无

总结