DevOps工程师正在沦为“流水线操作工”？

我先说一个可能挨骂的观察：2024年还在鼓吹“DevOps文化先行”的人，要么是没在万人规模公司待过，要么是卖课的。我干了6年DevOps，从传统运维转过来，经历过3000+节点的自建K8s集群迁移，也带人搭过一天跑2000次构建的Jenkins流水线。说实话，DevOps这个岗位正在分化成两种人：一种是天天改YAML、点鼠标发布、被拉去开会背锅的“流水线操作工”；另一种是真正理解系统边界、能用平台思维解决问题的“架构师型运维”。而我见过的大多数人，都在朝第一种滑落，包括我自己有一阵子也是。

第一个残酷真相：你的仪表盘越漂亮，离生产事故越远

很多团队引入DevOps后的第一个动作，是把部署频率和变更前置时间做成大屏。我们公司也不例外，CTO每周例会上都要看这两个数。为了把部署频率从周更变成日更，我们拆了微服务、上了dev分支自动构建、搞了蓝绿发布。那阵子数据确实好看，平均每天发布7次，变更前置时间从11个小时压缩到45分钟。但真实情况是什么呢？为了达标，团队开始用“跳过测试”的方式赶工，集成测试覆盖率从68%掉到34%，因为每次变更都要跑全量回归太慢了。后来一次依赖冲突直接把订单服务搞挂了4个小时，复盘的时候发现那个变更已经在流水线上“成功”部署了9次，每次都跳过了冒烟测试。那个瞬间我突然意识到，我们一直在优化一个对业务毫无意义的指标。DORA指标是好东西，但很多人把它当成了KPI，而不是诊断工具。真正的DevOps应该盯着另一个数字：平均故障恢复耗时（MTTR）和变更失败率。我们那年的变更失败率是22%，几乎每四次发布就砸一次，但没人挂在大屏上。因为这些数字不好看，会暴露我们的重构其实没有让系统更稳定，只是让流水线跑得更快而已。

第二个残酷真相：工具链越多，你离“自动化”越远

前阵子我梳理了一下我们整个DevOps的软件栈，光CI/CD相关就有12个工具：Jenkins跑构建，GitLab CI跑MR校验，ArgoCD做CD，HashiCorp Vault管密钥，还有一个内部的发布平台是上一批人用Go写的，另外还挂着三个不同的监控告警系统，因为Prometheus、Zabbix和云厂商自带的监控各有一帮人用。这玩意儿根本不是“基础设施即代码”，是“基础设施即一团乱麻”。最荒诞的是，我们花了大半年搭的“全自动”流水线，最后需要两个专职人员去维护流水线本身的依赖——比如某个插件版本升级会导致构建镜像缓存失效，或者ArgoCD和GitLab的Webhook偶发不同步，得手动去点“Refresh”。我统计过，一个普通功能从合并到生产，端到端平均是2.5小时，但其中真正在跑自动化流程的只有18分钟，剩下全是在等、在排查、在人工触发。所以别再说“DevOps解放了运维”，它只是把原来运维手工操作的工作，变成了DevOps工程师手工维护自动化工具的工作。我在上一家公司甚至提出过一个看起来很不政治正确的方案：砍掉一半工具，先把Jenkins和GitLab CI合并成一个，把三个监控系统收敛到Prometheus+Alertmanager。结果被leader以“影响其他团队现有流程”为由拒绝了。三个月后我离职了，听说他们又把监控加了两个。

第三个残酷真相：你天天做平台的事，但拿的是运维的钱

这是个很扎心的问题。我和几个朋友私下对比过薪资，同样是在互联网公司，一线DevOps工程师的薪水普遍比SRE低15%到20%，比后端开发低30%左右。但看看招聘JD——要求懂Kubernetes、Istio、Prometheus、Terraform、CI/CD，还要会Python或Go，能处理突发故障，最好还能跟开发团队沟通需求。这要求明明比普通后端高出一截，凭什么价格倒挂？后来我想明白了，因为DevOps的位置太“中间”了：你说自己是研发吧，大部分时间在维护别人写的部署代码；你说自己是运维吧，又得承受7x24的告警电话。在大多数公司眼里，DevOps就是“高级点的运维”，而不愿意承认它其实是在做内部平台产品。但反过来看，正是因为很多人自己也没想清楚，才被困在这个位置上。我后来接触到了“平台工程”这个概念——把运维能力封装成自助式平台，让开发通过API或界面自己完成大部分操作。这其实才是DevOps的最终形态。我见过一个做得好的例子：他们只保留了一个核心平台团队（5个人），但服务着公司里40多个开发团队，做法就是坚持把一切能力都“产品化”，发布窗口、环境申请、日志查看全部通过一个内部开发者门户搞定，开发团队根本不需要接触K8s。那个平台团队的人，现在跳出去个个都是抢手的平台工程师，薪资比普通DevOps高40%以上。

所以，别再学K8s了，去学“怎么让一万人不需要学会K8s”

我不是说Kubernetes没用，我想说的是，如果你还在把“会用kubectl、能写Helm chart”当作核心竞争力，那真的离被淘汰不远了。因为云厂商AWS和Google Cloud都在搞“免运维K8s”，托管集群的维护成本越来越低，而生成式AI写出的YAML已经基本不出错了。我最近试了一下让GPT-4帮我排查一个诡异的Service Mesh连接超时问题，它给出的思路比我们组里一半的同事都靠谱。那DevOps工程师以后靠什么吃饭？答案是：理解业务、抽象需求、设计自服务流程。你要能回答这几个问题：怎么让一个新服务在三十分钟内完成接入、监控、日志、权限配置，而不需要任何一个人去填工单？怎么在发布系统里自动判断一个变更的风险级别，然后决定走快速通道还是走全量回归？怎么把告警收敛到“一天只收到5条真正需要人类处理的”水平？这才是真正的“降本增效”，而不是让你的pipeline跑得更花哨。我自己的建议是，花点时间去读SRE workbook，去学一点平台工程的设计模式，然后找个机会在你所在的团队里尝试推行一个最小的自服务门户——哪怕只是一个带按钮的网页，能让开发自助申请一个测试环境。别小看这种土炮，我当年就是靠一个扔在内部Wiki上的shell脚本集，把测试环境申请时间从一个工作日缩短到15分钟，才终于摸到了“平台感”的门槛。这条路不是没方向，只是太多人只盯着流水线那点东西，忘了抬头看看更大的系统。

记住，工具会变，平台会变，但“让复杂系统变得对使用者简单”这件事，永远是DevOps工程师真正的护城河。