去年冬天凌晨两点，电信我被一个投诉电话从被窝里拽起来。后端某区宽带大规模中断，支撑总结用户打不进客服，工作客服也查不到故障点——因为网管系统里那台OLT设备显示“在线”，电信实际上光模块早被冻裂了。后端那是支撑总结我第一次意识到，后端支撑的工作价值不在系统跑得有多稳，而在用户感知断掉的电信那一刻，你能不能比用户更早发现。后端

那次事故之后，支撑总结我干了件得罪人的工作事：把故障工单的派发逻辑整个推翻。以前工单按“设备类型”自动流转，电信光猫问题去装维，后端OLT问题去传输，支撑总结可用户哪分得清自己是PON口闪断还是上联拥塞？我改成按“影响范围”分级，只要同一OLT下挂超过二十户报障，系统直接拉群通知所有相关专业的人，不管是不是你的设备，先上线看数据再说。运维同事骂我“小题大做”，但三个月后，跨专业协作的响应时间从四小时压到了四十分钟——没人再扯皮了。

干支撑这行，最怕的不是故障，是“假正常”。去年汛期，某机房动环监控一直显示温度24度，完美得让人发慌。我翻历史数据，发现该机房空调压缩机功率曲线连续七天纹丝不动，这不正常——设备功率再稳定也有波动。我直接打电话给值班员让他去现场摸一下空调出风口，结果制冷剂早漏光了，机房实际温度接近40度，交换机风扇狂转。监控没报警，因为传感器装在回风口附近，冷热空气混合后温度刚好卡在阈值内。这种事，光靠监控大屏永远发现不了，你得对“正常”保持警惕。

再说说那些“看不见”的工作。每个月我要处理大约两百条宽带质差用户数据，就是从BRAS上捞那些频繁掉线、时延忽高忽低的账号。这活儿枯燥，但有意思的是，很多质差根本不是网络问题——有个用户连续三周每晚八点准时掉线，查了所有链路都正常，最后发现是他家路由器定时重启，跟电信网络半毛钱关系没有。可用户不管，他认准了是运营商的问题。后来我学乖了，质差分析报告里专门加一栏“用户侧建议”，用大白话教装维师傅怎么跟用户解释，这比光发工单有效得多。

今年我开始琢磨自动化巡检脚本，用Python去模拟用户拨测，每天凌晨自动跑一遍核心业务的时延和丢包。刚开始同事觉得我没事找事——我们有专门的拨测系统，用得着自己写脚本？但那些商用系统测的都是标准场景，真实用户上网哪有那么规矩？我写的脚本专门模拟“非正常行为”：比如同时开视频会议和下载大文件，或者频繁切换Wi-Fi和5G。还真让我逮到过一次问题：某个边缘节点的缓存服务器在特定并发下会丢包，商用系统根本测不出来，因为它的测试流量太“干净”了。

支撑工作做了五年，我最大的体会是：别把“稳定”当成绩。稳定是底线，不是功劳。真正的本事，是在系统还没崩溃前，从那些不起眼的异常里嗅到危险的味道。就像老中医看舌苔，光看指标正常没用，得看气色、看精神头。这份工作教会我的，不是怎么修设备，而是怎么在数据洪流里找到那根最细的刺——它往往藏在最平淡无奇的曲线里。