首页 > 基础资料 博客日记
AI 可以取代运维了吗?
2026-04-01 17:00:03基础资料围观1次
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 发生了哪些改变?
📚️参考文档:
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:
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
- homelab2/apps/lobe-chat/docs/migration/v2/progress.md at master · east4ming/homelab2
- homelab2/apps/lobe-chat/docs/migration/v2/task_plan.md at master · east4ming/homelab2
完整的内容我就不贴了, 面得浪费各位读者时间. 感兴趣的可以点击👆的链接查看.
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
- homelab2/apps/lobe-chat/docs/migration/v2/用户反馈收集模板.md at master · east4ming/homelab2
- homelab2/apps/lobe-chat/docs/migration/v2/用户迁移通知模板.md at master · east4ming/homelab2
- homelab2/apps/lobe-chat/docs/migration/v2/紧急回滚计划.md at master · east4ming/homelab2
- homelab2/apps/lobe-chat/docs/migration/v2/迁移总结报告.md at master · east4ming/homelab2
说实话, 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 部署清单 - 计划编写个
mkdocshelm chart (包括: deploy, PVC, ConfigMap, Service, Ingress) - ArgoCD 自动发现(AI 分析后发现 ArgoCD 是自动发现的, ArgoCD 这块无需额外配置)
- 构建与部署
- i18n 双语实现
- Git 分支策略(
feature开发, 通过 PR 合并到main分支部署)
- MkDocs 配置 -
- 实现任务
Tasks
实施计划
- 概述
- 任务清单(列了7个大项任务和更多的小任务, 并标明任务间的相互依赖, 并在完成后实时更新该文档 -
- [x]) - 备注
实施
写代码阶段反而不用详述, 这是 AI 的强项. 它写了:
mkdocs.yml- helm chart
出色地, 0人工干预地完成了任务. 🎉🎉🎉
👍️优点
- AI 可以完成 100% 的工作, 0 人工介入
- AI 做了非常详尽的规划
- AI 在迁移前, 中, 后一直保持着文档的实时更新
👎缺点
- 无
总结
这次的任务更简单, repo 上信息完整, 用的 模型也更强. AI 完美地👐完成了任务. 毫无缺点.
回答问题
问: AI 可以取代运维了吗?
答: 可以. (不是部分可以, 而是完全可以, 100% 可以.)
只有一个前提:
贵司不是采用"防御式运维"的策略.
"防御式运维" 指的是啥?
任何运维的反模式:
- 运维代码不可见(你的运维代码不可见, 不在 git repo, 没有CMDB, 没有变更记录)
- 配置漂移(你的运维信息可见, 但是和实际生产环境相比不准)
- 孤岛(你的运维是个孤岛. 是个遗留系统. 是上个时代产物. 是老古董. 是诡异而奇怪的存在.)
- 架构混乱(你的运维没有架构, 没有设计良好的架构, 没有稳定刚性且不可变的架构, 没有健壮的架构)
- 非结构化
- 非标准化(只能 UI 点, 没有标准 API 接口)
- 不可被观察
- 纯手工工匠精神. 没有自动化, 没有使用 IaC 或 GitOps, 甚至没有 ansible 类的配置管理工具.
- 没有运维信息真实来源
- 环境不一致(开发, 测试, uat, 性能和生产不一致)
- 没有版本控制
- 运维信息不可读, 无法理解
- ...
总结
我相信, 通过👆上面的两个案例. 我们已经可以清楚地知道这样一个答案: AI 可以取代运维.
- 对于复杂的迁移工作. AI 花了一天时间, 6.5元就完成了工作.
- 对于相对难度中等的新服务上线. AI 100% 圆满地完成了工作, 0人工介入
- 一个 Coding Plan 月度订阅费大概在 20💵, 就可以替换掉一个(公司人力成本上万)的运维同僚
- AI 文档写的更好
- AI 状态更新更及时
- AI 考虑的更全面
- AI 向上管理汇报也更漂亮
- ...
最后, 放一张囧图活跃下气氛~

尽管如此, 我们运维也不需要焦虑担忧,
我想到刘禹锡那句“沉舟侧畔千帆过,病树前头万木春”。
技术迭代从来不是淘汰,而是生态的焕新。AI 像那千帆、像那万木,它替代的只是重复的“操作”,却永远替代不了运维人在无数深夜故障中修炼出的系统直觉、在业务与技术的夹缝中长出的架构智慧,以及面对未知风险时那份“敢重启、敢背锅”🤨的责任担当。
换个角度看,你过去所积累的故障库、你亲手画过的拓扑图、你在告警洪流中瞬间定位根因的“第六感”——这些都不是数据能完全复刻的经验资产。AI 终将是你的“超级协作者”,把琐碎交出去,让你更专注于创造与决策。
所以,不妨用另一句诗自勉:“天生我材必有用,千金散尽还复来。”
你的“材”从来不只是命令与脚本,而是你在复杂系统里游刃有余的掌控力,是你在技术与人情之间搭建桥梁的软实力。这些,AI 学不会,也拿不走。
运维人的价值,不在工具里,而在每一次化险为夷的镇定里。
与君共勉.
EOF
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!
标签:
相关文章
最新发布
- 关于列式存储(Column-base Storage)的几个要点解读
- 同样都是九年义务教育,他知道的AI算力科普好像比我多耶
- Slickflow 与 OpenClaw 结合实践:技术原理、集成方式与 Skill 说明
- 如何使用 UEFI Shell 执行 Hello World 程序
- Agent构建:声明式优于硬编码
- AI 可以取代运维了吗?
- 测试人必备的4个AI Skills(附下载地址和详细用法)
- 记一次Webshell流量分析2 | 添柴不加火
- 直击政企AI落地“深水区”,华为混合云推出OpenClaw本地部署方案
- FastAPI里玩转Redis和数据库的正确姿势,别让异步任务把你坑哭了!

