网络工程师月度工作计划.docxVIP

网络工程师月度工作计划

月初整理上个月的运维日志时，看到故障记录表最后一页的“23:47核心交换机端口环路告警”标记，我揉了揉发酸的后颈——上个月最后一个大夜班的场景还清晰得很。做网络运维这行6年，越来越觉得“计划”二字重如千钧：它不是墙上挂的表格，而是提前把隐患摊开在阳光下，把忙碌变成有序的齿轮转动。这个月，我打算从“守稳基本盘”“啃下硬骨头”“筑牢安全墙”“拧成一股绳”四个方向发力，让团队的网络运维从“救火式”转向“预防性”。具体计划如下：

一、守稳基本盘：夯实日常运维根基

日常巡检、故障响应、用户支持，这三项是网络工程师的“主业”，像housekeeping（家务）一样琐碎却关键。上个月某研发组深夜加班时突发断网，我们排查3小时才发现是旧网线老化导致接触不良——这类问题本可以通过更细致的巡检提前规避。这个月，我要把“日常”做“日常”的功夫做扎实。

（一）优化巡检流程，从“走过场”到“过细节”

细化巡检清单：以往的巡检表只有“设备状态正常”“链路绿灯”这样的笼统项，这个月要拆解到具体指标。比如核心交换机的CPU利用率要控制在40%以下（目前平均35%，但上周四峰值到过58%，得重点关注），接入层交换机每端口流量阈值设为带宽的70%（防止突发拥堵），无线AP的信噪比要保持在-65dBm以上（最近研发区有同事反馈Wi-Fi卡顿，实测部分AP信噪比掉到-72dBm了）。

增加重点时段巡检：除了每天早8点、晚6点的常规巡检，新增“午高峰”（11:30-13:00）和“晚加班”（19:00-21:00）两个时间段的抽查。上个月的断网事故就发生在晚23点，当时值班同事按常规流程已巡检过，但设备发热导致的隐性故障没被发现——多一双眼睛盯着，总能多一分保险。

引入用户反馈联动：在公司内部OA系统开一个“网络问题随手拍”入口，鼓励同事们发现卡顿、延迟时上传截图或描述（比如“下午3点会议室视频会议卡成PPT”）。我们每天下班前汇总这些反馈，和巡检数据交叉比对，精准定位问题点。

（二）提升故障响应效率，从“被动等”到“主动防”

修订应急预案：上个月的“核心交换机端口环路”事故暴露了预案的漏洞——原方案只写了“重启设备”，但实际需要先隔离故障端口再排查。这个月要和团队一起重新梳理3类高频故障场景（交换机死机、无线AP大面积断连、跨网段丢包），针对每个场景列出“前5步操作”（比如交换机死机时，第一步确认是否为电源问题，第二步切换冗余设备，第三步通知受影响部门），避免手忙脚乱。

组建“快反小组”：挑2名经验较丰富的同事组成机动组，日常轮值，遇到紧急故障（如全公司断网）时，10分钟内必须到达现场。上个月的事故中，我一个人既要排查设备又要安抚用户，分身乏术——多个人搭把手，效率能提30%。

建立故障复盘机制：每处理完一起影响超过20人的故障，当天下班前开15分钟小会，用“5个为什么”分析法深挖根源。比如上周测试区丢包问题，表面看是网线问题，深挖发现是施工时工人不小心压到了线槽，再往上是“新装修区域未标记网线走向”的管理漏洞——把这些“根因”记进《故障知识库》，下次遇到类似问题直接调解决方案。

（三）做好用户支持，从“修网络”到“教用网”

很多网络问题是用户误操作导致的，比如私自修改IP地址、用笔记本连接陌生Wi-Fi带病毒进来。这个月打算把“培训”融入支持过程：

每周三下午在茶水间摆个“网络小课堂”摊，用半小时教大家怎么看IP配置（“点右下角网络图标，选‘属性’就能看到啦”）、遇到卡顿先检查哪些地方（“先看电脑网线灯亮不亮，再用ping命令测网关”）；

给各部门秘书发一份《常用网络问题自查清单》，里面画了漫画版流程图（“Wi-Fi连不上？先看AP灯是否正常→不正常找IT→正常重启手机试试”）；

对研发、设计这些用网大户，单独约时间做现场指导，比如教他们怎么用QoS功能优先保障设计软件的流量（“在路由器里把PS、CAD的端口号标记成高优先级，上传素材时就不会卡了”）。

二、啃下硬骨头：推进网络优化升级

公司去年扩了两个研发部，终端设备从300台涨到500台，现有网络架构有点“撑不住”了。上个月做压力测试时，下午3点视频会议高峰期，核心交换机的转发延迟从平时的1ms跳到了8ms，研发同事吐槽“屏幕比嘴慢半拍”。这个月要集中解决三个“卡脖子”问题。

（一）调整网络拓扑结构，缓解核心压力

目前网络是“核心层-汇聚层-接入层”的三层架构，但汇聚层设备太老（都是5年前的H3CS5120），处理能力跟不上。计划：

本周内完成汇聚层交换机的采购比价（倾向于华为S5735S，支持更高密度的10G光口），争取月底前到货；

下周二和厂商工程师开线上会，讨论设备部署方案（重点是冗余链路配置，避免单设备故障导致整层断网）；

部署完成后，把原汇聚层的部分流量分流到新设备，预计核