写在前面
企业 IT 运维里，有一种故障特别容易让人头疼：
全公司突然断网。
老板在群里问：
“全公司都上不了网，现在什么情况？”
财务催着报税，销售催着发合同，业务部门开始不停地问 IT：
“什么时候能恢复？”
这种时候，最容易犯的错误就是冲进机房，然后开始：
重启交换机
↓
重启防火墙
↓
重启 DHCP
↓
重启 DNS
↓
祈祷网络恢复
如果碰巧恢复了，大家都松了一口气。
但过两天问题再次出现，你可能就会发现：
不知道为什么坏，也不知道为什么好了。
更麻烦的是，重启设备以后，部分故障现场和日志可能已经发生变化，反而增加了后续定位难度。
所以，企业网络出现大面积故障时，第一原则不是：
“赶紧重启。”
而是：
“先判断故障范围，再按照网络层级逐层排查。”
本文整理一套我比较推荐的企业网络故障排查思路。
一、先判断：到底是谁断网了？
“公司断网”并不一定真的代表整个公司的网络都坏了。
可能只是：
某一台电脑断网
某个工位断网
一个部门断网
一个 VLAN 断网
所有 WiFi 断网
所有有线网络断网
内网正常，外网断了
IP 正常，但是 DNS 解析失败
所以，第一步永远是确认影响范围。
建议快速找几台不同位置的终端测试
例如：
如果不同部门、有线和无线都同时出现问题，那么基本可以确定：
这不是某一台电脑的问题，而应该从核心网络开始排查。
二、先别重启，保护故障现场
网络设备发生故障以后，建议先保留现有状态。
重点查看：
核心交换机
防火墙
出口路由器
DHCP Server
DNS Server
无线 AC
然后检查：
设备是否在线
CPU 是否异常
内存是否异常
温度是否异常
风扇是否正常
端口是否 Down
上联链路是否正常
最近是否发生配置变更
日志中是否存在异常
如果企业已经部署了 Zabbix、Prometheus、Grafana 等监控系统，也应该第一时间看监控。
例如：
网络设备
↓
Zabbix
↓
发现设备 Down
↓
查看故障时间
↓
与业务反馈时间进行对比
这样通常能够快速判断：
到底是网络设备先出问题，还是某项业务先出问题。
三、第一层：物理层
网络排查最基础的一层，就是：
物理层。
虽然看起来很简单，但实际生产环境中，很多网络故障最后确实是由这些基础问题引起的。
建议先检查：
UPS
PDU
电源线
网络设备电源
光模块
光纤
网线
交换机端口
设备风扇
设备温度
3.1 先看核心交换机
进入机房以后，不要马上拔电源。
先观察：
电源状态
↓
设备指示灯
↓
管理口
↓
Console
↓
端口状态
↓
设备日志
如果核心交换机完全没有响应，再进一步判断：
供电是否正常？
↓
UPS/PDU 是否正常？
↓
设备电源是否正常？
↓
设备是否硬件故障？
如果设备可以正常登录，则继续查看：
CPU
内存
温度
风扇
端口
上联
ARP
MAC
STP
日志
3.2 运营商链路也不要忘记
如果公司网络架构类似：
Internet
│
▼
运营商
│
▼
光猫 / 专线设备
│
▼
防火墙
│
▼
核心交换机
│
▼
接入交换机
那么运营商设备也应该检查。
例如光纤设备出现：
LOS
红灯通常意味着光信号存在异常。
这种情况下，如果确认是运营商线路问题，应该直接联系运营商处理，而不是一直在公司内部折腾交换机。
四、第二层：检查 DHCP
如果核心设备、交换机和物理链路都没有明显问题，那么下一步建议检查：
客户端有没有拿到正确的 IP 地址。
Windows：
ipconfig /all
Linux：
ip addr
ip route
重点关注：
IP Address
Subnet Mask
Default Gateway
DNS Server
DHCP Server
五、看到 169.254.x.x，不要直接认定 DHCP 挂了
这是企业网络排查中一个非常经典的误区。
如果 Windows 获得类似：
169.254.x.x
通常说明系统没有成功获得 DHCP 分配的正常地址，Windows 自动使用了 APIPA 地址。
但这并不能直接证明：
DHCP Server 挂了。
因为 DHCP 的链路实际上可能是：
客户端
│
▼
接入交换机
│
▼
VLAN
│
▼
核心交换机
│
▼
DHCP Relay
│
▼
DHCP Server
任何一个环节出现问题，都可能导致客户端最终拿不到 IP。
所以应该继续向上排查。
六、检查 DHCP 地址池
登录 DHCP Server 后，重点查看两个问题。
1. DHCP 服务是否正常
Linux 环境可以查看：
systemctl status dhcpd
如果使用其他 DHCP 服务，则检查对应服务状态。
2. 地址池有没有耗尽
例如：
192.168.10.100
-
192.168.10.200
整个地址池只有约 100 个地址。
但如果公司实际上存在：
电脑
手机
打印机
AP
会议室设备
服务器
IoT设备
那么地址池可能很快被消耗完。
所以企业环境建议对 DHCP 地址池建立监控。
例如：
地址池使用率 > 70%
↓
预警
地址池使用率 > 85%
↓
告警
这样可以在真正影响员工之前提前处理。
七、别忘了 DHCP Relay
大型企业网络通常不会把 DHCP Server 放在每一个 VLAN 里。
例如：
VLAN 10
192.168.10.0/24
VLAN 20
192.168.20.0/24
VLAN 30
192.168.30.0/24
DHCP Server 可能统一部署在：
192.168.100.10
那么不同 VLAN 的 DHCP 请求就需要通过 DHCP Relay 转发。
如果 Relay 配置错误：
客户端
↓
VLAN
↓
核心交换机
X
DHCP Relay
↓
DHCP Server
最终结果依然是：
客户端拿不到 IP。
因此：
DHCP 故障 ≠ DHCP Server 故障。
这是排查企业网络时非常重要的一点。
八、第三层：DNS
假设现在客户端已经获得正常 IP：
IP：192.168.10.125
Mask：255.255.255.0
Gateway：192.168.10.1
DNS：192.168.100.10
那么继续测试。
首先测试网关：
ping 192.168.10.1
如果网关可以访问，再测试 DNS：
nslookup baidu.com
Linux 可以使用：
dig baidu.com
九、企业环境不要随便把 DNS 改成公网 DNS
遇到 DNS 故障，有些管理员第一反应是：
114.114.114.114
223.5.5.5
8.8.8.8
作为临时诊断手段没有问题。
但如果企业存在：
AD域
内部DNS
GitLab
OA
文件服务器
内部应用
监控系统
那么直接让员工终端全部使用公网 DNS，就可能导致内部域名无法解析。
企业 DNS 更合理的结构应该是：
员工终端
│
▼
企业 DNS
│
├── 内部域名
│
└── DNS Forwarder
│
▼
公网 DNS
所以：
公网 DNS 可以用来辅助判断 DNS 问题，但不能简单替代企业内部 DNS。
十、第四层：测试默认网关
如果客户端 IP 正常，继续：
ping 默认网关
例如：
ping 192.168.10.1
如果：
客户端 → 网关
不通，那么问题重点应该放在：
网卡
↓
网线
↓
接入交换机
↓
VLAN
↓
Trunk
↓
核心交换机
↓
网关接口
而不是继续研究 DNS。
这就是网络分层排查的意义。
十一、第五层：测试公网连通性
如果：
客户端
↓
默认网关
全部正常，可以继续测试公网 IP。
例如：
ping 8.8.8.8
或者使用：
tracert 8.8.8.8
Linux：
traceroute 8.8.8.8
需要注意：
公网 IP Ping 不通，并不能直接证明运营商线路故障。
因为 ICMP 可能被：
防火墙
路由器
上游网络
目标服务器
限制。
所以需要结合：
WAN接口
默认路由
NAT
防火墙策略
线路状态
流量监控
综合判断。
十二、如果 IP 通，但是网页打不开
这种情况重点检查：
DNS 和应用层。
先：
nslookup www.baidu.com
再：
ping www.baidu.com
Linux 可以进一步：
dig www.baidu.com
以及：
curl -I https://www.baidu.com
这样就可以把“上不了网”进一步拆解成：
IP层
↓
DNS
↓
TCP
↓
HTTPS
↓
应用
而不是笼统地认为：
“网络坏了。”
十三、别忘了检查防火墙
如果：
物理层正常
DHCP正常
DNS正常
网关正常
但是公网仍然无法访问，就应该开始检查出口防火墙。
重点关注：
WAN接口
默认路由
NAT
安全策略
ACL
会话数
CPU
内存
流量
尤其是：
最近有没有人修改过防火墙策略。
例如：
昨天
修改了一条出口 ACL
今天
全公司无法访问 Internet
那么这就是非常重要的排查线索。
十四、网络故障中，“最近改了什么”非常重要
企业网络故障排查时，我非常喜欢问一个问题：
“最近有没有改过东西？”
例如：
有没有调整 VLAN？
有没有修改防火墙？
有没有增加交换机？
有没有修改 DHCP？
有没有新增 AP？
有没有调整 DNS？
有没有更换光模块？
有没有升级网络设备？
有没有进行网络割接？
如果故障发生时间与网络变更时间高度吻合，那么：
变更记录就是非常重要的排查依据。
所以企业网络最好建立简单的变更管理制度：
不要让生产网络变成：
“谁改的没人知道。”
十五、如果出现异常流量，要考虑安全事件
如果发现出口流量突然异常：
正常
██████████
异常
████████████████████████████
同时出现：
大量连接
大量扫描
异常外联
DNS 请求暴增
单台主机持续产生大量流量
防火墙连接数异常
那么就不能简单按照普通网络故障处理。
需要进一步判断是否存在：
DDoS
恶意扫描
病毒传播
终端感染
异常外联
防火墙资源耗尽
例如：
某台内网电脑
↓
持续访问大量公网 IP
↓
连接数暴增
↓
出口带宽被占满
↓
员工感觉“全公司断网”
这种情况下，真正的问题可能并不是交换机。
十六、故障无法马上恢复怎么办？
IT 运维还有一个非常重要的能力：
业务应急。
如果确认短时间无法恢复，可以考虑启用备用网络。
例如：
主互联网
│
X
│
└──── 故障
备用 5G / 4G
│
▼
备用路由器
│
▼
防火墙 / 核心网络
│
▼
核心业务
企业可以提前准备：
4G/5G CPE
备用路由器
第二条互联网线路
手机热点
备用交换机
备用光模块
但建议建立明确的：
应急网络方案
而不是临时找一个路由器插上就开始救火。
十七、不要试图一次恢复所有业务
网络出现重大故障时，可以按照业务重要程度逐步恢复。
例如：
P1：核心业务
财务
核心生产系统
核心服务器
业务系统
P2：重要办公
OA
邮件
文件服务器
视频会议
P3：普通办公
普通 Internet
非核心应用
其他办公需求
这样做的目的不是区别对待员工，而是：
当资源有限时，优先保证企业核心业务能够继续运行。
十八、把整个排查过程总结成一张图
以后再遇到：
“全公司断网！”
可以按照下面的顺序排查：
全公司断网
│
▼
① 确认影响范围
│
▼
② 检查物理层
│
┌────────┴────────┐
│ │
异常 正常
│ │
▼ ▼
电源/链路/设备 ③ 检查 DHCP
│
▼
是否获得正常 IP？
│
┌──────────┴──────────┐
│ │
否 是
│ │
▼ ▼
DHCP / Relay / VLAN ④ 测试网关
│
▼
网关是否正常？
│
┌──────────┴─────────┐
│ │
否 是
│ │
▼ ▼
VLAN/交换机 ⑤ 测试公网
│
▼
⑥ DNS测试
│
▼
⑦ 防火墙/NAT
│
▼
⑧ 运营商线路
这张图其实就是整篇文章最核心的东西：
不要跳着排查。
十九、30分钟企业断网应急 SOP
如果把上面的内容进一步压缩，可以形成一张真正可以放在 IT 值班室里的 Checklist。
同时记录：
故障开始时间：
故障发现时间：
影响范围：
初步现象：
排查过程：
最终故障点：
临时解决方案：
最终解决方案：
网络恢复时间：
根本原因：
后续整改措施：
二十、真正成熟的 IT，不只是“会修”
一次网络故障处理完成以后，真正应该做的事情其实才刚开始。
例如：
DHCP 地址池不足
临时解决：
扩大地址池
长期整改：
DHCP地址池监控
+
使用率告警
+
IP地址规划
核心交换机单点故障
临时解决：
更换设备
长期整改：
双核心
+
堆叠 / MLAG
+
双上联
+
双电源
+
UPS
+
备用设备
运营商线路中断
临时解决：
启用5G备用线路
长期整改：
主线路
+
备用线路
+
5G应急链路
最终形成：
监控
↓
告警
↓
排查
↓
应急
↓
恢复
↓
复盘
↓
整改
这才是一套真正成熟的企业 IT 运维体系。
最后
企业网络出现故障时，最怕的不是不知道命令。
真正可怕的是：
还没有找到问题，就开始修改配置。
网络故障排查其实和看病很像：
先判断症状
↓
确认影响范围
↓
检查基础设施
↓
逐层排查
↓
定位故障
↓
处理问题
↓
验证恢复
↓
分析根因
↓
整改
所以以后再遇到老板在群里问：
“全公司怎么都没网？什么时候能恢复？”
不要急着回答：
“马上！”
更专业的做法是先告诉他：
“目前确认影响范围为全公司，核心网络设备在线，正在排查 DHCP、DNS 和出口链路，第一轮定位预计 10 分钟完成。”
因为对于企业 IT 来说：
专业的价值，不只是把网络修好，而是知道网络为什么坏、怎么快速找到问题，以及如何让同样的问题不再发生。