别吹了，DevOps 工程师就是给系统擦屁股的

上周三凌晨 3 点 17 分，我的手机像癫痫一样震起来。PagerDuty 显示生产环境 checkout 接口延迟飙到 8 秒。我眯着眼睛打开电脑，第一反应不是看日志，而是先打开 Terraform 的 state 文件——因为上周刚做过一次数据库迁移，我怀疑是某个同事手动改了安全组，导致应用服务器连不上 Redis 集群。结果不出所料，state 文件和实际 AWS 资源差了三个安全组规则。这不是第一次了，也不会是最后一次。

很多人以为 DevOps 工程师的工作是写漂亮的 CI/CD 流水线，是搞 Kubernetes 集群自动伸缩，是推行基础设施即代码。但在我干了五年之后，我越来越觉得，这份工作的核心其实是持续修复“人”造成的系统性裂缝。开发想快，运维想稳，业务想省钱，安全想管控，而 DevOps 工程师就是那个被夹在中间，负责把所有矛盾的后果咽下去的人。我们不是搞自动化，我们是给无数个“差不多就行”的决定做善后。

你问我为什么不用 Atlantis 做 plan 审批？为什么不用 OPA 做策略校验？兄弟，我试过。但现实是，业务上线迫在眉睫，架构师说“先上再说”，于是有人绕过了 PR 流程，直接在 AWS 控制台点了两下。等出事了，所有告警都指向我，因为我是那个“负责稳定性的”。开发同事会说：“你为什么不早说？”可你早说了，他们又会说“那你去跟老板谈延期的损失啊”。到最后，所有脏活累活都是 DevOps 的，而我们唯一能做的，就是把这些“手滑”变成下一次 runbook 里的一个检查项。

我并不是想抱怨，我只是觉得整个行业对 DevOps 的叙事太过于美化了。什么“DevOps 是一种文化”，什么“你我都是 DevOps”，这些话在大会演讲上说没问题，但你要是真信了，你就等着被坑。真实的 DevOps 工作里，60% 的时间在处理配置漂移、权限错乱、证书过期、镜像 tag 被覆盖这些破事。剩下的 40%，是在写文档告诉别人“不要这么做”，然后他们根本不看。我上次写了一份十二页的变更指南，结果第二天就有人直接在生产环境跑了一个 bash > /dev/null 的重定向任务。你说我还能怎么办？

所以我觉得，我们这代 DevOps 工程师真正该做的，不是追求什么“左移”，也不是盲目崇拜平台工程。而是学会承认系统的混乱本质，并且把这种混乱变成可控的、可见的、可恢复的常态。你可能觉得我在说废话，但你看看那些搞“GitOps”的团队，他们真的做到只靠 git 吗？没有，他们只是把手工操作换成了 YAML 里的人肉审批。关键不在于工具，而在于你愿不愿意接受一个事实：系统永远不会稳定，我们能做的只是让崩溃变得不那么痛苦。

最近我在想，也许我们该换个角度定义这个岗位。不是“DevOps工程师”，而是“生产环境的人类行为矫正师”。我们得设计一些让“错误操作”变得困难甚至可笑的机制，比如干脆把生产 console 的写权限关掉，只保留只读审计。当你真的这么做了，开发会骂你，但至少你不会在凌晨三点爬起来发现有人在生产环境跑了个 drop table。说真的，我宁愿被骂，也不愿意再擦屁股了。下一次谁再跟我谈“DevOps 转型”，我就让他先跟我一起守一次 on-call，感受一下什么叫真正的“文化”。