机房故障处置手册：从磁盘到 SDN 控制器的根因、预防与规章

机房里的故障，大多数不是"突然发生"的，是"早就埋下"的：盘会先坏道再失效，链路会先闪断再中断，配置会先漂移再爆发。这篇文章按我日常处理的场景，把每个故障的根因、识别方法、处置规章（SOP）和预防动作写清楚。

命令以 Linux、ESXi、Ceph、华为/华三交换机为主，其他设备（深信服、ZStack、FusionCube、UIS 这类超融合，以及阿里云/华为云/华三云）命令不同但思路一致，按同类逻辑替换。

开篇两条总则，所有场景都适用：

1. 处置前先定性：是"硬件断了""链路抖了"还是"配置漂了"。方向定错，后面步骤全白费。
2. 数据面和物理层的操作（删卷、换盘、拔线、重启节点）必须人确认执行。AI Agent 在这里只能当只读助手——它负责采集、关联、给方案，永远不直接动手。每节末尾单独说明它到底能帮到哪一步。

#速查表：先定位场景，再读 SOP

#一、AI Agent 是怎么"看到"机房的：五类状态的数据通道

讲各场景之前，先把一个前置问题讲透：AI Agent 不是会穿墙的超人，它能看到什么，完全取决于你给它放通了什么只读通道。 机房里有五类状态要看——物理机、虚拟机、虚拟交换机、存储、网络设备，每一类的数据通道都不一样，下面分别说清楚：数据从哪来、用什么命令/接口拿、能拿到什么、拿不到什么（这是边界）。

#1. 物理机：硬件和系统状态

物理机有两条独立通道，必须分开讲：

带外通道（BMC/IPMI/Redfish）——不依赖操作系统，服务器插着电就能看。硬件状态（电源、风扇、温度、传感器、硬件告警）都在这：

# IPMI 只读查看传感器和 SEL 事件日志
ipmitool sensor list
ipmitool sel elist

# Redfish 是带外的 REST 接口，机型新一点的服务器都有
curl -k https://<bmc-ip>/redfish/v1/Systems/1

带外的好处：OS 挂了、系统盘坏了，它照样能报。这是"服务器失联"时唯一还能说话的通道。

带内通道（主机 Agent / SNMP）——看的是操作系统层面：CPU、内存、磁盘 IO、进程、网卡状态。常见实现是 node_exporter、zabbix agent、telegraf 这类采集器把指标吐出来，AI 定时拉取：

curl http://<node>:9100/metrics | grep -E "node_cpu|node_memory|node_disk"
snmpwalk -v2c -c <ro_community> <node> 1.3.6.1.2.1.25   # HOST-RESOURCES-MIB

边界：带内通道依赖 agent 存活，agent 挂了 AI 就失明一半；带外通道看不到 OS 层。所以正确做法是两条都接，关键节点（存储节点、超融合节点）甚至要多一条"心跳探活"，AI 判断"节点失联"时才分得清是主机硬件挂了还是 agent 问题。

AI 能帮到哪一步：定时合并两条通道——"带外正常但带内失联"→ 大概率是 OS 或 agent 问题；"带外也报电源告警"→ 直接定位硬件。边界：拿到的是传感器的值，不是"这块板卡内部哪颗电容坏了"，最终定位还要靠硬件厂商工具。

#2. 虚拟机：状态从平台 API 来

虚拟机的状态不在"虚拟机里"，在虚拟化平台里。AI 看虚机，走的是平台的管理 API：

# vCenter / ESXi：走 SDK/REST（govc 是常用的只读命令行封装）
govc vm.info /datacenter/vm/db-01     # power state、内存、CPU、磁盘、网络

# 超融合管理面：各家都有自己的 API（FusionCompute、UIS、ZStack 等）
# 云平台：阿里云/华为云/华三云走 OpenAPI 只读接口，字段一致
# KVM/libvirt：virsh list --all / virsh dominfo <vm>

AI 能拿到的关键字段：power state（开机/关机）、connection state（平台还能不能连上它）、CPU/内存的实时与配置值、虚拟磁盘列表、网络端口与 VLAN。

边界：平台 API 看到的是"虚机对象"，看不到虚机内部——里面的进程、系统负载、应用状态，平台不知道。要看内部，得靠 guest agent（VMware Tools、qemu-guest-agent）或 SSH 只读账号，这是另一条通道，权限和位置都要单独规划。AI 最常犯的错就是拿平台 API 说"虚机正常"，其实内部早已 OOM——所以要分清"平台视角"和"客户机视角"，两个都要看。

AI 能帮到哪一步：批量拉全量虚机状态做对照（哪台该开没开、哪台 CPU 超分明显），出问题时把"平台断电"和"客户机无响应"两类失联分开定性。边界：虚机内部诊断靠 agent 通道，没装 agent 的虚机 AI 只能看到外壳。

#3. 虚拟交换机：状态要"意图层 + 数据面"两份一起看

虚拟交换机（vSwitch / vDS / OVS）有一个容易踩的坑：配置在管理面，转发在每台宿主机的内核里。AI 要看两层：

# 意图层：vCenter 里的分布式交换机配置（端口组、VLAN、上行）
# 走 vCenter API；ESXi 单机用 esxcli
esxcli network vswitch standard list   # 标准交换机端口组/上行
esxcli network vswitch dvs vmware list # 分布式交换机

# 数据面：每台宿主机内核里实际转发的端口状态、流量计数
esxcli network port list
# OVS 场景（KVM 超融合常见）：
ovs-vsctl show         # 网桥、端口、tunnel、VLAN 实际配置
ovs-ofctl dump-ports br-int   # 端口的实际收发统计

核心判断：意图层说"这个端口组 VLAN 100 有 4 个物理上行"，数据面说"只有 2 个上行 up"——这两份不一致就是故障根因。AI 看虚拟交换机的价值，就是把这两份状态并排对比，而不是只看管理界面。

边界：每台宿主机各有一份数据面状态，AI 要么逐台拉（慢），要么靠 vCenter/控制器聚合（部分信息会丢失）。vDS 场景下，业务虚机端口的信息在 vCenter 里有，但实际流量统计分散在各宿主机——目前没有哪个单一接口能同时给全，这就是为什么"虚机网络报障"不能只问 AI 一个问题，要让它跑五层快检（见第 12 节）。

AI 能帮到哪一步：定期抓"意图 vs 数据面"差异，把"端口组配置好了但宿主机上行没起来"这类管理面看不出来的问题提前暴露。边界：流表级的瞬态问题（OVS 流表老化、哈希冲突）需要抓包和流表 dump，AI 只能给线索，定位靠人。

#4. 存储：状态要从"存储自己的眼睛"里拿

存储状态不能靠猜，要靠存储系统自己的管理面：

# 分布式存储（Ceph、超融合内置分布式存储、云存储）
ceph -s                              # 集群整体健康
ceph health detail
ceph osd tree                        # 节点/OSD 分布

# 集中式存储阵列（华为 OceanStor、H3C 存储等）：走厂商管理 API/CLI 只读
# 超融合管理面：统一看存储池、副本、容量、重建任务

# 主机侧存储视角（AI 也要会看，和存储侧对照）
multipath -ll                        # 多路径状态
lsblk                                # LUN 映射到哪个盘

关键认知：存储状态有三个视角——存储管理面（存储自己认为的健康）、网络（链路/路径是否正常）、主机（LUN 是否被正确识别）。一个存储故障，三个视角的症状往往不一样，AI 的价值就是把三份"证词"放一起找交集。上一章的分布式存储、多路径章节，用的就是这三份数据。

边界：存储阵列内部的控制器日志、盘位、RAID 组状态，只有厂商管理面有，且部分厂商只开放 GUI、不开放 API——这种情况下 AI 只能靠 SSH 只读执行厂商 CLI 或人工导入，接不接得进来要看厂商接口开放程度和你的只读账号权限。

AI 能帮到哪一步：把"存储报链路降级 + 主机 multipath 少一条路径 + 交换机口错包"三份数据对齐，直接指向故障段（哪条链路/哪个端口）。边界：存储阵列内部的固件级诊断，AI 最多引用厂商告警，解释要靠厂商工具和资料。

#5. 网络设备：状态几乎全靠北向接口和只读命令

网络设备（交换机/路由器/防火墙）没有"agent"，状态获取靠三类手段：

# ① SNMP 只读（最通用，华三/华为/思科都支持）
snmpwalk -v2c -c <ro> <switch> 1.3.6.1.2.1.2.2.1.2   # 接口表
snmpwalk -v2c -c <ro> <switch> 1.3.6.1.2.1.1.3.0     # 运行时长
# 接口状态、流量、温度、电源、风扇都在各个 MIB 里，按需放通

# ② 北向接口：NETCONF/gNMI（新设备）、REST API（部分中高端）
# 华三、华为的管理面现在都支持 NETCONF 只读取配置和状态

# ③ SSH 只读执行 display 命令（兜底方案）
ssh <ro-user>@<switch> "display interface brief"
ssh <ro-user>@<switch> "display device"     # 电源/风扇/温度状态

网络设备的情况是：大部分老设备只有 SNMP 和 SSH display 命令可用，没有现成的结构化 API。所以 AI 接网络设备，通常要做一层"命令/SNMP 结果 → JSON"的适配，这就是为什么网络侧接入比其他侧成本高。

边界：SNMP 能拿到的是 OID 里有的东西，很多设备的管理面内部状态（转发芯片、ACL 命中、CPU 各进程占用）不暴露在 MIB 里；SSH 只读执行 display 也有个隐患——高负载时登录设备本身会抢资源，AI 巡检频率不能太高，要有节流。网络设备的"完整状态"，AI 永远看不到数据面转发芯片那一层，这是物理边界。

AI 能帮到哪一步：把 SNMP 轮询 + display 命令 + syslog 三路汇合，做全设备接口基线、告警聚合（见第 8 节）。边界：只读权限放通多少 OID/命令，AI 就看到多少；转发芯片级问题它拿不到数据，只能靠现象推断。

#小结：五类状态怎么"喂"给 AI

统一起来就一句话：AI 看到机房 = 定时拉取（轮询）+ 事件推送（syslog/trap/告警）+ 按需查询（SSH/API）。

• 物理机/存储：拉取为主，外部指标和硬件状态都能拿到，关键是两条通道都接。
• 虚拟机/虚拟交换机：平台 API 给的字段够用，但"客户机内部"和"数据面"要另想办法。
• 网络设备：SNMP + display 命令兜底，接入成本最高，能拿到的是"放通的 OID/命令"的范围。

所以在机房里谈 AI，先别问"它能干什么"，先问"你给它放通了哪几条通道"。通道越全，AI 能关联的层越多；通道有盲区，AI 就会把盲区当成"正常"，这是它所有误判的共同来源。

#二、存储与计算侧

#1. 磁盘故障

#根因

• 机械盘：磁头/盘片老化，坏道扩散；震动、散热不良会加速。
• SSD：NAND 写寿命（PE）耗尽、意外掉电导致映射表（FTL）损坏、固件缺陷直接掉盘。
• 附加因素：RAID 卡 BBU（电池）失效后写缓存降级为 write-through，性能暴跌甚至引发掉盘；供电不稳。

#识别

先看系统日志：

journalctl -k | grep -iE "I/O error|medium error|sd[a-z].*failed"

再看 SMART 属性：

smartctl -a /dev/sdb | grep -E "Reallocated_Sector|Current_Pending|UDMA_CRC|Wear_Leveling|Media_Wearout"

• 机械盘：Reallocated_Sector_Ct（重映射扇区）持续上涨、Current_Pending_Sector（待重映射）出现 → 坏道在恶化，早换早好，别等它变红。
• SSD：Media_Wearout_Indicator 接近 0、或 Wear_Leveling_Count 异常 → 寿命到头。
• RAID 卡：MegaRAID 系用 storcli /c0/eall/sall show，Drive State 出现 Failed，或者 rebuild 反复中断。

#处置规章（SOP）

1. 定性：盘是"已断"（I/O error、SMART 严重、RAID 报 Failed）还是"将死"（重映射扇区涨、Pending 增多）。已断直接走更换流程；将死评估窗口，能扛到维护窗口就扛，扛不住就换。

2. 评估影响面：这块盘承载什么——分布式存储的 osd、直通盘、还是系统盘。副本还剩几份直接决定紧迫程度：

   复制

   ceph osd tree        # 看 osd 状态
   ceph health detail   # 看 degraded / remapped

3. 隔离：RAID 阵列里将坏盘下线；osd 先 ceph osd out <id>，等 rebalance 完成再动物理盘。

4. 换盘重建：插入新盘触发 rebuild / ceph osd create，监控重建速率和 PG 恢复，别让恢复拖垮业务。

5. 验证：健康回 green、无残余告警、性能回落基线。

#预防

• 每周跑一遍 SMART 巡检（脚本化），坏道趋势比单次告警值有用。
• RAID 卡开启 Patrol Read（预读巡检），BBU 例行健康检查。
• 环境：散热、防震、供电稳定。
• 常备同型号备件，超融合/存储节点的目标应该是"故障盘 48 小时内能换上"。

AI 能帮到哪一步：把"盘报错 + 副本降级 + 重建速率"合并成一条结论，并提醒你先查网络再决定换盘。但它不知道这块盘是不是集群里仅剩的冗余、备件在不在库、今晚能不能动业务——这些都要人拍板。

#2. 慢盘

#根因

• 坏道/磨损还没到告警阈值，盘"半死"：数据能读能写，就是慢。
• SSD 写放大、固件降速（过热或擦写压力）。
• 同盘 IO 竞争；RAID 卡缓存策略没开写缓存。
• 注意区分：慢盘 ≠ 慢链路。多路径故障、存储控制器固件问题也有同样症状，定位范围前别急着下结论。

#识别

iostat -x 1 5
# 重点看 await：持续 >100ms 基本可判慢盘
# await 和 svctm 的差越大，说明 IO 在排队，不是"盘快"，是"盘在拖"
iotop -o        # 哪个进程在打这块盘

业务侧表现：数据库延迟突刺、某台虚机 IO 卡但 CPU 正常、监控面板一切正常。

#处置规章（SOP）

1. iostat -x 1 定位到具体盘。
2. 判断范围：单盘慢，还是同控制器/同链路都慢？对比同控制器其他盘、同链路其他主机的延迟——这一步用来排除链路和控制器因素。
3. 迁移数据/漂移虚机，观察慢盘影响是否收敛，确认根因就是盘。
4. 确认后按磁盘故障流程隔离更换。

#预防

• 建立 IO 延迟基线：每节点每周量一次。慢盘从出现到爆发通常有 2-4 周窗口，超过基线 2 倍就预警，能抢在业务故障前处理。
• SSD 容量水位控制在 80% 以内，高水位写放大明显。
• 统一 RAID 卡缓存策略、开启掉电保护。

AI 能帮到哪一步：慢盘是 AI 做例行巡检最划算的场景——它能量化 await 分布、自动和基线对比，比人翻监控实用得多。边界：慢盘根因也可能在控制器固件或链路，AI 建议"换盘"前，人必须用第 2 步（范围判断）复核一次。

#3. 分布式存储

#根因

• 单盘/单节点故障触发副本重建。
• 网络抖动——分布式存储的所有副本流量都走网络，网络一抖，重建慢、业务卡。
• 节点心跳超时：CPU 满载、内存压力、时钟漂移（NTP 没配）。
• 容量水位高：接近满的池，任何动作都慢。
• scrub、rebalance、快照备份和业务抢 IO。

#识别

ceph -s                  # 总体健康
ceph health detail       # 具体问题
ceph osd tree            # 节点/osd 分布
ceph pg dump | awk '/active\+clean/{ok++} /degraded/{d++} END{print "clean", ok, "degraded", d}'

超融合自带的分布式存储（FusionCube、UIS、深信服、ZStack）把这些搬进了管理面，核心逻辑就三项：副本、重建、容量。

#处置规章（SOP）

1. ceph health detail 定性：是数据面问题，还是节点/网络问题。

2. 盘点 PG 状态：多少 degraded、peering、stuck。

3. 先查网络：重建速率上不去，八成是副本流量在丢包。看恢复速率的同时，查交换机端口错误计数：

   复制

   ceph -w | grep -E "recovery|backfill"

4. 控制重建速率，别让恢复拖垮业务：

   复制

   ceph config set osd osd_max_backfills 1
   ceph config set osd osd_recovery_max_active 1

5. 根因处理后把速率调回，验证回 green。

#预防

• 容量水位 70% 告警，85% 强告警。
• 节点 NTP 统一；内存/CPU 水位监控。
• 存储网络冗余（双上联、多路径），别让"单点链路"成为隐藏瓶颈。
• scrub、备份排程错开业务高峰。
• 维护操作（换节点、重启）走标准流程，避免触发连锁重建。

AI 能帮到哪一步：跨层关联是它的主场——"osd down + 交换机丢包 + 重建慢"本来要开三个系统才能拼起来，它直接给结论。边界：osd in/out、调整权重、缩减副本这类数据面动作，永远由人执行。

#4. 多路径故障

#根因

• HBA 卡/网卡故障、光模块劣化、光纤/网线质量、存储端口故障、存储网络交换机故障。
• 路径策略误配：active/passive 切换失败、负载策略异常。

#识别

# Linux
multipath -ll
# 看每块盘的 path state：active / failed / pending

# ESXi
esxcli storage nmp path list
# Runtime Name 对应的 State：active / dead / standby

关键认知：冗余路径挂一条不会报警，业务也没断——但你的冗余已经减半了。 看"业务没断"没用，要看"路径还剩几条"。

#处置规章（SOP）

1. multipath -ll 盘点健康路径，确认冗余是否还在。
2. 定位故障段：主机 HBA/网卡 → 线缆/光模块 → 存储端口/交换机，逐段看（ethtool、光衰、display interface、存储面板端口状态）。
3. 修复后验证 path 恢复（重新扫描：multipathd reconfigure）。
4. 红线：拔线、换纤、重启 HBA 前，必须确认还有健康路径可用——否则等于亲手把自己唯一的冗余干没。

#预防

• 定期 path 巡检（脚本化 + 告警：任何路径 failed 就要报，别等第二条也断）。
• 双路径走不同 HBA、不同交换机，故障域隔离。
• 光衰巡检；线缆标签和配线表随变更维护。

AI 能帮到哪一步：最有价值的是"没有告警时发现 degraded path"——冗余悄悄少了一条，它定期比对路径数并预警，这活人做容易漏。边界：物理插拔、链路更换永远是人的责任，AI 只负责告诉你"该动手了"。

#5. 超融合集群重启

#为什么顺序是命门

断电检修、版本升级、硬件维护都要重启。风险不在"重启"本身，在顺序：

• 停机顺序反了（先断电）：分布式存储来不及把数据写完整，重启后一堆副本要恢复，甚至数据不一致。
• 启动顺序反了：集群起不来，或者 quorum 不满足出现"无主"，虚机恢复困难。

#处置规章（SOP）

停机顺序：

1. 业务虚机优雅关机（数据库先 stop 服务，再关机）。
2. 存储服务进入维护/停止迁移动作。
3. 节点关机（保留仲裁/多数派到最后关）。

启动顺序（重点）：

1. 存储服务/控制器先起，确认存储池 active。
2. 管理面起来。
3. 节点逐台起来，等集群 quorum 满足。
4. 存储池验证：副本数、容量、健康。
5. 虚机按依赖顺序启动（见第 7 节）。

重启后验证清单：每节点存储服务状态、存储池 active、副本健康、虚机状态、虚拟交换机上行链路、与外部网络连通性。

#预防

• 每季度做一次重启演练，把顺序文档化、脚本化。
• UPS 容量覆盖节点+存储+网络设备；电源双路。
• 弄清集群仲裁/防脑裂机制，知道哪台节点必须"最后断电、最先上电"。

AI 能帮到哪一步：生成停机/启动顺序清单，重启后自动跑验证脚本并汇总结果。边界：执行重启、确认业务窗口、现场断电，都是人的事——AI 再熟流程，也不知道机房电闸在哪。

#6. 存储操作（扩容、加盘、删卷）

#规章

存储操作比故障更需要规章，因为它坏在"你亲手做的"：

1. 备份元数据：删卷、缩容前必须先确认快照/备份。
2. 确认余量：容量、IOPS、副本数都够，再动手。
3. 避开业务高峰：回收、精简、压缩、重平衡全是 IO 大户。
4. 操作后验证：卷可见、主机识别、性能正常。
5. 破坏性操作（删卷/格式化）必须双人确认——这条不商量。

#预防

• 变更评审制度：小变更也要记录，便于回溯。
• 模板化操作：加盘、扩容按固定脚本/步骤走，减少手误。
• 定期演练恢复（从备份恢复卷），别等真出事才第一次试。

AI 能帮到哪一步：生成"变更预案 + 影响面清单"（哪些虚机/业务挂在这个卷上），减少漏项。边界：删、格式化、缩容这类动作，人在确认 + 双人复核后执行，AI 不直接碰。

#7. 虚机启动顺序

#根因

• 虚机之间有依赖：数据库 → 中间件 → 应用 → 负载均衡。
• 存储/网络未就绪就启动：应用起来了，连不上数据库。
• 一次性全量启动：存储瞬时压力过大，可能再次抖动。

#处置规章（SOP）

1. 维护一张依赖清单：哪台依赖哪台、起来后验证什么。
2. 逐层启动：先数据库（等存储 + 心跳网络就绪），验证可连接后再起中间件，最后应用和 LB。
3. 每层验证：网络通、存储就绪、关键端口监听（ss -lntp）。
4. 全量就绪后，再看业务入口。

#预防

• 依赖清单文档化，每次虚拟化架构变更后更新。
• 用编排/启动脚本固化顺序，避免临时凭记忆。

AI 能帮到哪一步：从历史启动记录、虚机标签里归纳依赖清单，重启后逐项验证。边界：业务依赖是活的，新系统一上线就变，清单最终要人维护，AI 只能辅助发现。

#三、网络侧

#8. 网络设备告警

#根因归类（先分类再处置）

• 物理层：风扇老化、温度升高、光模块劣化、供电。
• 链路层：端口 flapping、CRC 错误、双工不匹配、环路。
• 配置/策略：err-disable（STP BPDU guard、端口安全）、ACL 丢包。

命令（华为/华三）：

display logbuffer
display trapbuffer
display interface GigabitEthernet0/0/23   # 看 input/output error、CRC、late collision

#处置规章（SOP）

1. 分级：影响业务的（err-disable 锁口、链路中断）优先；不影响业务的（风扇偶发、温度波动）排队处理。
2. 归类：flapping + 短 duration → 物理链路问题；CRC 和 input error 同涨 → 双工/线缆；err-disable → 配置防护动作触发；广播风暴 + CPU 高 → 疑似环路。
3. 处置后验证，并在日志里留痕：什么时间、改了什么、验证结果。

#预防

• syslog 统一收集（至少保留 90 天），这是"全设备可检索"的基础。
• 光模块光衰巡检；风扇、电源、光模块常备备件。
• 告警阈值合理：别把风扇转速波动设成深夜轰炸。
• 配置定期备份 + 对比。

AI 能帮到哪一步：一晚上三百条 syslog，它聚合成三条"哪台设备、什么现象、疑似根因"，并把接口告警和"下面挂着哪台宿主机"关联起来。边界："这条告警能不能拖到明天"涉及业务判断，要人。

#9. 如何读取日志

#方法（比工具重要）

1. 确定时间窗：故障前 10 分钟到故障后 10 分钟，只读这个窗口，别从头翻到尾。
2. 带关键词读：先 grep 错误级别（error、fail、timeout），再看上下文。
3. 多机对齐：同一时间窗，把所有相关主机的日志放一起读——很多故障是多机联动的。
4. 记结论：每排查一起，把"日志现象 → 根因"记下来，沉淀成自己的排查库。

命令示例：

journalctl --since "14:50" --until "15:10" -p warning
tail -f /var/log/messages | grep -iE "error|fail"
# ESXi 优先看 vmkernel：存储、网络问题都集中在这
tail -f /var/log/vmkernel.log
# 华为/华三
display logbuffer | include ERROR

#预防

• NTP 全机房统一——时间对不齐，跨机排查无从谈起。
• 日志集中收集 + 保留策略。
• 定期"日志体检"：看有没有被刷屏的重复错误，那本身就是隐患。

AI 能帮到哪一步：跨机时间对齐、按窗口截取、把"这台报这个 + 那台报那个"拼成一条因果链，它干得好。边界："这个报错以前见过吗"是经验活，依赖你自己的排查库——AI 没有你的历史记忆，给不了这层结论。

#10. 锁定机柜、设备端口与网卡

#完整链路

虚拟机 MAC → 虚拟交换机端口组 → 宿主机物理网卡 → LLDP 邻居 → 物理交换机端口 → 机柜/U 位 → 配线表。

命令（华为/华三）：

# 虚机内
ip link                      # 拿 MAC
# 宿主机（ESXi）
esxcli network vm list        # 虚机对应的端口组
# 交换机
display lldp neighbor interface GigabitEthernet0/0/1   # 端口对端是谁
display mac-address | include <MAC>                    # MAC 挂在哪个端口
display arp | include <IP>                              # IP ↔ MAC

#处置规章（SOP）

1. 给定虚机名/IP → 拿到 MAC。
2. 宿主机侧确认端口组和物理网卡。
3. 交换机侧 LLDP + MAC 表，锁定交换机端口。
4. 用配线表/资产标签确认机柜 U 位。
5. 最后一米：到机柜对标签、对线色。

#预防

• 配线表随变更即时维护（这个环节最容易被偷懒）。
• 端口标签、资产登记规范。

AI 能帮到哪一步：把前几步自动串起来——给个虚机名，它调 vCenter API + 交换机数据，直接输出"这台虚机在 compute-02 的 vmnic2，交换机侧是 GE0/0/23"。边界：物理确认（机柜里那根线的真实走向）永远靠人腿。

#11. 如何测试服务器网络网速是否正常

#分层（ping 通 ≠ 没问题）

1. 物理协商：

   复制

   ethtool eth0
   # 看 Speed（千兆/万兆）、Duplex（必须 Full）、Link detected

   协商成 100Mb Half，物理链路或模块就有问题。

2. 丢包与 MTU：

   复制

   ping -c 100 -f 192.168.1.1            # 看丢包
   ping -M do -s 1472 -c 5 192.168.1.1   # 1500 MTU 的最大 payload
   ping -M do -s 8972 -c 5 192.168.1.1   # 测 9000 巨型帧

   MTU 黑洞（一头 1500、一头 9000）就靠这步测出来。

3. 吞吐：

   复制

   # 服务端
   iperf3 -s
   # 客户端
   iperf3 -c 172.16.0.10 -t 30   # 千兆应 >900Mbps，万兆 >9Gbps

4. 对比基线：同一条链路，昨天 9.2G、今天 5.8G，比"理论值"更能说明问题。

#处置规章（SOP）

用户报"网慢" → 按 1-4 跑一遍 → 每层给出结论（物理层/链路层/吞吐层）→ 落在哪层就在哪层查：换线、查光模块、查中间设备、查限速策略。

#预防

• 变更后必测（割接、换线、改 MTU 之后）。
• 建基线库：关键链路定期打流记录。

AI 能帮到哪一步：自动生成分级排查流程，和基线对比后输出"吞吐下降 37%，疑似光模块劣化"。边界：中间每一跳的定位（哪个交换机、哪根光纤）要人配合逐跳测。

#12. 如何排查虚拟机网络问题

#五层（自上而下，不跳层）

1. VM 内协议栈：ip addr、ip route、ping 网关。30 秒的事，却常常被人跳过。
2. 虚拟交换机端口组：VLAN、绑定、负载均衡策略；esxcli network port list。
3. 宿主机物理网卡：esxcli network nic list，vmnic 状态、错误计数。
4. 物理交换机端口：VLAN、access/trunk、MAC 表。
5. 路由与防火墙：跨网段才查；中间防火墙策略是高频根因。

#常见根因

• 端口组 VLAN 和交换机端口 VLAN 不一致（最高频）。
• MTU 不一致、上行 uplink 没挂、端口组漂移。
• 防火墙策略放行缺失。

#处置规章（SOP）

用"通/不通"二分法快速收敛：

• VM 内 ping 网关通 → 协议栈和虚拟交换机基本正常，问题在上层。
• 同宿主两台虚机通、跨宿主不通 → 问题在物理链路/交换机。
• 同 VLAN 通、跨 VLAN 不通 → 查路由、防火墙、trunk 放行列表。

#预防

• 虚拟化配置基线 + 变更比对（改交换机和改端口组必须同步）。
• 定期核查 vSwitch 上行绑定，别让冗余形同虚设。

AI 能帮到哪一步：出问题时自动跑五层快检，输出"哪层正常、哪层异常、差在哪个字段"（比如"端口组 VLAN 30，交换机端口 VLAN 20"）。边界：结论由它给，命令由人敲；改哪层、怎么改，人定。

#13. 宿主机和网络设备配置一致性

#重点核对四项

1. VLAN：宿主机端口组 ↔ 交换机 access/trunk 放行列表。
2. MTU：宿主机网卡/vSwitch ↔ 交换机端口，一处 1500 一处 9000 必丢大包。
3. 端口模式：access/trunk/混合，trunk allow vlan 列表完整。
4. 双工/协商：强制与自动混配，出现"能通但慢一半"的怪现象。

#根因

• 手工变更不同步：改了交换机，忘了改宿主机。
• 配置模板漂移：各台设备慢慢不一致。
• 升级/重装后配置丢失未复原。

#处置规章（SOP）

采集（display current-configuration、esxcli network vswitch standard list、ovs-vsctl show）→ 对比 → 输出差异清单（精确到字段）→ 审批 → 对齐 → 验证业务。

#预防

• 模板化配置 + 变更流程：改任何一端都必须同步另一端。
• 定期（每周）自动比对，差异即时上报。
• 变更后有验证步骤，别"改完就走"。

AI 能帮到哪一步：配置 diff 是它最不容易错的活——规则明确、纯文本对比，几秒扫完 14 台宿主机 + 6 台交换机。边界：对齐变更要人审批，改完后的业务验证也要人做。

#14. 虚拟交换机与 SDN 控制器

#虚拟交换机（vSwitch / vDS / 分布式交换机）

常见问题及根因：

• 端口组配置错误：VLAN、安全策略（混杂模式）、流量整形。
• uplink 绑定问题：冗余全压在一个 vmnic 上（esxcli network nic stats 看单卡流量）。
• dvSwitch 漂移：主机加入分布式交换机后 uplink 丢失 → 虚机断网，重启主机后最容易出现。

#SDN 控制器（华三 SeerEngine、华为 iMaster NCE 等）

核心坑：控制器以为配置下发成功了，数据面根本没生效。排查顺序：

1. 控制器本身：健康、集群状态、数据库同步。
2. 南向通道：控制器 ↔ 设备的会话（netconf/OVSDB/BGP EVPN）是否建立。
3. VTEP/VXLAN 隧道：隧道 up/down、EVPN 邻居状态。
4. 租户网络：VNI 下发是否到位、RT/RD 是否一致、vSwitch 上 VXLAN 端口组是否正确。
5. underlay：VTEP 之间连通性、MTU 9000 的 VXLAN 报文能否通过——VXLAN 封装后报文更大，MTU 黑洞很常见。

#处置规章（SOP）

控制器 → 南向 → 隧道 → 租户 → underlay，逐层 check，输出"不一致点在哪一层"。

#预防

• 控制器冗余部署，南向通道加监控告警。
• 定期做"意图 vs 实际"diff（控制器配置 vs 设备 running config）。
• 变更走控制器统一下发，禁止设备上手工改动——手工改就是漂移源。

AI 能帮到哪一步：把控制器 API、VTEP 状态、underlay 路由三处数据对齐，输出"控制器认为已下发，但 compute-05 的 EVPN 邻居没建起来"。边界：是回滚（放弃下发）还是强制收敛（重新下发），涉及业务窗口，这是人的决策。

#四、运维人员的提升方向

不喊口号，给你一个每周能落地的清单：

1. 把自己的 SOP 卡片化：每个场景做成一张卡片——触发信号、第一步命令、验证点、常见坑。出问题时照着走，比临场翻监控快十倍。
2. 每周主动巡检，别等告警：iostat 看 IO 延迟、multipath -ll 看路径数、ethtool 看协商、光衰巡检、存储容量水位。30 分钟，能提前掐掉大部分深夜故障。
3. 建基线，让"异常"可量化：iperf3 的数字、IO 延迟分布、路径数量、容量水位。没有基线，你只能说"好像有点慢"；有基线，你能说"降了 37%"。
4. 把 AI 当只读助手用：把你熟知的排查顺序写成固定模板喂给 Agent，让它跑第一遍、出结论，你只复核。它的定位是"不睡觉的实习生"，不是"自动改配置的神"。
5. 每处理一起故障，记录根因：半年后回看，你会发现自己处理过的故障类型就那么几十种。这些记录就是你教给 AI 的素材，也是你判断它结论靠不靠谱的依据——AI 能力有边界，但你和它都能在记录里持续进步。

#延伸阅读

• DevOps 运维中 AI 那些事 —— AI 在运维链路中的定位、验证与边界。
• Linux 网络高级配置实战：Bonding、RAID 卡、故障诊断与虚拟交换机 —— 主机侧冗余与链路排查的底层机制。
• 云计算机房网络和 K8S 网络，其实是同一套东西 —— VXLAN/EVPN 与 underlay 的分层。
• H3C 企业园区与数据中心网络综合实验 —— 交换机侧的配置与验证。