站长跨界融合启示：运维实习生的技术跃迁

文章配图，仅供参考

　　那会儿我刚转正三个月，每天的工作就是对着工单系统戳“确认”——主机巡检、磁盘空间清理、日志归档，连重启服务都要写三行操作记录。我原以为运维就是“服务器保洁”，结果五一那天，老监控系统突然抽风，所有主机的温度曲线在屏幕上扭成麻花，实际温度比显示值高了整整15度。更绝的是，报警邮件全卡在队列里，等我们发现时，三台数据库服务器已经自动关机了。

　　组长一边踹机柜一边骂：“这破系统是十年前站长带人写的，代码里全是‘if-else’硬嵌套，现在连个温度阈值都算不对！”我蹲在地上插拔内存条，听见他跟测试组打电话：“别测新版本了！先把监控系统的日志导出来，我要看看这帮人当年是怎么用‘死循环’处理报警的……”工位旁的加湿器还在冒白雾，显示器上贴的“今日工单：27/30”便签卷了边，外卖盒里的汤早就凝成一层油膜。

　　后来才知道，站长当年是搞开发的，跨界接手运维时，觉得“监控不就是写个脚本定时查数据吗？”于是带着两个实习生，用PHP+MySQL搭了个“能跑就行”的系统。结果十年过去，服务器从20台变成200台，监控项从5个变成500个，那套代码早成了“技术债”——比如报警阈值是写死在配置文件里的，每次扩容都要手动改；日志分析靠正则表达式硬匹配，稍微变个格式就报错；最离谱的是，系统为了“节省资源”，把所有报警邮件都攒到凌晨3点统一发送……

　　那天我们折腾到凌晨两点，临时用Zabbix搭了个简易监控，把关键主机的温度、负载、磁盘IO全接过去。组长盯着新系统的仪表盘，突然冷笑：“站长当年要是肯多花两天学学Prometheus，咱们现在至于在这擦屁股？”我原以为他只是吐槽，结果第二天，他直接拉了个会，把站长当年写的监控代码投影到大屏幕上——那哪是代码？分明是“技术拼图”：有从Stack Overflow抄的片段，有硬编码的IP地址，甚至还有用中文注释的“临时修复方案”。

　　测试组的阿杰凑过来，指着屏幕上一行“if ($temp > 80) { sleep(300); }”说：“这啥意思？温度超过80度就睡5分钟？”组长拍桌子：“这就是站长的‘智慧’！他觉得服务器过热时，先让它歇会儿，说不定自己就凉了……”全屋哄笑，可没人笑得出来——因为那行代码旁边，还躺着二十几个类似的“临时方案”，有的甚至注释着“2015年3月15日，站长亲测有效”。

　　后来我查了工单系统，发现这十年里，运维组报过17次“监控系统异常”，每次都被站长以“优先级不高”“先保证业务”为由压下去。最讽刺的是，去年春节前，监控系统因为日志文件过大崩溃，导致三台应用服务器宕机，站长在复盘会上说：“这是好事，说明我们的系统扛住了压力测试。”我当时就想，这哪是扛住？分明是“死撑”——就像用胶带粘裂开的手机屏幕，看着还能用，其实一碰就碎。

　　现在回头看，站长的跨界融合其实是个“反面教材”：他以为“能跑就行”就是技术，却没意识到，运维的核心是“可控”——可控的监控、可控的告警、可控的恢复。就像玩家抽卡，偶尔欧一次叫运气，但次次都欧，那一定是卡池概率被调过；运维也一样，偶尔靠“临时方案”救场叫应急，但十年都用同一套“临时方案”，那只能说明系统早就该淘汰了。

　　有人可能会说：“站长当年资源有限，只能这么干。”可资源有限不是借口——我实习时带我的师傅，用Python+InfluxDB搭了个轻量级监控，成本不到站长系统的十分之一，却能实时报警、自动扩容。他说：“技术债不是不能欠，但得知道什么时候还。”而站长呢？他把“能跑就行”当成了免死金牌，结果十年过去，债越滚越大，最后只能靠新人擦屁股。

　　测试机的充电线缠成一团，我扯了半天才解开。阿杰凑过来：“你说站长现在知道错了吗？”我摇头：“他去年调去负责新项目了，估计早忘了这茬。”他冷笑：“也是，跨界融合哪有KPI重要？只要业务不崩，谁管你技术债多少？”

　　现在每次看到工单系统里的“监控报警”，我都会想起去年五一那晚——空调外机在响，显示器上的温度曲线在跳，组长一边骂一边敲键盘，而我蹲在地上，看着那台自动关机的数据库服务器，突然明白：技术跃迁从来不是靠“跨界融合”，而是靠“优胜劣汰”——该淘汰的系统，就得淘汰；该还的技术债，就得还。不然，就像站长那套监控系统，看着能跑，其实早该进垃圾堆了。

　　对了，上周组长说，要彻底重构监控系统，这次不用PHP了，改用Go+TimescaleDB。我问他：“站长会同意吗？”他笑：“他现在管新项目，顾不上这儿——再说了，这次是老板拍板的，KPI里写着‘技术债清理’。”我哦了一声，没再说话。显示器上的便签又卷了边，我撕下来，重新贴了张新的：“今日工单：15/20”。

（编辑：均轻资讯网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!