云原生运维与传统自动化运维：本质不是工具，是控制权在谁手里

“你们用 Kubernetes 了吗？”

“用了，我们所有服务都容器化了，用 Helm 管理部署。”

“那你们的 Operator 或者 Controller 写了多少？”

“……那个还没有。”

这段对话在很多团队里都发生过。工具换了，但运维的思路没换。这是传统自动化运维和云原生运维之间最根本的裂缝——不在技术栈层面，在控制权模型层面。

---

传统自动化运维的本质：人是最终控制器

传统自动化运维的核心是把人做的事情脚本化。Ansible 的 playbook 是让机器代替人执行一系列步骤，Puppet 是把配置管理的规则编码下来让机器自动应用。但无论哪种形式，人依然是控制环路里的核心节点。

系统出了问题 → 触发告警 → 运维人员响应 → 执行脚本 → 恢复服务。这个循环里，人负责感知、判断和触发，自动化工具只是执行器。

这个模型有内在的合理性：基础设施是相对固定的，机器不会随机消失，网络基本可靠，服务一旦部署就应该持续运行。自动化的目标是减少人的重复劳动，不是替代人的决策。

---

云原生运维的本质：系统是自己的控制器

云原生改变了这个模型的核心假设。

Kubernetes 里的每一个 Controller，都是一个独立运行的控制循环：它持续观察集群中某类资源的实际状态，将其与用户声明的期望状态对比，发现偏差就自动修正。没有人在等待告警，没有人在触发脚本。这个循环 24 小时不间断运行。

// 简化的 Controller 逻辑
for {
    actual := getActualState()
    desired := getDesiredState()
    if actual != desired {
        reconcile(actual, desired)
    }
    sleep(interval)
}

人只需要声明意图，不需要描述过程。 你说”我要 3 个副本”，而不是”先启动第一个副本，检查健康状态，再启动第二个……”。过程是系统的责任，不是你的。

当一个 Pod 因为节点故障消失时，没有人被呼叫，没有脚本被触发。ReplicaSet Controller 在下一次观察周期里发现副本数从 3 变成了 2，然后直接创建新的 Pod。故障在人感知之前已经被修复了。

---

两个导致混淆的假象

假象一：用了容器就是云原生运维。

把应用装进 Docker，用 Ansible 把容器推到服务器上跑，监控脚本检查进程是否存活，挂了就 restart。这是传统自动化运维加了一层容器外壳，控制模型没有任何变化。

假象二：工具换了就行了。

用 kubectl 的方式和用 ssh 一样，每次变更都是命令式操作；Helm chart 只是打包工具，没有任何控制逻辑；告警触发之后还是靠人工响应 runbook。这种情况下，Kubernetes 只是一个更复杂的服务器，复杂度增加了，收益没有。

---

真正的迁移代价

从传统自动化运维切换到云原生运维，最难的部分不是学 Kubernetes API，是重新分配人和系统之间的职责边界。

在传统模式里，运维工程师是执行者，他们拥有对系统状态的直接控制权。在云原生模式里，运维工程师更接近系统的架构师：设计控制循环，定义期望状态的表达方式，决定系统在什么情况下做什么。他们不再直接操作系统，而是编写系统自己操作自己的规则。

这个转变对团队能力的要求是不同的。会写 Ansible playbook 的工程师，不一定会设计 Operator。会看 Pod 日志，不代表能从 metrics 里判断控制循环的健康状态。

---

不是说传统自动化运维更差。对于基础设施固定、团队规模小、故障频率低的场景，它反而更直接、更容易 debug。云原生运维在提升系统自愈能力的同时，带来了更高的抽象层和更复杂的调试路径。

选择哪种模型，取决于你的系统失败的频率和成本，以及团队能承受的认知复杂度上限。把 K8s 当 Ansible 用，是最坏的结果——两套东西的复杂度都扛着，两套东西的好处都没拿到。