排障第一响应命令包

故障现象不明确时，先跑一套第一响应命令包，把设备层面的全局视图建立起来，再针对性深入。顺序固定为分层排查：物理层看接口状态与光模块，链路层看错包与地址表，网络层看地址解析与路由，应用层看端口与会话。跳过物理层直接查路由是新手最常见的弯路，因为大量看似三层的故障根因就在接口与链路上。

基本信息

典型使用场景

• 用户报障但描述含糊，需要先建立全局视图
• 多个业务同时异常，判断是共性设备问题还是单点问题
• 变更后业务异常，快速判断是否与本次变更相关
• 值班交接时按同一套命令采集，结果可对比
• 向厂商报障前采集标准信息包，减少来回沟通

华为 VRP

display interface brief          # 物理与协议状态、利用率
display ip interface brief       # 三层地址与协议状态
display cpu-usage                # 处理器占用
display logbuffer                # 最近日志，定位变更与异常时间点
display transceiver interface    # 光模块收发功率（光链路故障时）

思科 IOS

show ip interface brief
show interfaces status           # 二层链路状态与所属 VLAN
show processes cpu sorted        # 处理器占用排行
show logging                     # 日志
show interfaces transceiver

H3C Comware

display interface brief
display ip interface brief
display cpu-usage
display logbuffer
display transceiver interface

分层排查顺序

执行要点

• 先采集再动手：故障现场的数据只有一次机会，清空或重启会永久丢失证据
• 一次只改一处并立刻验证：同时改多项会让因果关系无法判断
• 从下往上查：接口与链路层面确认无误后再进入路由与策略层面
• 对间歇性故障做多次采样：单次快照看不到波动，采样序列才有价值
• 把命令包脚本化：按厂商维护两份脚本，值班时一条命令采集完整信息
• 采集结果归档并标注时间点，便于与日志时间线对齐

常见疑问

• 为什么先看物理层：大量看起来是三层的故障实际来自链路或介质，跳过这一步会绕远路
• 要不要先重启设备：尽量不要，重启会丢失现场证据，也未必解决问题根源
• 单点异常与大面积异常怎么区分：大面积异常优先怀疑共因，例如上联链路或核心设备
• 怎么判断与变更有关：把日志时间点与变更记录对齐比对，是最高效的方式