说实话，我一开始干运维纯属误打误撞。2019年毕业进了家小公司，老板说缺个管服务器的，我就去了。那时候哪懂什么运维开发，就是每天ssh上去敲命令，写点shell脚本批量看日志、清磁盘。到了2020年公司业务涨了，机器从几台变成几十台，我还在用for循环加crontab，结果有一次凌晨磁盘满告警没抓到，整个业务崩了，老板凌晨三点打电话骂人。那事之后我意识到，光靠脚本不行了，得有个正儿八经的监控报警体系。
于是我开始学Prometheus、Grafana，学着把各种exporter接进来。一开始确实很开心，觉得这玩意比Shell高级多了。但后来慢慢发现不对劲：监控指标越来越多，告警规则写了一堆，可真正出了事，大家还是手忙脚乱。有一次MySQL主从延迟，告警是触发了，可当时值班的同事根本不知道先看哪块面板，在群里吼了十分钟才找到人。我那时候才明白，工具再炫，如果流程和人的认知跟不上，就是白搭。
后来我觉得光做监控不够，还得把运维能力开放给开发，于是开始搞自动化平台。用Python写了套发布系统，从Git拉代码、构建镜像到滚动更新，整个过程做成Web界面，开发点点按钮就能上线。刚开始他们觉得特别好用，后来就出幺蛾子了：有人半夜发布没看SQL变更，把表给锁了；有人频繁回滚，导致容器一直漂移。我这才发现，我把流程自动化了，但没说清楚边界和规范，反而让事故升级得更快。这事之后我改版了权限控制，把高危操作单独拉出来二次审批，也逼着开发把数据库变更纳入发布流程里，才算稳下来。
对比我另一个在传统运维岗干了五年的同学，他现在还在手动改配置、跨机房跑脚本。他觉得我的东西太复杂，我也觉得他那套迟早被淘汰。但反过来讲，我这两年天天扑在Kubernetes和Terraform上，已经很久没真正沉下心去理解一条SQL的执行计划或者TCP握手细节了。有时候开发追着问为什么这个接口偶发超时，我第一反应是查链路追踪，而不是先想想是不是网络参数没调好。说实话，这种虚浮感一直困扰着我。
如果让我总结运维开发这个岗位，我觉得它本质不是写代码，也不是盯监控，而是要把复杂的系统状态抽象成别人能懂的东西，然后把这个抽象过程固化下来。你写的每一段自动化代码，本质上是在表达你对运行时的理解。但理解得不好，代码越写系统越乱。我见过有人用Ansible写了五百行的玩法，最后没人敢碰，就是因为他没搞懂幂等性的意义。我也见过我一个前同事，愣是用Zabbix加Python脚本撑起了几百台节点的监控，虽然土，但稳定得一批。
所以你要问我值不值得做？我劝你，先别看薪资和热度，你得先问问自己能不能接受那种夹在开发和业务之间、天天当传话夹板的日常。如果你想在里面找到一个纯粹的、自己说了算的边界，大概率会失望。但如果你能扛住混乱，并且愿意把每一次事故当成迭代需求，那这行还是有点意思的。我现在还在学着少堆技术栈，多写点文档，多跟开发聊业务，毕竟，再牛的发布系统，也扛不住业务方向想不清楚的团队。