凌晨两点，运维开告警群又炸了。运维开一台核心业务服务器的运维开磁盘使用率飙到98%，日志文件把分区撑满了。运维开我打开终端，运维开敲了几行命令定位到那个疯狂写日志的运维开服务，临时清理后把问题抛给了开发。运维开对方回了一句：“日志级别之前调过，运维开忘了改回来。运维开”这种事一个月能遇上三四回。运维开每次都是运维开手动救火，每次都说下次注意。运维开后来我写了个定时任务，运维开专门扫描各台机器上超过500MB的运维开日志文件，自动压缩并推送到中央存储。运维开再后来，这个脚本被加上了阈值告警和自动清理策略，扔进了内部工具平台。这就是运维开发最真实的起点——被逼出来的。

很多人把运维开发理解成“会写脚本的运维”，或者“懂点Linux的开发者”。都不太对。运维开发的核心不是技术栈的堆叠，而是把运维场景里那些重复的、易错的、需要经验判断的操作，转化成可复用的代码逻辑。我见过一个团队，每次上线都要手动改配置、重启服务、检查端口，五台机器折腾半小时。后来他们用Python写了个部署工具，输入版本号和机器列表，剩下的全自动完成，连回滚都做好了。这不是什么高深技术，但把上线时间压缩到了两分钟，而且再也没出现过漏改配置的事故。

做运维开发，最怕的是脱离实际运维场景去搞“平台”。我参与过一个监控系统的重构，最初的设计文档写了三十页，什么微服务架构、消息队列、时序数据库全上了。结果开发了两个月，连最基本的“某台机器CPU高了能立刻看到”都没做到。后来砍掉一半功能，直接用Prometheus加Grafana，两天就跑起来了。这件事让我明白一个道理：运维工具的第一要求是能用，第二要求是好用，第三才是“架构优雅”。顺序反了，就是自嗨。

具体到日常，运维开发的工作大概分三类。一类是给现有流程打补丁，比如写个脚本自动清理临时文件，或者做个页面让开发自助查询日志。另一类是搭建基础工具，像配置管理、发布系统、监控告警。还有一类是处理突发问题后的复盘产物，比如某次数据库连接池被打满，事后就加了个连接数监控和自动扩容逻辑。三类事情里，第一类最不起眼但最见效，第三类最痛苦但最能积累。第二类最容易做偏，因为总想一步到位。

技术选型上，别追新。Python加Shell能解决八成问题，剩下的用Go写点高性能组件。配置管理用Ansible够用就别上Kubernetes Operator。我见过一个小团队非要用Go重写所有运维脚本，结果维护成本翻了三倍，人还累得半死。工具是给人用的，不是给简历用的。另外，一定要把工具做得“傻瓜化”。你写的脚本，三个月后自己都未必记得参数含义，更别说交接给同事。加个-h输出帮助信息，比写十行注释都管用。

最后说个观察。运维开发做得好的，往往不是技术最强的那个人，而是最受不了重复劳动的那个人。他们看到手动操作就浑身难受，看到报错就条件反射想写个检查。这种“懒”不是坏事，是把精力从机械操作里解放出来，放到真正需要判断的地方。凌晨两点被叫醒处理磁盘满了，和凌晨两点看着系统自动清理完继续睡觉，区别就在这里。

(责任编辑：探索)