简介：H3C网络设备巡检报告模板（doc格式）是一份面向网络管理员、运维工程师及企业IT维护人员的标准化巡检工具，用于定期检查H3C交换机、路由器等设备的状态。模板涵盖网络拓扑与带宽、设备硬件信息、IOS软件版本、CPU/内存利用率、模块与风扇电源状态、路由交换协议、连通性、NAT、防火墙策略及机房环境等巡检维度，并内置检查指导，列出每条命令、期待结果和结果判定，方便按项记录与排查隐患。压缩包内仅含1个doc文档，大小38KB，轻量易用，可直接作为日常巡检或项目交付的参考底稿；文档中逐项说明VLAN、以太通道、STP、邻居关系等检查点，并附有实际命令输出范例，帮助新手快速上手，也有助于统一团队巡检标准。目前已有108人学习下载，经实际环境验证的模板文档能节省编制巡检表的时间，提升网络健康检查的规范化程度。

1. 巡检报告不是填表：先搞清楚H3C设备巡检到底在查什么

新接手一个机房的网络运维，第一个任务往往是「给设备做一次巡检，交一份报告」。这时候大部分人第一反应是上网找一份「H3C网络设备巡检报告模板.doc」，下载、打开、对着设备信息填表，填完交上去，感觉任务完成了。但只要被领导追问一句「这台设备CPU 80%为什么标正常」「接口CRC错误涨了多少」就会意识到，模板根本不是拿来填的，而是拿来执行的——每一行巡检项背后，必须有一组H3C设备的命令和一套判定标准，否则报告写出来就是一张谁也看不懂的表格。

这篇内容适合两类人：一类是被要求做巡检但是不知道查什么的运维新人，另一类是团队里要建立巡检制度、想把巡检报告做成固定交付物的老手。我会把巡检项、H3C命令、判定阈值、模板字段逐一对应起来，最后再讲清楚哪些常见坑会让新手白干一场。

2. 把巡检项拆成命令清单：display 命令族与报告字段一一对应

2.1 先分层：巡检分「设备自身、链路、协议、安全」四块

一份能用的H3C巡检模板，第一件事不是排版，而是确定巡检范围。我一般把巡检拆成四块，每一块对应一批命令和报告字段：

设备自身：型号、序列号、软件版本、运行时间、CPU、内存、风扇、电源、温度，这些是设备能不能继续撑下去的基础。协议状态：OSPF/BGP/VRRP/LLDP等邻居和会话状态，这些决定业务路由是否健康。链路质量：接口的速率、带宽利用率、错包、丢包、聚合链路成员状态，这些决定转发面是否健康。安全与配置：登录会话、ACL命中、配置是否被改动过、日志里有没有异常告警。

四块不是平均用力。日常巡检里设备自身和链路质量占七成工作量，协议和安全主要靠基线对比发现变化。模板里也应该按这个权重安排篇幅，而不是把十几张表平均铺开。

这四块的每一条，在H3C设备上都有对应的查询命令。把命令记熟，比背任何网上的模板字段都管用。

2.2 每块对应什么命令：从 display version 到 display logbuffer

设备自身信息集中在「display」命令族里。以下命令在H3C Comware V7设备上是通用做法，我按巡检顺序整理成一段可以直接复制到终端里逐条执行的命令清单：

# 设备档案:型号、SN、软件版本、运行时长 display version # 硬件健康:单板、电源、风扇、温度 display device display power display fan display temperature # 资源使用率:CPU 和内存(注意看多槽位) display cpu-usage display memory # 系统时钟和 NTP 状态 display clock display ntp-service status

这段命令每条都有明确目的。display version不只是看型号，还要看软件版本和启动时间——运行时长短的设备可能刚重启过，原因要去日志里查；display device的输出里要盯「Fault」状态而不仅是「Normal」，因为单板处于Absent（未安装）时不报Fault，新手容易漏。

链路和协议部分，要用另一组命令。接口巡检的重点是错误包和利用率，不是只看端口up/down：

# 接口流量与错误包:逐个查看关键接口 display interface GigabitEthernet 1/0/1 # 接口摘要:一次看所有接口的状态和流量 display interface brief # 链路聚合:成员口、负载分担方式、总带宽 display link-aggregation summary # 邻居与协议状态 display lldp neighbor-information display ospf peer display vrrp display irf

display interface brief适合快速扫一遍端口状态，但每台几十台设备做完会累到怀疑人生；真正要详细看的是业务上联口、专线口、出口，这些接口单独执行display interface看完整计数器。display link-aggregation summary必须看「聚合口满了」那一栏——成员口是不是都在Selected状态、分担是否均匀，这直接关系到带宽瓶颈判断。

安全配置和日志，放在最后查：

# 日志:内存日志缓冲和文件日志 display logbuffer display logfile summary # 配置基线:核对当前配置是否有未授权改动 display current-configuration display this

display logbuffer查的是内存里的环形缓冲，设备重启就没了；display logfile才是落到flash里的历史日志。这两条必须配合看，光看logbuffer很容易得出「设备没报过错」的错误结论。

2.3 把这些命令固化成一个「巡检执行卡」

命令记在模板文档里没问题，但我更建议单独做一张「巡检执行卡」：一页A4纸，左边是命令，右边留空填结果。每次巡检先执行卡片上的命令，再往报告里抄数据。这样不会漏项，也不会在设备上现场想「查什么来着」。

执行卡与报告模板的区别在于：执行卡是给自己用的，怎么顺手怎么来；报告模板是给领导和审计看的，要规范、要能归档。把命令和报告字段一一对应起来之后，模板的结构才有依据，而不是随便找一张表硬填。

我自己通常把执行卡按「登录 → 设备档案 → 硬件状态 → 资源 → 接口 → 协议 → 日志 → 配置基线」的顺序排，每条命令后面留空格写结果和异常标记。做到后面熟练了，一台设备从登录到采集完数据控制在五六分钟，整套巡检的核心效率都在这张卡上。

3. 设计一份能直接落在纸面上的 H3C 巡检报告模板：字段、表格、填表规范

3.1 模板.doc 的页面结构：封面、设备档案、巡检项明细、异常记录、遗留问题

一份交上去不会被退回来的H3C巡检报告模板，文档结构通常固定为五块，顺序不能乱：封面、设备档案表、巡检项明细表、异常记录表、遗留问题跟踪表。

封面不是装饰。写明被巡检设备所属系统、巡检日期、巡检人、复核人，这两行信息在后续追溯时价值极大——半年后翻报告，能直接定位「这台设备是哪位同事在什么时间做的巡检」。设备档案表放型号、序列号、软件版本、槽位板卡信息、IP地址、物理位置，相当于设备的「身份证页」，后续所有巡检记录都挂在这张身份证下。

巡检项明细表是模板核心，每行一个巡检项，按设备自身、链路、协议、安全分组。异常记录表单独拎出来，是因为领导的阅读习惯是：先看有什么问题，再看例行结果。把异常埋在一堆「正常」里是模板设计失败。遗留问题跟踪表则用于跨周期管理——这次解决不了的问题，留到下次巡检继续确认，形成闭环。

3.2 巡检项明细表的字段设计：少一列都不行

巡检项明细表不建议超过七个字段，否则填表成本过高，巡检员会偷工减料。我常用的七字段设计如下：

关于字段顺序有个细节：不要按「模块、巡检项、实测值」排，而是把「执行命令」放在「判定标准」前面。原因是填表人先看到命令，再看到标准，操作路径最短；如果先看到标准再看命令，填表时要来回翻命令，出错概率高。

表格排版上，A4纸横向放置，每行高度固定，避免Word文档在不同电脑上打开行高变乱。巡检项大概二十到三十项，表格控制在三到四页内。打印出来的话，每页表头重复显示，方便归档翻页。

3.3 填表规范：一个巡检项怎么算是「正常」，结论怎么下

模板有了，填表规范必须跟着定，否则十个巡检员能填出十种模板。我给团队定的规范很直接：「正常」意味着实测值在判定标准范围内且没有波动趋势；「关注」意味着实测值在正常范围边界或存在持续上升趋势；「异常」意味着实测值明确超过标准，或设备已出现告警。

判定标准写实测值而不是写「正常」两个字。比如CPU一项，实测值写「CPU 23%，5分钟均值18%」比写「正常」有价值得多——后者的数据三个月后完全无法对比。接口错包项也一样，写「CRC 12个，昨日基线5个」比写「有少量错包」严谨。

检查项中，任何一项填了「异常」或者「关注」，必须在异常记录表里有对应条目，不能只写在明细表里。这也是模板的一种自我校验逻辑。

3.4 让模板和命令一一对应的技巧：表格里留「执行命令」列

网上能下载到的巡检模板，绝大多数只有「巡检项、判定标准、实测值、结论」四列。缺少「执行命令」列是这类模板不能直接落地的关键问题。我设计模板时坚持把命令写进表格的每一行，原因有二：一是填写人不用回忆命令是什么，照着执行即可；二是模板本身成为一份培训材料，新人拿到手就可以上手巡检，不用再翻命令手册。

执行命令列内容要做到可复制。命令要写完整格式，比如display interface GigabitEthernet1/0/1必须写全端口名，不能写成display int gi1/0/1这种缩写——虽然设备支持缩写，但填表的人不一定认识。

最后关于doc格式本身：如果项目要求的是Word文档，我建议模板文件用表格加内容控件，把巡检项和判定标准设为锁定不可编辑，只开放实测值和结论单元格。这样能防止巡检员顺手改判定标准——一旦有人把CPU阈值从80%改成95%，整份报告就失去了意义。

4. CPU、内存、接口与日志：H3C 设备巡检结果的判定阈值和执行逻辑

4.1 CPU 和内存：看均值不看瞬时，区分主控板和业务板

H3C设备的CPU查询输出通常按板卡分槽位显示，display cpu-usage默认显示所有板卡的CPU使用情况，而不仅是登录的那块主控板。很多人第一次看到输出里一排槽位会懵，这对应了热词里「h3c如何计算cpu和vcpu关系」的困惑——在框式设备上，CPU是按物理板卡维度统计的，每块板卡有独立的CPU占用率，只有虚拟化平台才会换算vcpu占比，巡检时以设备输出为准。

判定逻辑上，我关注的是持续值而不仅是瞬时值。CPU使用率看1分钟均值，瞬时飙到90%但1分钟均值降到30%，通常只是配置下发或路由计算的瞬时抖动。持续15分钟以上超过80%，才需要进设备排查是什么进程在消耗CPU。display process cpu可以进一步定位top进程；如果是某个协议进程异常，再查对应的邻居状态。

内存判定比CPU简单，但有一个坑：H3C设备的内存使用率要看display memory里的Used比例和Free绝对值，两者都要看。曾经遇到过一台设备「使用率75%」，看起来没事，但free内存只剩几十兆了，后面业务板卡动态加载特性时直接内存耗尽重启。因此判定标准建议定为「使用率<80%且Free内存绝对值大于500MB」两个条件同时满足才算正常。

4.2 接口和聚合链路：利用率、CRC错误包、聚合成员状态

接口巡检的核心是四个指标，缺一不可：带宽利用率、CRC错误包、输入输出丢包、接口状态变化次数。

带宽利用率是判断链路是否饱和的直接依据。业务正常的情况下，持续超过70%就要考虑扩容或者流量分担了，超过85%基本可以认定为拥塞。这里注意聚合链路的特殊性：display interface Bridge-Aggregation显示的流量是各成员口流量的总和，不能用它和单物理口速率直接对比。要看每个成员口各自多少——聚合口整体利用率30%但某个成员口已经到90%，负载分担算法有问题，这正是「聚合口满了」这个现象的典型场景。

CRC错误包是链路质量的晴雨表。逐日看数据，单日增长数量为0最好；出现持续增长就要排查光模块、尾纤、对端设备端口。少量CRC错误可以定位为瞬时干扰，持续增长则是物理链路劣化的明确信号。

接口状态变化次数看display interface里的Last 300 seconds input rate附近的状态信息。Access端口频繁up/down，多半是协商问题或物理接触不良；Trunk端口频繁变化，则要查是否对端交换机在做STP或聚合配置调整。

4.3 日志和温度：什么级别才需要写进异常记录

日志巡检的目标不是「没有错误日志」，而是「没有新增的高危错误日志」。H3C的日志级别分为Emergency、Alert、Critical、Error、Warning、Notification、Informational、Debug八级，巡检时只看前四级：Emergency和Alert几乎出一次就要坐不住，Critical通常伴随板卡故障或业务中断，Error需要记录并跟踪。Warning及以下级别不需要进异常记录，否则报告里会堆满噪音。

温度巡检看起来简单，实则容易翻车。display temperature的输出会列出当前温度和上下限，不同板卡的告警阈值不同，不能拿统一数值套用。而且温度有明显的季节性特征：夏天机房空调故障时温度升高，冬天恢复正常。因此温度判定标准建议写成「当前温度 < 告警上限 - 5℃」且「与上次巡检差值 < 10℃」，后者用于捕捉空调失效这类渐进式故障。

4.4 阈值速查表：一套可以直接抄走的判定标准

下面是我在H3C设备上长期使用的阈值速查表，可以作为模板「判定标准」列的默认值：

这套阈值适合大多数中小型H3C网络。核心链路的设备可以收紧——比如把CPU关注阈值降到60%，接口利用率关注阈值降到60%；不重要的接入设备可以适当放宽。但规矩是：阈值一旦定下来写进模板，就不要在现场临时改。巡检要的是可对比的一致性，而不是灵活变通。

5. H3C 设备巡检避坑：5 个命令输出把新手带沟里的真实案例

5.1 堆叠设备只查了主设备，成员设备悄悄告警

现象：在一组H3C IRF堆叠设备上执行display cpu-usage，显示CPU正常，但网络却有卡顿。后来登录到成员设备才发现，其中一台成员设备CPU已经持续90%以上。原因：默认情况下，从主设备登录后执行display cpu-usage只能看到主设备主控板的CPU，输出了所有槽位吗？很多默认输出只包含本机单板。解决：巡检堆叠时先执行display irf确认有几台成员，再逐台执行display cpu-usage slot 成员编号。我的习惯是直接display cpu-usage之后立刻用display device核对槽位清单，确保每块板卡的CPU和状态都看见。

5.2 聚合口流量「满了」，但报告里看不出是哪个成员口

现象：核心链路聚合口带宽利用率显示60%，业务方却说频繁卡顿；仔细看成员口，其中一个物理口利用率已经99%，另一个只有20%。原因：聚合口负载分担基于流哈希，大流量业务如果哈希到同一个成员口，就可能出现单个物理口打满而其他口闲置。聚合口的整体利用率掩盖了单口拥塞。解决：巡检链路时，除了display link-aggregation summary看聚合状态，一定要对每个成员口单独display interface看速率。报告上的链路模块应该体现成员口各自的利用率，而不是只写聚合口总计。

5.3 logbuffer 是空的，不代表设备没有问题

现象：某台H3C设备巡检时display logbuffer只有三五条信息，报告写了「无异常日志」。后来设备故障，排查时才发现flash里的logfile有大量告警记录。原因：logbuffer是内存环形缓冲，容量有限且设备重启即清空；如果设备已经运行了很久，或者日志输出量大，早期日志早被覆盖。解决：巡检必须同时查display logbuffer和display logfile summary，以文件日志为准补历史。遇到logbuffer几乎为空的情况，先确认设备运行时间display version，如果运行时间很长但buffer空，还有可能日志被人工清过，这也是一个值得写进备注的信息。

5.4 设备时间乱套，日志顺序对不上

现象：两台上联设备发生故障，把两边日志拼在一起排查时间线，结果时间差半小时，根本无法还原故障先后顺序。原因：设备没有配置NTP时间同步，或者配置了NTP但源不可达。H3C的小盒设备比如S1850系列，出厂时间不准又没接NTP，运行几个月后偏差越来越大。解决：巡检模板里把display ntp-service status单列一项，查看同步状态和偏差值。偏差超过1秒就报异常，建议配置NTP自动同步网络日期和时间。巡检本身也依赖准确时间——所有采集的数据、日志、报告时间戳，都建立在设备时间正确的前提下。

5.5 风扇与电源状态是 Absent，不是 Fault

现象：display fan输出显示风扇状态是Absent，新手填写报告时写成「风扇故障」。原因：Absent在H3C设备上表示该位置「未安装设备」，不是「设备故障」，比如设备只有两个电源槽但只装了一个电源，另一个槽位显示Absent是正常现象。Fault才是真正需要报修的故障状态。解决：巡检报告模板里应把两种状态分列：Absent归入「硬件配置备注」，Fault归入异常记录。这一条看似简单，但巡检员不对着display device查阅状态含义，几乎都会写错。

这五个坑的共同根源是：只看命令输出，不看输出字段的含义和边界。巡检报告写的不是命令回显，而是对回显的判断。

6. 让巡检报告自己长出来：把命令固化成脚本，用基线对比替代每次从头看

6.1 把巡检命令变成一段可复用脚本

巡检做了几次之后，重复劳动感会很明显。常见做法是把执行卡上的命令写成一棵脚本，批量执行并保存回显，之后手动从回显里提取关键数值填报告。脚本不复杂，核心就是按设备循环执行命令：

#!/bin/bash # 巡检命令采集脚本:批量执行常见 H3C 巡检命令 # 用法: ./inspect_h3c.sh <设备IP> <输出目录> DEV=$1 OUT=$2 mkdir -p "$OUT/$DEV" for cmd in "display version" "display device" "display cpu-usage" \ "display memory" "display interface brief" \ "display logbuffer" "display logfile summary" \ "display clock" "display ntp-service status"; do echo "===== $cmd =====" >> "$OUT/$DEV/all_output.txt" ssh admin@"$DEV" "$cmd" >> "$OUT/$DEV/all_output.txt" 2>&1 done

这段脚本的逻辑是逐个执行命令并把回显追加到同一文件。参数说明：DEV是设备管理地址，OUT是输出目录，ssh admin@需换成实际登录账号。脚本的价值在于让每次巡检的原始数据都沉淀到同一目录，后续写报告时直接翻文件，不用重新登录设备。

要注意脚本里的命令顺序按巡检执行卡排列，不宜随意增删。还有一点：所有命令的回显保留原始格式，不要做任何裁剪——原始回显是证据，裁剪过的不是。

6.2 基线对比：第二次巡检只看变化

做巡检这件事，最有效率的实践是基线对比。第一次巡检时把版本、配置、邻居、硬件清单、日志摘要存为基线文件；之后每次巡检，差别只在变化项。设备巡检的核心价值不是一遍遍确认「正常的还是正常」，而是捕捉「哪里变了」。

实现方式很朴素：第一次巡检后把display current-configuration、display lldp neighbor-information、display device存进一个以设备IP命名的txt文件，放入「基线」目录；下次巡检后用diff对比两次输出。脚本可以顺手写，但重点是习惯——每次巡检结束前，花两分钟把当日输出与基线diff一次，比把所有回显重读一遍高效得多。

6.3 落到模板与交接习惯

模板.doc 里可以加一页「配置变更记录」，专门登记基线diff发现的变化：变更时间、变更人、变更内容、是否已在配置库更新。这张表的作用是把「巡检发现变化」和「变化被管理」连起来。如果设备配置在两次巡检之间变了但没人登记，要么是合法变更没走流程，要么是未经授权的改动——两种情况都值得关注。

我的个人习惯是：每次巡检完把采集的原始回显连同报告模板一起放进以日期命名的目录，并同步到团队版本库；交接工作时候直接把基线目录和历史报告一起交给下一任。这样巡检就不再是别人问起来才做一次的文档任务，而是一条源源不断的信息流。做巡检这件事的底气，不来自一次报告写得多漂亮，而来自历史数据越积越多、每次变化都能说清来龙去脉。希望帮到你。

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