DevOps工程师到底需不需要会写代码？

先说结论：如果你只想做个“运维操作员”，那确实不用会写代码，用现成工具点点点就行。但如果你想让自己的薪资翻倍、能在招聘市场上被抢，那写代码的能力就是你跟别人拉开差距的硬指标。我2018年进第一家公司做DevOps，当时觉得自己特牛，会配Jenkins、会用Ansible跑几个playbook，还能用Python写个自动化清理日志的脚本，这不就是DevOps吗？结果后来遇到一个线上故障，需要临时写个Sidecar来拦截流量做灰度对比，我对着Go语言的interface看了三个小时，最后靠运维同事用Bash硬凑了个方案，线上差点没救回来。那次之后我彻底明白，DevOps的“Dev”不是白写的。

会写代码和不会写代码的DevOps，差距具体在哪

我自己的体会是，纯靠Shell和手工点界面搞自动化，顶多解决30%的重复问题。但一旦进入云原生时代，Kubernetes的Operator、自定义控制器、Prometheus的exporter定制、服务网格里的Wasm插件，这些玩意儿全是代码驱动的。比如2022年我给一个电商客户做资源成本优化，他们有一千多个Pod，每次大促前要手动调整HPA阈值，光改YAML就改到眼瞎。我用Python写了个控制器，读取历史监控数据自动计算并调整Deployment的副本数和HPA配置，整个过程大概五百行代码，搞完之后大促期间CPU使用率稳定在60%到75%之间，成本直接降了28%。而旁边一个负责同样业务的同事，还在用Kubectl手动敲命令改副本，熬了几个通宵，效果也不如我的好。这就是活生生的对比。

当然我不是说代码越高级越好，很多场景下Bash加awk加sed就是最快的解决方案。我见过一个老运维，用一行awk直接处理了10GB的nginx日志，找出所有5xx状态码的IP段，效率比我用Python写多线程还高。但问题是，Bash适合做“一次性解决问题”的事情，而DevOps的核心是要交付“可持续演进平台”。你今天用Shell处理的临时问题，明天还会换个姿势再来一次。写代码的本质其实是把你自己从重复劳动里解放出来，让你能思考怎么让系统自己运行自己修复。比如我之前写的一个自动故障转移脚本，刚开始用Bash写的，两百多行，逻辑复杂得自己都看不懂，后来用Python重构到八十行，加了单元测试，故障演练的时候终于不用提心吊胆了。

别把DevOps和平台工程混为一谈，它们差的也是一个代码能力

现在很多公司招的所谓“DevOps工程师”，实际干的是“平台工程师”的活——要搭CI/CD流水线、要维护内部开发者平台、要提供自助式基础设施接口。这种情况下，光会写脚本的人根本玩不转，因为平台本身就是一个软件产品，你不懂API设计、不懂数据库事务、不懂消息队列，你怎么去设计一套让研发团队用得爽的发布系统？我去年面试过一个候选人，简历上写了五年DevOps经验，精通Kubernetes和Jenkins。我问了他一个问题：如果让你设计一个持续部署系统，要求支持十个微服务并行发布、发布失败自动回滚、并且能区分不同环境的状态，你会怎么设计？他开始东扯西扯说用ArgoCD就行。我再问ArgoCD的同步机制底层原理是什么？如果遇到资源冲突怎么办？他直接沉默了。这就是典型的情况——用过工具但是不会写代码，遇到问题只能重启Pod，一旦工具本身出问题就彻底歇菜。

但我也观察到一个反方向的现象，就是有人太执着于写代码，把DevOps搞成了“开发运维平台”而不是“运维业务系统”。我有个前同事，非要用Go重写一个内部用的部署工具，本来Ansible加Shell十分钟能搞定的事情，他花了三周写了几个自定义CRD和控制器，最后因为没时间写文档和维护，那个代码库成了孤儿项目。我觉得真正的DevOps工程师应该有的能力是：拿到一个具体的运维问题，先判断用脚本、用现成工具、还是写完整代码来解决，并且能预估出各自的成本。这种判断力比单纯会不会写代码重要得多。对于想要入行或者转型的人来说，我建议先学Bash和Python，再学点Go或者Java，能看懂主流开源项目的核心代码就行，不一定要从头造轮子。同时多去了解业务架构和部署拓扑，因为代码不是目的，让服务稳定跑着才是目的。

写了这么多，其实就想说一句话：DevOps工程师会写代码不是万能药，但不会写代码就是没有牙齿的老虎。只要你还想往上走，不管是转向SRE、云架构师还是平台工程负责人，代码能力都是你绕不开的一道门槛。别被我说的那些技术名词吓到，拿个自己负责的小任务，试着写成自动化工具，比如自动清理测试环境的脚本、自动生成监控报表的小应用，半年之后你会发现，原来那些逼得你加班到深夜的事情，其实一两百行代码就搞定了。