运维开发是什么

凌晨两点，手机响了。不是闹钟，是告警短信。一台线上服务器的磁盘使用率飙到98%，业务日志还在疯狂写入。我爬起来打开电脑，第一件事不是SSH登录那台机器，而是打开自己写的一个小工具，点了一下“自动清理归档日志”按钮。三十秒后，磁盘降到60%。然后我关掉手机，继续睡。

这就是运维开发。它不是一个岗位名称那么简单，而是一种工作方式——用写代码的方式，去解决运维里那些重复、琐碎、容易出错的事情。

传统运维什么样？登录机器，敲命令，改配置，重启服务。一台机器还好，十台呢？一百台呢？每次上线新版本，手动传包、解压、停服务、启服务、检查日志。干到第三十台的时候，手已经开始抖了，因为你不知道前面哪一步漏了。运维开发的人受不了这个。他们会写一个脚本，把所有步骤串起来，点一次执行，一百台机器自动完成。脚本里还加了检查点，哪台失败就停下来报警，不用人盯着。

有人把运维开发理解成“会写脚本的运维”。这说法太窄了。我见过一个典型的例子：某电商公司的运维团队，每天要处理上百个“帮我开个权限”的工单。人工审批、手动执行、回复邮件，三个人轮班都忙不过来。后来他们用Python写了一个自助平台，开发人员自己提交申请，系统自动校验权限、调用API开通、发通知。运维人员从“执行者”变成了“平台维护者”。工单量没变，人力省了两个。

运维开发的核心不是工具本身，而是把运维经验固化成代码。你知道磁盘满了要先看哪个目录，知道日志切割要配合服务重启，知道数据库主从切换前要检查延迟。这些“知道”如果只留在人脑里，人一休假就抓瞎。写成代码，它就变成了团队的能力。

我参与过一个CI/CD流水线的搭建。之前开发提交代码后，要等运维手动构建、手动部署到测试环境。平均等待四十分钟。开发经常抱怨“改一行代码，等一节课”。后来我们用Jenkins加Ansible写了一套自动化流程，提交即构建，构建通过自动部署到测试机，发消息通知开发。等待时间降到三分钟。开发开始愿意频繁提交小改动，而不是攒一周再合并。代码质量反而上去了——因为每次改动小，出问题容易定位。

运维开发的人通常有个特点：对“重复”极度敏感。看到同事第三次手动做同一件事，就想把它自动化。这种敏感不是天生的，是被线上事故逼出来的。手动操作一定会出错，而出错的代价可能是几小时的故障，或者几百万的损失。代码不会累，不会走神，不会因为接了个电话就忘了改配置。

当然，运维开发不是万能药。写自动化工具本身要花时间，有时候写工具两小时，手动做只要十分钟。但下次呢？下个月呢？如果这件事每周做一次，写工具就值。判断标准很简单：一件事重复超过三次，且步骤固定，就值得写成代码。

另一个误区是追求“全自动”。我见过一个团队，非要搞无人值守的故障自愈系统，结果误判了一次，把正常节点踢出了集群。自动化要有边界，关键操作留人工确认，或者至少留一个“后悔按钮”。运维开发的目标是减少重复劳动，不是消灭人。

现在很多公司招运维开发，要求会Python、Go、Kubernetes、Prometheus。技术栈确实重要，但更关键的是理解运维场景。一个不懂Linux排障的人，写出来的“自动化工具”可能连日志路径都找不对。工具是手段，不是目的。

回到开头那个凌晨两点的故事。那个自动清理工具是我花了三个周末写的，代码不到两百行。但它让我少熬了至少二十次夜。运维开发就是这样——你花时间写代码，代码帮你省时间。省下来的时间，你可以用来写更多代码，或者，好好睡觉。