去年我在一家做 SaaS 的公司做咨询，第一天开会，CTO 跟我大谈他们要搞"云原生 DevOps 转型"，PPT 上画了完整的工具链：Kubernetes、GitOps、Argo CD、Prometheus、OpenTelemetry，还有一堆我没听过的新玩具。我问他你们的部署流程现在什么样，他愣了一下说我们有个 Jenkins 脚本，大概要跑四十分钟吧。我说好，那我们先从这四十分钟开始。
那四十分钟里，有一个环节是等一个第三方 API 超时，超时重试五次，每次等两分钟。这个错误在日志里躺了半年，没人去修，因为大家都在忙着搭更酷的基础设施。这让我想起前几年流行的"DevOps 文化运动"，所有人都说我们要打破墙，要开发自服务，要持续交付，结果呢？我们只是把墙往右边挪了挪，然后贴上了新的标语。
在真正的小团队里，我见过最棒的 DevOps 实践其实特别朴素。一个五人的创业团队，没有 k8s，没有专门的运维，只有一台 8 核 16G 的服务器和一套用 Docker Compose 编排的应用。他们把部署脚本写成了 Makefile 的一行 make deploy，然后配上 WhatsApp 通知，每次发布完大家都会在群里发个火箭表情。那个脚本也没有多复杂，但人家连续一年零事故，因为每次改东西都会同步更新脚本，连带着把文档也改了。
对比起来，那些花了几百万搭平台的大公司，反而整天在解决平台本身的问题。我有次看到他们一个 SRE 的工单，说是升级 Argo CD 版本后，某个 Application 的 sync 策略变了，结果生产环境被回退了三个版本。这种问题在传统运维时代根本不会发生，因为你不会把整个发布系统拆成十几个微服务。工具本来是帮助减少复杂性的，结果它自己变成了复杂性的来源。
我后来跟那个 CTO 说，你们想要的其实不是 DevOps，而是平台工程。DevOps 的本质是让开发团队拥有运维责任，但你们引入了太多抽象层，以至于开发和运维都变成了平台的用户。而平台成了新的"墙"——墙更高，更厚，而且只有少数几个懂 K8s 和 GitOps 的"平台工程师"能翻过去。这跟十年前的运维团队有什么区别？除了名字听起来更唬人。
说到底，DevOps 被卖成了新的消费主义。每个季度都有新工具，每个工具都有新的 Dashboard，每个 Dashboard 都需要有人盯着。我们忘了 DevOps 最初的目标只是缩短交付周期，减少失败变更，快速恢复服务。这四件事，用一个 shell 脚本加一个 cron 都能做到，只是在某些公司里，没人会为"简单"买单。
如果你正打算做 DevOps 转型，我的建议是先把你的部署流水线跑起来看看哪里在卡，哪里的日志没人看，哪一步还是手工点击。先解决那些看得见的问题，再谈要不要上 Kubernetes。工具永远是为了解决具体问题而存在的，不是为了让你在 conference 上演讲。