网络工程师工作计划

凌晨两点，网络机房空调的工程嗡鸣声突然变得刺耳。我盯着监控屏上跳动的师工告警灯，心跳跟着加速——核心交换机的作计一个端口流量飙到了90%。这是网络家制造企业的核心网络，生产系统正跑着MES，工程断一分钟就是师工几十万的损失。我深吸一口气，作计把备用链路切过去，网络然后开始翻日志。工程

这种场景，师工每个网络工程师都懂。作计所谓工作计划，网络不是工程年初写一份PPT交差，而是师工每天都要面对这种突发的、琐碎的、却可能致命的细节。我的计划，从来不是一张时间表，而是一套应对不确定性的逻辑。

先说说日常巡检。我给自己定了个规矩：每天早上八点半，雷打不动看一遍核心设备的状态，包括CPU、内存、端口错误率，还有光模块的收发光功率。别小看光模块，去年夏天一台接入交换机频繁丢包，排查了半天，最后发现是光模块老化，收光功率跌到了临界值。换一个几十块钱的模块，问题就解决了。但如果不巡检，这种问题会积累到某天突然爆发，变成“网络卡顿”的投诉。

巡检不是走过场，得带着问题去看。我习惯把上周的流量基线调出来对比，如果某个端口利用率突然涨了五个百分点，哪怕还在正常范围，也要查清楚是业务增长还是广播风暴。这种“主动找茬”的习惯，帮我提前处理过好几次隐患。有一次，财务部的VLAN里出现了大量未知单播帧，顺着排查，发现是台打印机被植入了恶意脚本，正在扫描内网。这种事，等用户报障就晚了。

再说变更管理。这是我最头疼的部分，也是计划里必须写死的一环。每次要改配置，哪怕只是加一条ACL，我都坚持走流程：先在测试环境模拟，再写回滚方案，最后定在周末凌晨两点操作。有人觉得我太保守，但去年隔壁公司就因为改防火墙规则没备份，导致整个办公网瘫痪了四小时。他们IT主管后来跟我说，当时脑子里一片空白，连原来的配置都找不回来。我不想像他那样。

实际操作中，我会把变更窗口控制在十五分钟内。提前写好脚本，用工具批量下发，然后立刻检查关键业务的连通性。如果发现异常，直接执行回滚，绝不犹豫。这种“快进快退”的节奏，靠的是平时的准备——我维护了一个配置版本库，每次变更前都打快照，出了问题能在一分钟内恢复到变更前状态。

还有个计划里容易忽略的，是跟业务部门的沟通。网络好不好用，不是看延迟多低，而是看用户卡不卡。我每周会花半天时间，去车间和办公室转转，听他们抱怨。上个月，生产部的老张说MES系统偶尔会卡一下，我一开始以为是服务器问题，后来蹲点观察，发现是交接班时上百台扫码枪同时连Wi-Fi，把无线控制器搞懵了。后来我调整了DHCP地址池的分配策略，又给无线控制器加了负载均衡，问题就消失了。这种问题，光看监控数据是发现不了的。

最后说说学习计划。网络技术更新太快，SD-WAN、零信任、自动化运维，你不跟上就落伍。我给自己定的目标是每月拆解一个开源项目，比如用Python写个脚本，自动备份所有设备的配置。这个月刚写完，能省下我每周两小时的重复劳动。说白了，网络工程师的活，一半靠经验，一半靠工具。经验让你知道问题在哪，工具让你快速解决。

凌晨三点，告警终于平息了。我关掉监控，在日志里记下这次事件的原因：一条光纤被施工队挖断了，冗余链路自动切换，但切换时产生了短暂的广播风暴。我边记录边想，明天得跟行政部说一声，下次施工前先通知我。这个计划，又得加一条了。