晚上八点多，线上交易断了近一小时，数万条请求被重复下发，客户投诉炸开了锅。查出来不是被人搞了啥大动作，而是一堆配置和设计上的疏漏叠加在一起，最后把整个网络的协议、地址、转发和运维短板都暴露出来。下面按时间线和模块把事儿讲清楚，细节别省，谁干了啥、哪儿出问题都会交代。
最先冒出来的问题是协议和地址这一层。现场日志显示同一批机器同时收到了两套DHCP的Offer，IP冲突不断。有人把公网边界的BGP邻居写错了AS号，对端于是撤路由，部分网段瞬间不可达。说白了就是基础配置没管严：DHCP作用域没隔好，DHCP Relay乱设；边缘路由器的BGP邻居和prefix-list也没校验。IPv6方面也没统一规划，设备上到处用临时地址，监控探针对不上主机ID。排查时还能看到痕迹：DHCP短时间发出大量Offer，但Request很少，说明客户端收到多个回复在犹豫；BGP会话一会儿建一会儿掉，路由表在抖动。真让人无语的是配置里还有老脚本残留，静态路由和动态路由优先级没弄清楚，路由回流和NAT翻译表相互干扰，流量走向被打乱。emm，这都能丢。
用户面那头，数据包走的路远比想象复杂。请求进来要过边缘防火墙、负载均衡器，再分给几个后端集群。此次故障里，负载均衡器的健康检查策略太宽松，有个后端服务挂了但仍被判定为可用，大量请求就打到不可用实例，产生重传和超时，放大了网络层问题。再看转发路径，防火墙和交换机之间的VLAN/ACL配置不一致，跨VLAN流量被打回；部分交换机的TCAM表项满了，新流量没法写到硬件转发表，只能掉回软件，性能直接降。整个典型路径是：客户端→边缘路由→防火墙→L4负载均衡→后端交换机→应用实例。任何一处出问题都会连锁，这次是多点同时掉链子。
网络规模扩大后，老的地址规划撑不住。公司从单机房扩到多机房、跨区域，但IP规划没按扩展规则重新划分，结果路由表膨胀，路由通告零散，BGP表项多，收敛慢。查出有些子网缺乏汇总路由，核心路由器里堆了上百条细粒度路由，一旦邻居波动，整个网络得花时间重新收敛，服务就掉链子。还有老设备长期占静态IP，但没记录在资产库里，IP冲突调查变得像破案。NAT过度依赖端口映射，出口地址池不够，出现端口耗尽。扩容计划零碎执行，子网划分不按可扩展性来，短期能顶，长期会出问题。
终端和应用也没做好配合。许多客户端和中间件缺乏退避策略，超时就疯狂重试，瞬间把后端压垮。应用日志显示短时间内大量重复请求，消息队列堆积。监控阈值设置不当，有报警触发却被静默规则吞掉，值班没拿到可操作的提示。运维流程也乱：排查没有标准流程，团队靠群里碎片化沟通，出现重复操作和误操作。有人在没和人确认的情况下重启了部分路由器，结果BGP邻居一度崩了，反而把问题扩大了。好在事后我们抓了完整的事件流：每台设备的配置变更、操作时间和责任人都有记录。临时补救措施也做了——回滚部分配置、扩充DHCP作用域、清理冗余路由、收紧负载均衡健康检查、在关键链路上打开流量镜像帮定位。后面会把变更单和日志贴上，先到这里。
暂无评论内容