工作总结
发布时间：2026-04-24服务行业年终工作总结（精辟）。
这一年下来，手头的活儿说白了就是两样：一是每天按部就班的巡检和维护，二是不知道什么时候会冒出来的突发故障。跟你讲个真事儿。
七月份那阵子，中心机房一台华为CE12800交换机的端口频繁闪断。一周出现三次，每次断个二三十秒自动恢复，但刚好赶上下午业务高峰期，影响了下游两百多台终端的访问。第一次报障时我按标准流程走：查物理链路、换光模块、测光纤衰耗。光功率-18.5dBm，正常范围内；模块收发光也都在阈值内。折腾两小时没找到原因，只能复位端口暂时恢复。说实话，当时觉得挺丢人的——干了六年还搞不定一个闪断。
第二次又出现，我学乖了。把设备三个月的历史日志全导出来，用Python写了个小脚本，过滤出所有端口状态变更的记录。脚本跑下来发现一个规律：每次闪断前，端口Gi0/0/3的入方向广播报文数量会在十秒内从平均83个/秒飙到超过4700个/秒。顺着这个端口往下游查，是接入层一台S5720下挂的一个监控摄像头网卡损坏了。那破玩意儿不断往外发畸形的ARP请求，把交换机的CPU利用率顶到98%，触发了协议栈的保护性重启。
处理过程其实简单——拔掉那个摄像头，换一台备用，问题就消了。但我后来复盘时给自己记了一笔：第一次排查花了两个半小时，其中两小时在错误的方向上。如果一开始就做流量趋势对比而不是先动物理层，这个时间能压缩到四十分钟。
这事之后，我给我们组的故障排查流程加了一个硬性动作——任何闪断类问题，必须先拉出故障点前后五分钟的广播包和CPU曲线对比图，有了数据再动手。这不算什么创新，但至少让我们少走了弯路。
再说说设备维护这块。我们组负责全市十六个节点、四百多台网络设备。以前的季度巡检就是对着清单打勾：清灰尘、看日志、测电源、查风扇。今年我搞了个性能趋势预判表。每台核心设备的CPU、内存、端口流量按月做曲线，用Excel的线性趋势线算斜率。如果你发现CPU曲线连续三个月斜率都是正的，哪怕当前才40%，也得提前看。
举个例子。九月份做数据时，一台汇聚交换机的内存使用率曲线斜率达到每月2.3%，当时实际占用63%，远没到80%的告警线。但我翻了去年同期的数据，发现这个斜率不正常——正常应该在0.5%以下。拆机一看，是内部一个进程日志写爆了，把内存分成碎片块。重启清空日志后，曲线斜率降回0.3%。如果等到80%告警再处理，那个节点下的四十多个监控摄像头会全部掉线。
当然也犯过二逼的错误。八月份有个链路聚合的故障，当天晚上我抢修完就简单记了几个操作步骤，画了个粗糙的网络拓扑。三个月后，另一个同事遇到几乎一样的问题，翻我的文档发现端口状态交替顺序没写清楚，聚合组的主备切换条件也漏了。他打电话问我，我当时自己也记不太准了。后来我俩一起重新搭环境复现了一次才算搞清楚。这事给我的教训是：复盘文档如果不画好时间轴、不标清楚每一步的预期结果，那就是废纸。
-
66职场网精选典藏:
- 服务行业思想总结 | 服务行业工作总结心得 | 景区服务行业转正总结 | 服务行业个人工作总结 | 服务行业年终工作总结 | 服务行业年终工作总结
说到自己的开发工作，今年我写了一个小工具，算不上多高级，但很管用。以前排查环路或者异常广播，得手动登录每一台交换机敲命令看MAC地址表。我写了个基于Netmiko的批量采集脚本，输入一个IP范围，自动登录、抓取mac-address-table和arp信息，输出成CSV。原来查一个区域的广播源需要四十分钟，现在三分钟出结果。脚本还在持续改，加了异常日志自动标记功能——如果某个MAC地址在五秒内在两个不同端口出现，标红报警。这事让我觉得，技术骨干不能光会修故障，还得会造工具，把重复劳动干掉。
不足的地方也挺明显。一是预维护做得还不够细，目前只覆盖了核心层设备，接入层的四百多台交换机还没纳入趋势监控。那些老设备才是真正的雷区。二是故障复盘的标准化不够。虽然我现在要求组里每个人都写，但不同人写的颗粒度差距很大。有人会贴配置对比和抓包截图，有人就写两行“重启解决”。明年一季度之前，我准备把之前总结的复盘模板固化下来，至少包含故障现象、时间线、根因链、修复步骤、预防措施这五个模块，然后用Git管理版本。
说到底，干技术服务这行，经验不是干得久了就自然有的，而是每解决一个问题之后，能不能把它拆透了、写明白了、以后还能用得上的过程。明年我给自己定的目标就一个：把接入手上的四台老旧汇聚设备全部做过一遍预检，把那个批量脚本的功能再扩展一版，加上自动告警推送。别的虚的，不说了。
-
为了您方便浏览更多的工作总结网内容，请访问工作总结
