工作总结
发布时间:2026-03-27联通话务员工作心得。
今年跟往年比,最憋屈也最痛快的一件事,就是六月份那场IMS语音故障。痛快不是结果好,是过程让我把自己那套“接电话、派工单、等外线、催回复”的老流程给砸了。
那天下午一接班,投诉电话就跟商量好了似的涌进来,全是一个片区的固话打不了。换往年,我肯定是一边接电话一边开工单,32个用户就是32张单,派给外线,然后等他们到了现场,查完一户再查下一户。运气好,两三个小时能恢复;运气不好,用户等急了,工信部投诉下来,整个班组跟着挨批。
那天我没这么干。说实话,电话响成那样,心里也毛,旁边座席同事看我一眼,那意思就是“你这片区又炸了”。但我没急着点开工单界面,先登录U2000网管,把那片区域所有ONU的注册状态扫了一遍。扫完心里咯噔一下——不是零星掉线,是某个PON口下挂的32个用户全部在“离线-注册中”来回跳。这他娘就不是用户端的问题了。
我调出那个PON口收发光功率的历史曲线,看到过去24小时光功率从-18dBm一路跌到-28dBm,中间还有三次骤降。这简直令人难以置信——前两天施工队刚在附近布放过光缆,熔接包八成没盘好,纤芯被挤压了。
接下来那通电话我现在还记得。我直接打给外线班长老周,张嘴就说:“周哥,你带上OTDR去XX路口那个光交,我怀疑1.8公里附近有熔接损耗点,不是用户端的事。”老周在电话那头愣了两秒,说:“你一个坐席的,怎么知道我该去哪?”我说:“你先去,我网管上看得见光功率曲线,错了我请你吃饭。”
四十分钟后,老周电话打回来:“你神了,真在1.8公里处找到个熔接损耗点,重新熔了,光功率上来了。”那四十分钟,我一边应付着继续打进来的投诉电话,一边盯着网管上那个PON口的光功率数值。从-28dBm慢慢回升到-26、-24、-22,直到-19dBm稳定住,32个用户的注册状态一个一个变绿。说实话,那种感觉,比多发几百块奖金都爽。
这事儿之后我给自己定了两条规矩:第一,以后不管什么故障,先看网管上关联设备的数据,不能一个用户一个用户单打;第二,每次处理完,把根因写成标准化的排查步骤,存进班组共享文件夹。
八月份那个政企客户的视频会议卡顿,就是这条规矩救的场。用户是家设计院,每周二上午雷打不动跟总部开方案评审会。连续三周卡成PPT,客户经理被骂得抬不起头,转到我这的时候,用户口气已经硬得能砸核桃。
我远程登进用户的光猫,光衰正常,PON口收发光功率也正常,但顺手点开设备信息一看——光模块温度72度。我心里骂了一句,这玩意儿正常应该在四五十度,72度早该报警了。翻历史记录,这个温度已经持续了两周。当时机房空调出过故障,虽然恢复了,但这光模块明显已经“内伤”了。
我联系厂家,厂家说光模块得换。我说行,那你给我发个新的,我上门换。厂家愣了半天:“你是话务员还是代维?”我说我什么员不重要,重要的是用户等不了了。下午我带着新模块去了用户机房,拔下旧的,烫得差点没拿住。换上新的,温度掉到48度,用户当场开视频会议测试,一路流畅到底。
这事儿后来我写了篇复盘,把“高温导致光模块误码率升高”这个案例加进了月度培训材料。有同事说我管得宽,我心想,下次谁再碰到这种情况,不用再走一遍弯路,这就是管得宽的价值。
九月份那次的预警,更让我觉得这条路走对了。我日常用SNMP轮询抓OLT的关键指标,设了阈值告警。那天系统弹出来一条,说某台OLT的上联口错包率异常增长。不是已经超标,是连续三天缓慢增长。我调出历史数据,发现每天凌晨两点到四点错包率会跳一下,白天又降回去。打电话问传输那边,说那条链路最近在割接调整,可能尾纤有微弯。
我赶在用户感知到丢包之前,协调传输专业去机房检查。果然,那根尾纤被机柜门夹了一下,有轻微折痕。换了一根,错包率曲线立马平了。这种“治未病”的干法,比等用户骂上门来舒服太多了。
-
⬬群学网业界良心专题:
- 话务员工作汇报 | 学校话务员工作总结 | 电信话务员工年度工作总结 | 话务员年终个人工作总结 | 联通话务员工作计划 | 联通话务员工作计划
但也不是每次都能这么顺。有次处理一个宽带掉线,按老经验查了一圈,光功率、数据、设备温度,全没问题。用户是个退休老教师,说话慢条斯理的,但掉线频率高得离谱。我在远程折腾了两天,该查的都查了,实在没招了,申请了备机去现场换。
到了用户家,老教师给我倒了杯茶,说:“小伙子,辛苦你了,我这事儿让你费心了。”我一边说没事一边拆墙上的信息插座。拆开一看,里面的模块线序打错了,只通了四芯。百兆勉强跑,稍微有干扰就掉。重新压了个模块,再没掉过线。
走的时候老教师非要送我下楼,说:“还是得你们亲自来一趟啊。”我当时心里说不出什么滋味。干了这么多年,有时候太依赖远程手段,反而忘了最后那一百米才是最要命的。
说白了,话务员也好,运维也好,到最后都是给用户解决真问题。今年我处理的工单里,重复报修率比去年降了不少,个人满意度也上来了。但这数据背后,是无数次跟设备较劲、跟历史遗留问题死磕、跟自己那套“差不多就行了”的惯性思维对着干。
明年,我打算把那套自动化巡检脚本再完善完善,把一些容易忽略的隐性故障点也加进去。另外,自己这些年踩过的坑、趟过的路,想整理成一份更直白的排查手册,给新来的同事省点时间。这行当里没有捷径,只有真摸过设备、真熬过夜、真被用户骂过,才知道什么叫稳定。
-
想了解更多工作总结的资讯,请访问:工作总结
