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 briefdisplay 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 memorydisplay 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/1display 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-statusdisplay 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在线状态重点找反复离线的APdisplay 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 巡检问题分级哪些当场修、哪些观察、哪些报备巡检报告不能只记录数据还要给出动作建议。我习惯在报告末尾放一张问题分级表级别典型信号处理方式P1IRF分裂、会话表超限、电源模块故障立即响应现场处理或电话支持P2CRC错误包持续增长、CPU高位、风扇异常近期安排变更窗口准备备件P3单端口光衰偏大、聚合口余量不足、AP信道利用率高记录观察下次巡检重点复查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, port22, usernameusername, passwordpassword, timeout10) output {} for cmd in commands: stdin, stdout, stderr client.exec_command(cmd) output[cmd] stdout.read().decode(utf-8, errorsignore) client.close() return output这段代码做的事情很简单按IP连接设备依次执行巡检命令把每条命令的输出以命令名为键存进字典。timeout设10秒是避免某台设备无响应时脚本卡死errorsignore处理设备输出里可能出现的非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错包、会话表这三项的变化方向变化超过阈值时回到设备上复测一次确认不是采集噪声。有了这套脚本之后我的巡检流程变成脚本批量采集、自动填充、人工抽核、结论录入。模板的兼容性在最初几轮要花时间调不同软件版本的输出格式略有差异但跑顺之后一台设备从采集到生成报告不到一分钟。这个改变把巡检从“半天敲命令”变成了“半小时抽核与写结论”回头看值得投入。希望这个方案和这套踩坑记录能帮到你。本文还有配套的精品资源点击获取