H3C网络设备巡检报告模板：从指标采集到自动化生成

简介：这是一份专用于H3C网络设备的巡检报告模板，面向企业网络运维人员、IT支持工程师及负责设备健康检查的管理者。模板围绕网络巡检全流程设计，覆盖网络拓扑与带宽链路、设备品牌型号/放置位置/性能参数/内存/槽位/序列号/购买年限/保修与备件状况、IOS版本与运行时间、CPU与内存利用率、模块状态、风扇及电源、端口信息、连通性、冗余协议、VLAN、以太通道、路由与交换协议、邻居关系、STP、NAT、FLASH配置、防火墙策略、DMZ区、Xlate状态、应用业务及IP使用状况等检查项，并包含机房温湿度等环境检查。每个项目均提供标准检查命令、期待结果和备注说明，检查结果可勾选正常或不正常，便于对照执行。资源为1个doc文档，压缩包仅38KB，可直接套用或按需修改。已有108人学习下载，适合需要建立例行巡检机制、规范检查流程、提高故障排查效率的团队参考使用。

1. H3C网络设备巡检报告模板：为什么说巡检报告比巡检本身更重要

夜班被拉起来处理业务中断，查了半小时才发现核心交换机一个光口在疯狂丢包，可端口指示灯还是绿的。这种故障不罕见，更扎心的是事后写巡检报告，翻遍上个月的记录，只找到几屏display interface的回显，当时端口计数已经涨得离谱，却没人把它标成风险。H3C网络设备巡检报告模板这件事，核心不是做个Word文档，而是把巡检动作固化成一套可对比、可追溯、能定级的体检表：固定采集哪些指标、命令怎么写、数值在什么范围算正常、异常了该找谁。这套东西适合维护着几十台上百台H3C交换机、路由器和防火墙的运维工程师，也适合刚接手一批设备的网络管理员，它能让你从“敲过命令”变成“对设备状态有数”。

2. 巡检报告的核心字段与采集指标：把H3C设备的健康基线固定下来

巡检报告最忌讳把十几条命令的输出直接粘成几十页PDF，打印出来没人翻。我见过不少同行这么干，理由是原始数据都在，出了问题可以回查。这话听上去没错，但真到排查故障那天，没人能在几千行日志里找到关键变化。一份能用的巡检报告，应该在采集侧就做减法：台账、硬件、链路、表项四个面，每面只留判断健康状态必需的字段，并且给每个字段配一个正常基线。这样报告才具备对比价值，这次CPU是30%，上次是55%，趋势立刻看得见。

2.1 设备台账：先解决“不知道这台设备是谁”的问题

巡检的第一步不是敲display命令，而是核对设备身份。H3C设备上最常用的三条命令能一次性拿齐设备的基础信息：

display version display device manuinfo display lldp neighbor-information brief

display version输出软件版本、BootROM版本和开机时间，开机时间能判断设备是不是悄悄重启过；display device manuinfo拿到序列号，查维保、报故障都要用；display lldp neighbor-information brief能在不登录对端的情况下看到邻居设备的接口和名称，是核对链路连线的利器。

模板里台账部分我一般固定这几个字段：设备IP、主机名、机柜位置、型号（比如H3C S5130-52S-EI）、序列号、软件版本、上联设备、下联设备、维保截止日期。其中软件版本最容易被人忽略。两台上联设备做IRF堆叠时版本不一致，可能导致成员设备反复重启；日常不堆叠的交换机，版本差好几个大版本也可能出现配置同步失败。巡检报告里给版本字段加一列“是否同一批次”，能在下一次变更前提前发现隐患。

2.2 硬件健康指标：温度、风扇、电源、CPU、内存

硬件层面巡检要回答的问题是：这台设备的物理部件是不是都在正常区间内。H3C设备上对应的命令很固定：

display environment display fan display power display cpu-usage display memory

display environment给出设备内部温度。H3C多数交换机在50到65摄氏度算正常，超过70度就要检查风扇转速和机房空调；display fan和display power分别看风扇和电源状态，这里容易翻车的地方在于电源模块的Status显示Normal不代表它在正常供电，还要看输出功率。比如两台电源模块都正常但整机负载超过单电源额定功率，拔掉任何一台都会宕机。

CPU和内存需要单独说。H3C设备在多核架构下，display cpu-usage不带参数时经常只显示管理核的占用率。比如S5130交换机上，业务转发由数据核处理，管理核占用率和整体负载可能差很远。所以巡检时我一般会执行display cpu-usage slot 1，再配合display cpu-usage history查看五分钟内的趋势。内存同理，display memory要关注的是剩余可用内存的绝对值，而不是占用率百分比。设备运行大半年后内存碎片化，占用率可能只有40%，但可用内存只剩不到100MB，这种状态很容易在配置保存或批量下发时直接卡死。

2.3 链路与协议状态：物理通不等于业务通

链路巡检是整个巡检报告里信息量最大的部分。很多网络故障的表现是端口指示灯正常、物理层up，但业务丢包严重。巡检时需要用这几条命令把链路状态固定下来：

display interface brief display link-aggregation summary display interface Ten-GigabitEthernet1/0/1

display interface brief能快速筛出状态Down的端口和速率异常的端口；display link-aggregation summary看聚合口，重点关注Selected成员口数量和Total端口数是否一致。这里有个很常见的场景：聚合口满了。H3C的聚合组在不同型号上有成员上限，常见的是8个或16个，超过上限后新成员口加不进去，配置下发时报错，业务流量还是只走老成员口。结果就是带宽上不去，链路利用率动不动顶到90%以上。这类问题我不当场改配置，而是在巡检报告里记一笔“聚合成员数/最大成员数”，留给变更窗口处理。

display interface Ten-GigabitEthernet1/0/1这种单口详查主要看三个计数：CRC错误包、Input Errors、Output Errors。CRC错误包持续增长通常指向光模块光衰过大或光纤头脏污，接口物理层还是up，但已经在下游引发重传。巡检模板里我建议留出一列专门记“错包较上次巡检是否增长”，比单纯贴计数更有决策价值。

2.4 表项与日志：黑匣子里面的异常信号

最后一块是设备内部的表项和日志，它们相当于网络设备的黑匣子：

display logbuffer display arp | include Total display mac-address | include Total display ntp-status

display logbuffer看日志缓冲。巡检时不需要逐条读日志，但要学会看高频事件：某个接口反复up/down，说明光模块在劣化；大量端口安全日志，说明下面接入了不该接的设备。display arp和display mac-address的Total数量可以和上一次巡检对比，ARP表项异常暴涨通常是内网有设备在扫网段，MAC表项超过设备规格的一半就该关注了。display ntp-status检查时间同步，设备时间漂移会让日志时间错乱，出故障时不同设备各说各话，根本没法串联事件链。H3C的S1850这类小型设备也支持NTP，模板里我建议把“时间同步状态”列为必填项。

3. 分设备类型的巡检侧重点：交换机、路由器、防火墙、无线控制器各看各的

通用模板只能保证不遗漏，真正写出价值的巡检报告，要按设备角色调整侧重。换一台H3C S5130交换机，和换一台出口路由器，关注点完全不同：交换机侧重端口和堆叠，路由器侧重会话和带宽，防火墙侧重策略和安全事件。下面按最常见的管理对象拆开讲。

3.1 交换机：堆叠一致性、端口利用率和链路冗余

交换机是网络里数量最多的设备，也是巡检报告的大头。除了第2章里的通用指标，交换机还要多加两个专项：堆叠和端口利用率。

堆叠状态用display stack或display irf查看。H3C的IRF是常见的堆叠技术，巡检时要确认：堆叠成员数是否和预期一致、IRF链路是否正常、有没有分裂过。IRF分裂是个事故级故障，两台设备各自为政，会造成同一网段出现两个网关，业务直接瘫痪。巡检报告里对堆叠设备我固定记录IRF成员状态和优先级，主设备优先级高的那台应该长期固定，不能出现主备反复漂移。

端口利用率要结合业务容量看。接入交换机的上行口，或服务器区的下行口，在高峰期利用率超过70%就要在报告里标黄。具体数值从display interface的输出里读，Input速率和Output速率除以端口协商速率就是当前利用率。S5130的万兆口做服务器接入时，最容易出现的问题是服务器双网卡bonding没配对端聚合，流量全挤在一个物理口上。这类问题不一定会造成宕机，但会让延迟在晚高峰明显升高。

3.2 路由器与出口设备：CPU要按方向看，会话表要算余量

路由器或出口设备是网络的咽喉，巡检报告的结论部分要能回答“这台设备还能撑多久”。出口设备的CPU占用率不能只看总数值。H3C路由器上display cpu-usage可以按板卡和核分开看，转发核负责处理数据面，控制核负责路由协议和网管。如果控制核CPU高，通常是路由震荡或网管轮询太频繁；转发核CPU高，才是真正的流量压力。巡检时这两类CPU要分开记，因为后续扩容判断的依据不一样。

出口设备上NAT会话表也是必检项。display nat session table能看会话数，display session statistics能看到老化和超时的统计。会话表满了之后，新用户上网会直接失败，表现是时好时坏，刷新一下能用，过一会又打不开。巡检报告里要把会话表使用率和设备规格上限写在一起，比如当前会话12万、上限30万，比单独写一个12万有价值得多。

关于可视化，有些运维者喜欢先开启设备的web管理再看趋势图。H3C配置web命令一般要配local-user的服务类型，再用ip http enable开启，具体以型号为准。我个人的习惯是web管理用于平时快速查看，正式巡检报告仍然以CLI采集为准，因为CLI输出稳定、可归档、可对比，web页面的实时曲线截进报告里反而难以做历史对比。

3.3 防火墙：策略命中、会话表、安全域是重点

防火墙的巡检报告要把重点从连通性转移到安全性上。连通性正常只是底线，策略是否合理、会话是否超限，才是防火墙需要回答的问题。

策略这块，display security-policy rule查看策略列表中每条策略的命中次数。长期命中次数为0的策略要单独列出来，这类策略要么是冗余的，要么是配置有误没覆盖到真实流量。安全策略的匹配顺序在H3C防火墙上有讲究，巡检报告里我会给“策略命中Top10”单独一栏，方便事后审计。

会话表对防火墙的意义比路由器更重。防火墙的会话表里有安全域信息和报文状态，display firewall session-table能看总数，和规格上限做对比。常见坑是内网P2P下载或视频终端量太大，会话表被占满，表现是部分用户网页打开极慢但ping网关正常。这种故障单纯看接口流量看不出来，必须查会话表。另外防火墙的CPU在高会话场景下容易冲到高位，很多型号会触发会话老化的自我保护，巡检时要同时记录CPU和会话表两个数，只看一个容易误判。

3.4 无线控制器与AP：在线率和信道利用率是用户感知的关键

无线控制器和AP的巡检，用户感知比协议指标更直接。display wlan ap all看AP在线状态，重点找反复离线的AP；display wlan client看在线终端数；display radio all看射频口的工作状态和信道利用率。

AP反复离线的原因很杂：PoE交换机端口供电不稳定、AP软件版本和AC不匹配、信道干扰导致射频模块重启。其中信道利用率超过50%的射频口，实际用户体验已经明显变差，但设备状态还是up。巡检报告里我会把“高信道利用率AP”单列一页，附上周边AP的信道分布，给后续调优留依据。无线部分还有一个容易忽略的点：AC的授权数量。AP在线数量和授权上限接近时，新AP会反复尝试上线但进不来，这类问题在日志里能看到，巡检时扫一眼display wlan ap all的输出就能发现。

4. 巡检中的故障信号识别：用三个真实场景给告警定优先级

巡检报告的价值在于异常信号能被人看出来。但“看出来”需要经验，下面用三个最常见的场景说明怎么从巡检数据里读出故障，并在报告里定性。

4.1 端口指示灯全绿，业务却时断时续

现象：服务器区某台交换机的下行端口指示灯正常，用户反馈从该端口上联的终端访问内部系统时快时慢，丢包率在2%到5%之间波动。

原因：物理层正常不代表数据层干净。巡检数据里CRC错误包持续增长，端口重传计数升高，光模块发送功率接近接收灵敏度的临界值。光纤头脏污或法兰盘松动都可能导致这种状态。

解决：巡检报告里把该端口标记为“光路劣化”，记录当前CRC错误包计数，并和上次巡检数据做差值。处理方案是现场清洁光纤接头，替换光模块后重新观察计数是否归零。这类问题不需要深夜割接，但必须在报告里留下对比基线，否则下次巡检仍然会看到同一组增长的数字。

4.2 CPU占用居高不下，但看不出大流量

现象：核心交换机CPU占用率长期在80%以上，端口流量统计却显示所有上行口总流量只有带宽的20%。

原因：数据面流量不大时CPU高，问题多出在控制面。常见的元凶是环路导致广播风暴被抑制但仍在消耗CPU、ARP表项频繁刷新，或路由协议邻居反复震荡。display cpu-usage能看到CPU高，但定位不到原因，需要配合display logbuffer和display ip statistics继续往下查。

解决：执行display logbuffer搜索包含LOOP、ARP、DUPLICATE的关键字；用display ip statistics看报文计数类型。报告里对这种问题定级要高一些。CPU长时间高位的设备，一旦遇到突发流量，控制面很可能直接无响应。巡检结论要明确写出建议：排查环路，检查STP配置，必要时启用BPDU保护。

4.3 IRF堆叠设备反复重启

现象：两台H3C交换机组成的IRF堆叠，成员设备每隔几天重启一次，堆叠分裂告警和恢复告警交替出现。

原因：堆叠链路不稳定是主要原因。光纤心跳线松动、IRF端口配置不一致、两台设备软件版本有差异，都会导致成员设备间握手失败。成员设备在分裂后会尝试抢占主设备角色，反复抢占的过程就会产生重启现象。

解决：巡检时用display irf查看IRF端口状态和成员优先级，重点确认IRF链路两端的端口配置一致。处理时清洁或更换堆叠线缆，统一两台设备的软件版本。这类故障在巡检报告里必须标红，因为每一次分裂都会造成网络广播风暴，用户侧的感知就是全网中断几秒钟。

4.4 巡检问题分级：哪些当场修、哪些观察、哪些报备

巡检报告不能只记录数据，还要给出动作建议。我习惯在报告末尾放一张问题分级表：

P1级别的问题在报告里要写清现象、影响面和初步判断；P2要给出建议的处理时间；P3可以只记录数据和观察方向。这套分级不需要多复杂，但能把“发现问题”和“解决问题”的节奏分开，也让看报告的人知道哪些可以先放着、哪些等不得。

5. 常见问题与避坑：巡检报告模板最容易翻车的五个细节

模板用久了会形成惯性，惯性会掩盖变化。以下五个问题是我在实际巡检中踩过的坑，每条按现象、原因、解决写，希望能帮你少走一段弯路。

5.1 现象：模板里填的设备IP和实际设备对不上

原因：设备在两次巡检之间被挪过位置、换过互联，但台账没有同步更新。还有一种情况是DHCP环境里交换机先后拿到不同IP，模板里还留着旧地址。

解决：巡检开始前先做一遍核对。用LLDP或mac-address-table从核心交换机往下捋，把实际设备的序列号和IP绑定关系刷一遍，再开始采集。模板里的“设备IP”字段应该改成“采集时实际IP”，避免下一个人拿着旧报告去对设备。

5.2 现象：CPU数值异常偏低，或者一个核100%但总CPU显示正常

原因：H3C设备多核架构下，display cpu-usage不带参数可能只展示管理核或默认核的占用率。数据核（转发核）的负载是独立的，而且不同型号的核编号规则不一样，h3c如何计算cpu和vcpu关系需要看具体型号的命令参考，没法用一套规则套所有设备。

解决：巡检脚本里对CPU采集固定使用display cpu-usage slot x格式，把每个核的占用率都抓下来。报告里CPU字段写成“管理核/数据核峰值”两项，不要只填一个总数值。遇到型号不确定时，先执行display cpu-usage进入交互式界面看完整核列表，再定采集命令。

5.3 现象：聚合口满了，业务带宽上不去

原因：H3C设备聚合组成员数量有上限，常见是8个或16个，超过上限后新成员口配置会失败或处于Unselected状态。另外还有两端成员口数量不一致的情况，比如本端有6个成员口，对端只有4个，聚合链路实际只按4个跑。

解决：巡检报告里为每个聚合口增加“本端成员数/对端成员数/最大允许数”三个字段。数量不够时，先在对端加成员口再回本端加。模板中要留备注栏，记录是接口规格受限还是对端配置不全，避免下个工程师重复踩同一个坑。

5.4 现象：模拟器里跑通的巡检命令，真机上失败

原因：H3C模拟器和真实设备存在命令集差异，模拟器里可能没有真机上的一些监控命令，或者命令格式在不同软件版本里不同。h3c模拟器设备启动失败也是一个常见问题，通常是版本和模拟器不匹配或虚拟化软件环境问题，这类问题会和真实设备关系不大，但会让人误判脚本本身有毛病。

解决：巡检命令清单先在真机上逐条验证，确认输出格式后再写进模板。真实设备上批量采集时，先用两台设备试跑，比对输出内容是否完整。报告格式以真机输出为准，模拟器只用来做流程演练，不用来定命令格式。

5.5 现象：报告写完了，看报告的人说看不懂

原因：模板设计时只考虑了数据采集，没考虑阅读体验。命令输出几百行，但关键的判定信息藏在其中，读者必须自己找。

解决：模板的每一节都加固定的“结论”行，先写判定再放依据。比如链路部分的结论写“上联口CRC错包较上次增长120%，建议安排更换模块”，后续再附具体输出。这样巡检报告从“数据存档”变成“决策文档”，看报告的人不需要懂命令也能知道该做什么。

6. 把巡检报告模板做成自动化脚本：用Python直接生成Word

模板的字段和对设备的判定基线定下来之后，下一步是减少人工操作。几十台设备一台台登录、复制、粘贴，容易漏设备也容易抄错数。我用Python写了一套小工具，连接H3C设备批量采集标准命令，再把结果填充到巡检报告模板里。

6.1 用paramiko批量采集设备状态

import paramiko def fetch_device(ip, username, password, commands): client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(ip, port=22, username=username, password=password, timeout=10) output = {} for cmd in commands: stdin, stdout, stderr = client.exec_command(cmd) output[cmd] = stdout.read().decode("utf-8", errors="ignore") client.close() return output

这段代码做的事情很简单：按IP连接设备，依次执行巡检命令，把每条命令的输出以命令名为键存进字典。timeout设10秒是避免某台设备无响应时脚本卡死；errors="ignore"处理设备输出里可能出现的非UTF-8字符，防止解码中断脚本。这里需要注意的是，command列表要严格按第2章到第4章梳理出的命令来填，顺序不要随意调整，输出会按相同顺序写入报告。

6.2 用python-docx把采集结果填进报告模板

from docx import Document doc = Document("巡检报告模板.docx") replace_map = { "{{DEVICE_IP}}": device_ip, "{{CPU_USAGE}}": cpu_value, "{{MEMORY_USAGE}}": memory_value, } for paragraph in doc.paragraphs: for key, value in replace_map.items(): if key in paragraph.text: paragraph.text = paragraph.text.replace(key, value) doc.save(f"{device_ip}_巡检报告.docx")

这里用占位符替换的思路：在Word模板里写死{{DEVICE_IP}}这种标记，脚本遍历所有段落，把标记替换成实际值。replace_map的键值对由上一节采集结果整理而来。实际操作中我会把设备台账、硬件指标、链路状态分别做成表格写在模板里，替换逻辑从段落扩展到表格单元格。占位符放在表格里容易漏替换，因为python-docx的doc.paragraphs不覆盖表格内的段落，需要单独遍历doc.tables，这是个容易踩的小坑。

6.3 验证与复核习惯

脚本生成的报告不能直接发，至少要做两步核验。第一步打开随机两台设备的报告，确认CPU、内存、错包计数三个关键字段不是空值，空值说明命令执行失败或设备没有响应，要回去看脚本日志。第二步把本次报告和上次报告同字段做对比，重点看温度、CRC错包、会话表这三项的变化方向，变化超过阈值时回到设备上复测一次，确认不是采集噪声。

有了这套脚本之后，我的巡检流程变成：脚本批量采集、自动填充、人工抽核、结论录入。模板的兼容性在最初几轮要花时间调，不同软件版本的输出格式略有差异，但跑顺之后，一台设备从采集到生成报告不到一分钟。这个改变把巡检从“半天敲命令”变成了“半小时抽核与写结论”，回头看，值得投入。希望这个方案和这套踩坑记录能帮到你。

本文还有配套的精品资源，点击获取