运维历史演进与 K8S 之后趋势

背景

过去三十多年，服务器运维其实一直在做一件事：让人越来越少地去“手动管机器”。

早期的运维非常原始。服务器买回来要自己上架、装系统、配置网络、改配置文件。机器出了问题，就 SSH 登录上去排查，很多时候靠的是经验和记忆。那时候的运维，本质上就是“人盯机器”。

但当服务器数量越来越多，这种方式很快就撑不住了。
问题主要有两个：重复劳动和配置混乱。

重复劳动很好理解，比如同一个服务要部署到几十台机器，每次都要手动执行一堆命令；规模一大，运维每天都在做这些重复的事情。在 SRE 体系里，这类工作有一个专门的名字，叫 toil （可以自动化、重复、但长期价值不高的工作）。

另一个问题叫 配置漂移。今天在一台机器上临时改了个参数，半年后没人记得；不同机器的配置慢慢变得不一样，系统也越来越难维护。

为了解决这些问题，运维开始走向自动化。
最早是各种 Shell 脚本，后来发展成 配置管理工具（比如 Puppet、Chef、Ansible）。再往后，一个更重要的理念出现了：基础设施即代码（IaC）。

简单来说，就是把服务器配置写成代码，放进 Git 里管理。这样所有变更都有记录，可以回滚，也可以重复执行。运维不再是“去机器上改东西”，而是“改代码”。

虚拟化云计算

再往后，一个非常关键的变化出现了：虚拟化和云计算。

以前买服务器是一件很重的事情，需要采购、上架、布线。虚拟化出现后，一台物理服务器可以跑很多虚拟机，服务器不再是硬件，而变成了一种“资源”。
到了云时代，甚至不需要自己买服务器了，直接在控制台点几下就能申请资源。运维的角色，也开始从“管机器的人”变成“调度资源的人”。

容器化技术

真正改变软件交付方式的，是 Docker 和 Kubernetes。

Docker 解决的是一个老问题：软件在不同环境运行不一致。
开发机器能跑，测试机器不行，线上环境又不一样。Docker 把应用和运行环境一起打包成一个镜像，就像打包盒饭一样，拿到哪里都能运行。

但如果只有 Docker，还是不够。
当容器数量变成几十、几百、几千个时，就需要一个系统去管理这些容器。于是 Kubernetes 出现了。

Kubernetes 的核心思想其实很简单：
你只需要告诉系统“我希望系统是什么样”，系统会不断把现实拉回这个目标状态。

比如你声明：“我要 3 个服务实例”，如果有一个挂掉了，Kubernetes 会自动再拉起一个；如果机器坏了，容器会自动调度到别的机器上。
这种机制叫 控制循环（Control Loop），也是 Kubernetes 能够自动化管理大规模集群的关键。

所以从更宏观的角度看，运维的发展其实是三次大的跃迁：

• 配置管理 / IaC：让服务器配置可以版本化管理
• 虚拟化 / 云计算：让服务器变成资源
• Docker + Kubernetes：让整个集群可以自动运行

Kubernetes 之后，如何发展

Kubernetes 并不是终点，它只是把“集群管理”这个问题解决得比较好了。
在 Kubernetes 之后，运维的发展主要集中在三个方向：更自动、更可观测、更少服务器心智负担。

第一个趋势是 GitOps。

GitOps 的思路很简单：
Git 就是系统的唯一事实来源。

所有配置都写在 Git 里，系统自动把线上环境和 Git 的状态对齐。如果要改配置，不再是去服务器上操作，而是提一个 PR。合并代码之后，系统自动完成部署。

这种模式最大的好处是：
变更可审计、回滚简单、流程更清晰。

第二个趋势是 可观测性和服务治理。

当系统变成微服务之后，真正复杂的往往不是某个服务，而是服务之间的调用关系。
请求可能经过十几个服务，一旦某个环节慢了，整个系统都会受影响。

于是出现了 Service Mesh、Prometheus、OpenTelemetry 这一类技术。
它们的核心目标是：让系统运行状态更透明，问题更容易被发现。

第三个趋势是 Serverless 和边缘计算。

Serverless 的理念是：
开发者只需要写代码，服务器由平台自动管理。

比如一个函数在有请求时才运行，没有请求就不占资源。对很多场景来说，这种模式可以大幅降低运维成本。

与此同时，一些计算也开始往“边缘”移动，比如门店设备、工厂设备、车载系统等。
为了适应这些场景，也出现了很多轻量化 Kubernetes（比如 K3s）和云边协同技术。

AI 如何改变运维

最近几年，AI 也开始逐渐进入运维领域。

很多传统的监控系统都是基于 固定阈值 的，比如 CPU 超过 80% 报警。但在复杂系统中，很多异常其实很难用阈值描述。

于是越来越多的平台开始用 机器学习来做异常检测。

例如：

• AWS 的 DevOps Guru 会分析指标数据，自动发现异常并给出建议
• Azure 的智能检测会自动识别性能下降或错误率上升
• Elastic 的异常检测会先学习系统的正常行为，再识别异常模式

还有一些研究和产品，会用深度学习去分析日志，从日志序列中发现异常模式。

这些技术的目标其实很简单：
减少告警噪声，让运维更快找到真正的问题。

运维这个职业，何去何从

很多人看到自动化和 AI，会担心运维是不是会消失。
但现实情况更像是：运维的工作方式在改变。

过去运维的价值，很多时候体现在“会不会手动处理问题”。
比如登录机器、改配置、重启服务、排查故障。

但未来更有价值的能力，其实是这些：

• 能把经验 自动化
• 能把流程 平台化
• 能从业务指标理解系统问题
• 能设计 可观测性和稳定性体系

目前来说 未来的运维，不是去修机器的人，而是让系统自己会修自己，会观测自己，会听从人类语言指令自动构建建设的那个人。