工作总结
高级网络工程师工作总结。
核心机房那套设备，运行时间已经累积到六万小时。告警是从去年底开始的，起初是零星的丢包，监控上看就像心电图偶尔抖一下，没引起重视。直到今年三月份，一个周三的凌晨两点，主备引擎倒换，业务会话中断了半分钟。虽然监控平台五分钟内自动恢复了，但第二天上班，运维日志里“连接超时”的记录比平时多了十几条。用户没投诉，但这比投诉更让我警觉。
真正决定动手是在一次例行巡检。我发现光模块的误码率曲线在缓慢爬升，虽然还在阈值内，但趋势不对。查阅设备日志，旧引擎的微码有一个已知缺陷——处理特定厂商的长帧时，会触发硬件转发异常。这问题藏得深，不跑到一定负载量根本看不出来。
替换方案的难点不在技术选型，而在怎么不中断业务。我给出的策略是分步切割。第一步，把两台核心设备从集群里拆开，逐台隔离，确保任何时候都有一条路是通的。这个“拆”的过程本身就有风险，集群分裂如果心跳处理不好，可能两边都以为自己是主。我们提前两周在测试环境模拟了六次，把心跳超时参数从默认的3秒调整到10秒，给链路抖动留出余量。
最麻烦的是策略迁移。新设备ACL资源的分配方式和旧设备不一样，旧设备上三千多条策略，直接灌进去会超限。这事儿我是在预演阶段发现的。那天晚上十一点，配置灌到一半，设备报“资源不足”。当时心里咯噔一下，冷汗都出来了——这要是割接当晚才发现，整个计划全得推翻。我停下来，用脚本把三千多条策略按命中次数排序，排在前面的两百条占了百分之九十的流量，后面的很多是历史遗留。花了两天时间，一条条核对，合并了七百多条冗余条目，把资源占用从百分之九十五压到了百分之五十三。团队里有人觉得我太保守，说有些策略直接删了也没事。我没同意，生产环境，宁可不做，不能做错。
割接定在周六凌晨。周五晚上我又去机房看了一遍，把每一根光纤的标签都对了一次。凌晨两点开始操作，我负责命令行，搭档盯着监控，还有一个人专门负责看变更记录。最紧张的时刻是切换链路那一瞬间——心跳检测正常，路由收敛两百毫秒完成，监控大屏上的曲线平滑过渡。但割接后第四天，财务部的人找来了，说有几台老打印机连不上网络。我去查，发现新设备默认启用了更严格的ARP安全检测，而这些打印机的协议栈实现不标准，发出的ARP报文格式有偏差。我从抓包里看到，正常设备的报文偏移量是0x2C，这些打印机是0x28。临时在接入端口做了针对性放行，半小时恢复。这事儿之后，我把这批老旧设备的MAC地址建了个白名单，统一在接入层做了豁免策略。
这次替换让我意识到一个问题：很多故障不是设备坏了，是设备“太新”了，和旧生态不兼容。后来我们整理了一份“终端兼容性清单”，把市面上常见的打印机、IP电话、门禁控制器都测了一遍，标注哪些设备需要特殊放行。这份清单后来成了新员工入职的必读材料。
网络安全那块，真正触动我改微隔离策略的，是一次季度演练。红队利用钓鱼邮件突破了一台终端，在内网横向移动了三个网段，最后被流量审计发现。虽然判定为“成功防御”，但横向移动持续了将近二十分钟。我翻了防火墙日志，发现很多安全域之间的策略太宽了，“研发”和“生产”之间居然开了所有的TCP端口。
我开始重新梳理隔离策略。以前按物理位置分，现在按业务属性分，把研发、生产、办公拆成十一个子类，每个子类之间默认拒绝，只开必要的业务端口。工作量巨大，光是梳理四百多台服务器的互联关系就花了两周。我写了个脚本，从防火墙的NetFlow数据里提取过去三十天的实际访问记录，生成初始白名单。然后拿着这张表和业务负责人一个一个核对。有个研发负责人一开始不理解，说“你们网络的人别管我们业务怎么通”。我没反驳，把脚本跑出来的记录给他看：“你看，这台数据库服务器过去一个月只被这三台应用服务器访问过，其他端口全开着，等于把钥匙挂在门上。”他看完沉默了，主动配合做了收敛。
策略上线那天，我特意挑了个工作日的下午，因为大部分是拒绝策略，风险可控。切完第一个子类，监控上立刻看到几波异常访问被阻断的告警，都是意料之外的内网扫描流量。有一个是从研发网段发起的，追过去发现是一台测试机被人装了扫描工具，做了几个月的内网探测，我们一直没发现。这事儿在团队里炸开了锅，大家这才意识到，微隔离不光是防御，还是“照妖镜”。
下半年，我开始琢磨怎么把团队的能力短板补上来。起因是一次故障。新来的同事在处理BGP路由震荡时，折腾了两个小时，最后发现是邻居配置的AS号少了一位。他基础不差，但面对生产环境动辄几百条的路由策略，完全不知道从哪儿下手。我后来想，这不是他一个人的问题，是我们缺少把经验沉淀下来的机制。
我开始做三件事。第一，建故障案例库。每次排故完，要求当事人在两小时内写一份“快照记录”，格式不限，但必须回答三个问题：现象是什么、我怎么查的、我当时为什么没想到这一步。有个老同事第一次写，交上来就两行字：“光模块坏了，换了就好。”我没收，让他重写。第二次他写了半页，把排查过程中犹豫的那个点标出来了：“我一开始怀疑是光纤，换了一根没解决，后来才想起来看光功率。”这种“犹豫”的过程，比正确答案更有价值。
第二，设“路由诊所”。每周三下午抽半小时，随机抽一个历史故障案例，所有人模拟排故。不讲原理，只模拟操作。一个人当排故工程师，其他人当观察员，只能看不能说话。最热闹的一次是模拟一个OSPF邻居无法建立的故障，新人上手就去看接口状态，老员工直接敲命令看hello包超时时间。演练完复盘，大家发现每个人排查问题的路径都不一样，互相学了不少小技巧。
第三，推搭档制。复杂变更强制要求两人结对，一人操作一人观察，操作前必须口述即将执行的命令和预期影响。一开始有人抵触，觉得被盯着不舒服。有次一个同事在做路由策略变更时，口述到一半自己发现命令写错了——本来该改前缀列表，他写成了地址族。搭档还没开口，他自己就停了。“这要是直接敲进去，整个BGP邻居就重置了。”那次之后，搭档制再没人抱怨。
这套东西跑了两个月，效果是能看见的。故障平均发现时间从去年同期的四十分钟缩到了二十多分钟，新人独立处理常见问题的周期从三个月压到了一个半月。更重要的是，出故障时大家不慌了，知道该从哪儿查起。
有个周末，数据中心一台汇聚交换机CPU突然飙到百分之九十九，业务大面积延迟。值班的同事打来电话，语气有点急。我到现场，登录设备，发现CPU中断集中在几个特定核心，不是均匀负载。我第一个反应是STP有问题。查生成树拓扑变化记录，果然，最近五分钟收到一百多个TCN报文。顺着MAC地址表追溯，定位到接入层一台新上架的交换机。这台交换机昨天刚上架，配置是我审的，按理说没问题。我登上去看，发现它和上游的链路偶尔闪断，每次闪断就发TCN，导致全网STP重新计算。十分钟定位根因，十五分钟隔离设备，业务恢复。事后分析，如果不是平时在“路由诊所”里反复推演过类似场景，面对这种CPU高但日志里啥也没有的故障，我可能也会先去查环路，走不少弯路。
这一年干下来，我最大的体会是：网络工程师的工作，不是保证设备永远不出错，那是神仙也做不到的事。我们能做的，是在出错的时候，手里有预案、心里有底气，比问题跑得快一点。设备可以换，策略可以改，但真正值钱的，是那些从故障里磨出来的判断力，以及把这些判断力传给后来人的本事。
- 为了您方便浏览更多的工作总结网内容，请访问工作总结
