简介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 irfdisplay interface brief适合快速扫一遍端口状态但每台几十台设备做完会累到怀疑人生真正要详细看的是业务上联口、专线口、出口这些接口单独执行display interface看完整计数器。display link-aggregation summary必须看「聚合口满了」那一栏——成员口是不是都在Selected状态、分担是否均匀这直接关系到带宽瓶颈判断。安全配置和日志放在最后查# 日志:内存日志缓冲和文件日志 display logbuffer display logfile summary # 配置基线:核对当前配置是否有未授权改动 display current-configuration display thisdisplay logbuffer查的是内存里的环形缓冲设备重启就没了display logfile才是落到flash里的历史日志。这两条必须配合看光看logbuffer很容易得出「设备没报过错」的错误结论。2.3 把这些命令固化成一个「巡检执行卡」命令记在模板文档里没问题但我更建议单独做一张「巡检执行卡」一页A4纸左边是命令右边留空填结果。每次巡检先执行卡片上的命令再往报告里抄数据。这样不会漏项也不会在设备上现场想「查什么来着」。执行卡与报告模板的区别在于执行卡是给自己用的怎么顺手怎么来报告模板是给领导和审计看的要规范、要能归档。把命令和报告字段一一对应起来之后模板的结构才有依据而不是随便找一张表硬填。我自己通常把执行卡按「登录 → 设备档案 → 硬件状态 → 资源 → 接口 → 协议 → 日志 → 配置基线」的顺序排每条命令后面留空格写结果和异常标记。做到后面熟练了一台设备从登录到采集完数据控制在五六分钟整套巡检的核心效率都在这张卡上。3. 设计一份能直接落在纸面上的 H3C 巡检报告模板字段、表格、填表规范3.1 模板.doc 的页面结构封面、设备档案、巡检项明细、异常记录、遗留问题一份交上去不会被退回来的H3C巡检报告模板文档结构通常固定为五块顺序不能乱封面、设备档案表、巡检项明细表、异常记录表、遗留问题跟踪表。封面不是装饰。写明被巡检设备所属系统、巡检日期、巡检人、复核人这两行信息在后续追溯时价值极大——半年后翻报告能直接定位「这台设备是哪位同事在什么时间做的巡检」。设备档案表放型号、序列号、软件版本、槽位板卡信息、IP地址、物理位置相当于设备的「身份证页」后续所有巡检记录都挂在这张身份证下。巡检项明细表是模板核心每行一个巡检项按设备自身、链路、协议、安全分组。异常记录表单独拎出来是因为领导的阅读习惯是先看有什么问题再看例行结果。把异常埋在一堆「正常」里是模板设计失败。遗留问题跟踪表则用于跨周期管理——这次解决不了的问题留到下次巡检继续确认形成闭环。3.2 巡检项明细表的字段设计少一列都不行巡检项明细表不建议超过七个字段否则填表成本过高巡检员会偷工减料。我常用的七字段设计如下字段填什么示例巡检模块设备自身/链路/协议/安全设备自身巡检项具体检查什么CPU负载执行命令查这项用哪条命令display cpu-usage判定标准什么范围算正常60秒均值持续80%实测值本次实际结果CPU 23%5分钟均值18%结论正常/异常/关注正常备注留给你写补充判断主控板CPU略高业务板正常关于字段顺序有个细节不要按「模块、巡检项、实测值」排而是把「执行命令」放在「判定标准」前面。原因是填表人先看到命令再看到标准操作路径最短如果先看到标准再看命令填表时要来回翻命令出错概率高。表格排版上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设备上长期使用的阈值速查表可以作为模板「判定标准」列的默认值巡检项正常范围关注范围异常CPU使用率1分钟均值70%70%80%且持续上升80%持续15分钟内存使用率75%且Free500MB75%85%85%或Free200MB接口带宽利用率50%50%70%70%持续接口CRC/Day02355且持续增长单板温度低于上限10℃距上限≤5℃达上限日志新增Error01条且可解释1条或高危模块NTP偏差100ms100ms1s1s这套阈值适合大多数中小型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 21 done这段脚本的逻辑是逐个执行命令并把回显追加到同一文件。参数说明DEV是设备管理地址OUT是输出目录ssh admin需换成实际登录账号。脚本的价值在于让每次巡检的原始数据都沉淀到同一目录后续写报告时直接翻文件不用重新登录设备。要注意脚本里的命令顺序按巡检执行卡排列不宜随意增删。还有一点所有命令的回显保留原始格式不要做任何裁剪——原始回显是证据裁剪过的不是。6.2 基线对比第二次巡检只看变化做巡检这件事最有效率的实践是基线对比。第一次巡检时把版本、配置、邻居、硬件清单、日志摘要存为基线文件之后每次巡检差别只在变化项。设备巡检的核心价值不是一遍遍确认「正常的还是正常」而是捕捉「哪里变了」。实现方式很朴素第一次巡检后把display current-configuration、display lldp neighbor-information、display device存进一个以设备IP命名的txt文件放入「基线」目录下次巡检后用diff对比两次输出。脚本可以顺手写但重点是习惯——每次巡检结束前花两分钟把当日输出与基线diff一次比把所有回显重读一遍高效得多。6.3 落到模板与交接习惯模板.doc 里可以加一页「配置变更记录」专门登记基线diff发现的变化变更时间、变更人、变更内容、是否已在配置库更新。这张表的作用是把「巡检发现变化」和「变化被管理」连起来。如果设备配置在两次巡检之间变了但没人登记要么是合法变更没走流程要么是未经授权的改动——两种情况都值得关注。我的个人习惯是每次巡检完把采集的原始回显连同报告模板一起放进以日期命名的目录并同步到团队版本库交接工作时候直接把基线目录和历史报告一起交给下一任。这样巡检就不再是别人问起来才做一次的文档任务而是一条源源不断的信息流。做巡检这件事的底气不来自一次报告写得多漂亮而来自历史数据越积越多、每次变化都能说清来龙去脉。希望帮到你。本文还有配套的精品资源点击获取