# 把运维干掉不是开玩笑，用AI试了试4小时搞定3天活

LLMS 索引： [llms.txt](/llms.txt)

---

> 原作者：陈明 · [微信公众号转载页](https://mp.weixin.qq.com/s/wLHHzRmu9sfgufukA8oexA)

**作为一名AI架构师，我没想到一次技术实践的分享，会在技术群里引发如此激烈的争论。从"把运维干掉"的激进主张，到AI工具能力的认知升级，这场讨论让我看到了一些被忽视的真相。**

### 39个存储卷4小时迁移完成，我在群里聊天AI在干活

今天下午，我完成了一个让自己都有些惊讶的任务。

我们运行在Kubernetes上的测试集群需要进行持久化存储迁移——从一个NFS存储迁移到另一个存储。这涉及39个PV（持久化卷），覆盖数据库、AI训练数据、监控系统等各种应用的重要数据。

这种迁移任务级联修改比较多，顺序也比较复杂。虽然本身技术复杂度不算太高，但非常耗时间和心力，传统运维通常需要2-3天才能完成。

这次我决定尝试使用AI编程的思路，让Claude Code来处理。**需要特别说明的是，这是在测试环境中进行的一次技术实验，并且我们已经做了异机全量数据备份，即使出现最坏情况也可以完全恢复**。

关键的是，**我只告诉了它目标，具体方案和执行都是它自主完成的**。整个4小时过程中，大部分时间Claude Code都在自主执行，期间我还在微信群里和朋友聊天，做其他事情，很少需要干预。

![图片](01.webp)

结果让我惊喜：4小时全部搞定。Claude Code不仅制定了分层修复策略，还在过程中帮我发现了NFS存储服务器的配置问题，待我解决后，顺利完成了全部迁移。

![图片](02.webp)

心情不错的我在技术群里分享了这个成果：

> "我今天让CC干运维，做nfs存储迁移，干的挺好"

没想到这条简单的消息却点燃了一场大讨论的导火索。

------------------------------------------------------------------------

### 一句话点燃技术群："把运维干掉就好了"

我的消息刚发出去，马工立即抛出了一个惊人观点：

> **"把运维干掉就好了，运维是自动化的敌人，不是盟友，更不是客户"**

这句话就像一颗炸弹，瞬间点燃了群里的讨论。争论围绕三个核心问题展开：

#### 运维是否还有存在价值？

**马工的激进主张：** 彻底废除专门的运维团队。

> "不要有专门的运维组，谁开发的，谁维护，开发组自己on call。我五月份入职，八月份就完成了CI/CD，为什么这么快？因为我们没有运维"

**Nemo的专业分工论：** 术业有专攻，提效而非阻碍。

> "我们运维做了helm模板，核心是把开发人员的学习成本省下来，仅需要做一次工作就行了"

**Player的风险控制观：** 专业能力不可替代。

> "不能说AI能干就压给一个人头上干，服务指标、中间件状态管理，这些是运维的事情"

#### 技术工具是否过度复杂？

争论的焦点集中在Kubernetes上。马工直言不讳：

> **"kubernetes垃圾，一个工具不降低问题的数量，反而引入更多问题，这个工具应该打零分"**

但实际使用者的体验截然不同。我的观点是：

> **"k8s只要懂五六个基本概念也就够了，至少不用去ui上点点点"**

Nick的经验更具参考性：

> **"我们用了阿里云的托管k8s，不维护k8s本身，我们只用"**

#### 成本与效率如何平衡？

这个问题没有标准答案，需要结合具体情况。我的观点比较务实：

> **"小公司要省运维团队的钱，就是all in一朵云"**\
> **"cc不仅能写代码，干运维也是ok的。只要给他标准化接口"**

------------------------------------------------------------------------

### 三个发现：AI不只是写代码，还能重新定义工作

争论看似激烈，但背后反映的是更深层的认知差异。我总结了三个关键发现：

#### AI接管重复工作，人类专注高价值决策

我的AI迁移实践证明了一个重要趋势：AI真正改变的不是某项具体能力的强弱对比，而是工作本质的重新定义。

传统运维工程师需要花费大量时间在信息收集、状态分析、命令执行这些基础工作上。这些工作虽然重要，但本质上是重复性的模式识别和标准化操作。AI恰恰擅长的就是这类工作。

但这并不意味着运维工作没有价值了。恰恰相反，当AI承担了这些基础工作后，真正有价值的工作浮现出来了：业务理解、风险判断、架构设计、创新思维。

#### 小团队vs大公司：成功模式背后的适用条件

马工3个月完成CI/CD建设的成功，有其特定条件：小团队、扁平组织、决策链条短。而Nemo坚持专业分工的团队，往往面对更大规模、更复杂的业务需求。

不同规模的公司，最优策略确实不同：

- 小公司：成本敏感，AI + 云服务组合最具性价比
- 中型公司：需要平衡效率和风险，混合模式更合适
- 大型公司：业务复杂，专业化分工仍然必要

#### 最关键的不是AI干了什么，而是我决策了什么

在我的迁移过程中，最关键的不是AI执行了多少操作，而是我做出了哪些关键决策：选择在测试环境进行、确保有完整备份、实时监控执行结果。这些决策背后是对业务需求、技术风险、时间约束的综合判断。

这让我看到了一个新的协作模式：AI负责信息处理和方案生成，人负责目标设定和风险控制。这种分工不是基于能力的强弱，而是基于责任的承担。

------------------------------------------------------------------------

### 四个洞察，运维和开发都该看看

通过这场争论，我提炼出几个被大多数人忽视的洞察：

#### 很多人不知道：AI会写脚本、调API、执行命令

**这是很多人的认知盲区**：大家以为AI编程工具只能写代码，实际上它可以自主执行复杂的任务——写脚本、执行命令、调用API、分析结果。

我的迁移案例证明了这一点：Claude Code从系统分析到方案制定，从脚本执行到结果验证，完全自主完成了整个运维流程。这远超大多数人对"AI写代码"的认知。

**对运维的启发**：不要低估AI工具的能力，但也要明确人类的不可替代价值——业务理解、风险判断、架构设计。**对研发的启发**：学会与AI工具深度协作，不只是让它写函数，而是让它承担更多系统性工作。

#### 马工的犀利观点：让问题变多的工具都是垃圾

马工的犀利观点揭示了一个重要原则：

> **"一个工具不降低问题的数量，反而引入更多问题，这个工具应该打零分"**

这个判断标准比技术先进性更实用。K8s很强大，但如果增加了系统复杂度，对小团队可能就是负担。Docker Compose很简单，但如果解决不了滚动升级，对业务就是风险。

**关键问题**：这个技术选择是让问题变少了，还是变多了？

#### 别盲目复制成功案例，先看看适用条件

这次争论最大的收获是：每个成功模式都有其隐藏的适用条件。

马工的"无运维"模式成功，前提是小团队、扁平组织、技术栈相对标准化。Nemo的专业分工模式有效，基础是业务复杂度高、团队规模适中、有标准化投入。

**启发**：不要盲目复制成功案例，要分析其背后的适用条件。

#### 真正的成本计算：不只是工资，还有学习和沟通成本

群里基本达成共识：小公司"All in一朵云"最经济。但很多人只看到表面成本，忽略了隐藏成本。

真正的成本不只是人员工资，还包括学习成本、沟通成本、风险成本、机会成本。云服务贵，但它把复杂度转移给了专业团队；AI工具贵，但它大幅提升了个体效能。

**思考框架**：总拥有成本 vs 单项成本，长期效益 vs 短期开支。

------------------------------------------------------------------------

### 别学我瞎搞：测试环境+数据备份才敢这么玩

最后，必须提醒想要尝试类似AI辅助运维实验的读者：

**风险评估不可少**：生产环境的运维操作风险极高，必须充分评估可能的影响范围和后果。**备份是最后防线**：我这次敢于大胆尝试，关键在于测试环境+完整的异机数据备份。任何运维操作都应该先确保数据安全。**循序渐进很重要**：建议从简单、低风险的任务开始尝试AI辅助，逐步积累经验和信任。**人工监督不能省**：AI虽然强大，但关键决策点仍需人工确认，特别是涉及数据删除、配置变更的操作。

技术进步让我们有了新的可能性，但谨慎和负责任的态度永远不能丢。

**感谢参与讨论的技术同行们：马工、Nemo、Player、Better、Nick、伤感星星、WenJie、linhow等，你们的观点和思考为这篇文章提供了宝贵的素材。**

------------------------------------------------------------------------

**陈明，企业AI架构师，AI编程布道者。专注于AI技术在企业中的实际应用，相信技术要为业务价值服务。如果你也在思考类似的问题，欢迎交流讨论。**