工作总结
2026-04-29 工作总结 五周年工作总结2026年自贸区五周年工作总结。
从2018年挂牌算起，我在自贸区片区干了整整五年。项目技术经理这个位子不好坐，底下管着7个人，上面顶着海关、码头、政务网十几个部门的需求。说白了，就是得把烂摊子收拾利索，还不能让业务方觉得你不专业。
先交个底：这五年，我们负责的网络核心节点可用性99.99%。可能有人觉得这个数一般，但你得知道，我们这里7×24小时通关，夜里三点的故障最要命。刚开区那会儿，半年内发生过两次夜间大面积断网，都是因为监控没覆盖到死角。用户打电话过来骂，我们只能一边赔不是一边摸黑查。
好在后来一点点啃下来了。到现在，年均故障响应时间从45分钟压到12分钟以内。客户满意度从82%涨到96%。这个96%怎么来的？不是自己编的，是管委会每季度委托第三方随机抽20家入驻企业做的电话回访。去年四季度有一家物流公司给了不满意，理由是“维修后没主动告知原因”，我们后来加了一条流程：每次故障修复，一小时内发短信通知联系人。
项目交付方面，五年32个配套项目，平均提前率11.3%。这个提前率计算方法很简单：（计划天数-实际天数）/计划天数，取所有项目的平均值。有3个项目其实是延期了的，但延期原因都是甲方变更需求，我们按合同重新算了工期，不计入考核。
监控升级：从被骂到提前预警
2018年底那次改造，我们干得最实在。花了43万，把两个核心机房和6个弱电间的动力环境监控全换了。老的监控只有温度和烟雾，空调压缩机卡死都不会告警。新系统加了189个传感器节点，不光温度湿度，连UPS每个电池组的电压都实时采集。这钱花得值不值？我给你算笔账：换了以后，第一年就提前发现了三次电池内阻异常，避免了UPS带载掉电。单独那三次，如果真掉电了，通关业务中断一小时起，光企业索赔就不止43万。
自己写的告警收敛平台，一开始也是坑。第一版上线时，阈值设得太敏感，一个机柜温度波动两度就发警报，值班兄弟一晚上收到两百多条微信。我们后来花了两周时间，把每个传感器的告警阈值根据历史数据重新拟合，又加了关联分析——比如同一机柜的温湿度、风扇转速、空调出口温度同时异常，才推一级告警。现在基本能做到一天少于5条无效告警。
去年7月那个空调压缩机案例，我印象很深。海关二机房的精密空调，品牌是华为，用了三年多。我们平台在凌晨两点多报了排气温度偏高，但不是一级告警，是二级预警。值班工程师小王看了数据，发现排气温度比前一天同一时段高了11度，而且压缩机运行电流也涨了7%。他判断不是偶发波动，凌晨三点直接打电话给我。我到现场用热成像一扫，压缩机外壳有一块区域温度明显偏高，判断是内部轴承磨损。早上八点我联系维保商，对方报价两万八换压缩机。领导问我能不能修，我们自己拆开看了，轴承抱死，轴已经偏磨了，修不了。最后砍到两万二，下午两点新压缩机换上，三点恢复。用户那边全程没感觉——因为我们提前把业务切到了备用空调，机房温度一直控制在24度以下。
网络改造：一次真实的割接“出包”
2020年扩区，最头疼的是网络物理隔离改造。老设备不支持VRF，预算又只批了80万，换不了核心交换机。我们想了个笨办法：在旧设备之间搭临时二层隧道，把新规划的VLAN一段一段挪过去。每挪一段，跑24小时流量验证，没问题再挪下一段。
割接定在某个周六凌晨2点到4点。我带了三个工程师蹲在机房，提前把配置脚本在模拟器上跑了四遍。结果真割的时候，新配的华为交换机跟对端的思科3560（IOS版本12.2(55)SE）出现生成树协议兼容性问题。华为这边发出来的BPDU，思科不认，直接把端口阻塞了。我当时心里咯噔一下——临时想脚本？来不及。好在提前做了预案，把强制端口边缘模式的备用脚本灌进去，再手动把两台设备的路径开销改成一致。20秒，端口起来了。事后统计丢包6个，其中5个是广播包，实际业务无感知。 386H.cOM
这个Bug后来我们专门写了份技术通报，把华为S5720跟思科3560对接时生成树的坑列了三条，贴在内部分享平台。去年另一组同事做类似割接时，提前改了参数，没出问题。
带团队：我比较“较真”的那几件事
团队7个人，工龄从两年到十五年都有。我最看不惯的是出事就互相推。所以立了条规矩：每次故障，不管大小，48小时内必须出根因分析报告。报告里不能只写“网络问题”或者“设备异常”，必须细化到哪个命令、哪个参数、哪个硬件。写不清楚的，周末搭环境复现。
五年攒了80多份这样的内部案例。新人入职第一周不看文档，直接拿最近三个月的案例做模拟排查。去年有个新来的小伙子，入职第三天遇到一次DNS故障，他自己按照类似案例的步骤，十分钟就定位到是缓存污染，我们觉得这方法管用。
- ⬬小学范文网新老编辑交接必传内容:
- 2026年终工作总结 | 70周年作文 | 2024年七一建党103周年总结 | 财务五年工作总结 | 自贸区五周年工作总结 | 自贸区五周年工作总结
技能交叉这事，我做得可能有点狠。网络组的必须会看Linux的路由表和iptables，系统组的必须知道交换机的基本VLAN配置。每个季度搞一次“实战擂台”，我随机设故障场景，限时90分钟排查。今年一季度我设的是：跨境申报系统返回“域名解析失败”，但明明nslookup能解析。故障涉及DNS转发策略、负载均衡健康检查、防火墙域名白名单三层。最后全组都在80分钟内定位到根因——负载均衡的健康检查源地址被防火墙误拦截了。比去年同类型场景快了28分钟。我没表扬，但请大家喝了奶茶。
有一个年轻工程师，去年处理光模块故障时，没测光衰就直接换模块，结果换上去还是不通，折腾了两个小时才发现是光纤头污染。我把他喊过来，没骂，让他自己写一份《光纤链路故障排查九步法》。他花了三天，反复改了三版，最后那份流程现在是我们处理光模块问题的标准操作。他自己后来跟我说，写一遍比听十遍都管用。
说实话，还有一堆烂账
现在最大的问题是自动化程度低。核心交换机上跑了三百多条ACL，谁哪天改了哪条，全靠微信聊天记录翻。上个月有一次因为ACL顺序错了，导致一个网段的虚拟机访问不到数据库，查了两天才发现。我们想上配置管理平台，但公司预算一直没批。今年我自己写了个脚本，每天凌晨自动备份所有设备配置，并用git做版本对比。虽然简陋，但至少能看出谁改了什么。
另一个短板是对业务理解不够深。有次海关那边报“系统卡顿”，我们查了链路、查了设备，都没问题，后来人家业务人员点了一句：“你们有没有查数据库连接池？”我们才恍然大悟——我们的人不懂应用层。所以从今年开始，每个月安排一个人去业务部门跟岗半天。第一个去的回来跟我说，原来海关的申报系统每票单子要调用六个外部接口，任何一个慢都会连锁反应。现在再接到“卡顿”投诉，我们会先问“是哪个环节慢”，而不是一头扎进网络里。
还有人员问题。五年里走了两个人，一个去了厂商，一个转行做开发。走的时候我都谈了，原因都是觉得在这里太偏运维、没前途。说实话，这行确实留人难。我现在尽量让每个人每年至少主导一个完整的项目，从前期的客户沟通到后期的验收文档，全流程走一遍。至少以后跳槽能拿出东西来说话。
明年计划就是把配置自动化和变更审批流程打通，别的先不想。能把这一个硬骨头啃下来，就算没白干。
- 想了解更多【工作总结】网的资讯，请访问：工作总结
