尧图网页设计 
简介这份《防火墙巡检报告书模版》面向网络运维工程师、安全运维人员及IT外包服务团队用于规范Juniper防火墙的日常巡检流程与报告输出。模版以表格化条目呈现覆盖软件版本核对、日志与调试开关检查、系统时间与时区、telnet/web/snmp登录控制、多接口监控、双机配置同步、接口与IP地址分配、CPU与内存使用率、系统连接数、区域与域间策略、设备及接口指示灯等近二十项检查内容每项均给出Web与命令行两种检查方法及判定标准可直接套用形成标准化巡检记录。资源包为单一PDF文件共1个文件体积约78KB轻量易传输打印或电子归档均方便。目前已有116人学习下载适合需要快速建立防火墙巡检规范、统一报告格式的运维人员参考使用也可作为团队内部培训与巡检执行的模板依据。1. 防火墙巡检报告书模版从手工填表到半自动出报告的落地路径每月月底运维群里总会准时出现同一句话“这个月的防火墙巡检报告谁写”然后就是漫长的沉默。不是没人会写而是没人想写——十几台防火墙品牌横跨华为 USG、H3C、Juniper SSG、山石、深信服每台都要登进去敲show命令、截图、复制粘贴到 Word 里再手动填 CPU、内存、会话数、策略命中数。一份报告折腾两三天写完还没人看。防火墙巡检报告书模版.pdf 这类文件之所以被反复搜索本质上不是缺一个 PDF 格式而是缺一套“能自动采集、能套模板、能批量出报告”的方法。这篇笔记就按我实际落地的路径把巡检项怎么定、命令怎么采、数据怎么灌进模板、坑在哪一步步拆开讲。适合手里管着几台到几十台防火墙、每月被巡检报告折磨的运维和安服人员。2. 巡检项怎么定一份能落地的报告该采哪些数据2.1 从“报告给谁看”倒推采集字段很多人一上来就打开防火墙把所有能show的东西全导出来结果报告几十页领导翻两页就扔了。我踩过这个坑之后改成先问一句这份报告给谁看通常两类人——一是等保测评或内审要留痕的合规人员二是想知道网络有没有隐患的技术负责人。前者关心“有没有做、什么时候做的、结果是否正常”后者关心“CPU 高不高、会话有没有打满、策略有没有异常命中”。所以巡检项分三层基础信息层设备型号、固件版本、运行时长、HA 状态、健康指标层CPU、内存、会话数/并发连接、接口流量与错包、安全策略层策略总数、命中数为零的策略、最近变更记录、日志告警。这三层对应报告里的三张表不多不少。下面这张表是我现在用的字段清单可以直接抄层级字段采集方式正常判定基础信息设备型号/固件版本show version记录即可基础信息运行时长show system记录即可基础信息HA 主备状态show ha state主主或主备正常健康指标CPU 5 分钟均值show cpu持续低于 70%健康指标内存使用率show memory低于 80%健康指标会话数/并发连接show session低于规格 80%健康指标接口错包/丢包show interface错包增长为 0安全策略策略总数show policy记录即可安全策略零命中策略数show policy hit标记待清理安全策略最近配置变更show config diff记录即可这张表的价值在于它把“巡检”从模糊的“看看设备”变成了可勾选的清单。你拿着它去任何品牌防火墙上找对应命令找不到的就标“该型号不支持”而不是漏掉。2.2 不同品牌命令的对应关系热词里反复出现 Juniper、NetScreen、华为 USG、H3C、山石、锐捷说明大家手里的设备很杂。我整理了一份常用命令对照注意 Juniper SSGNetScreen 系的命令风格和老 ScreenOS 一致和 Junos 完全不同别搞混巡检项华为 USGH3CJuniper SSG (ScreenOS)山石版本display versiondisplay versionget systemshow versionCPUdisplay cpu-usagedisplay cpu-usageget perf cpushow cpu内存display memory-usagedisplay memoryget perf memoryshow memory会话display session tabledisplay sessionget sessionshow session策略display security-policydisplay security-policyget policyshow policy接口display interface briefdisplay interface briefget interfaceshow interface提示Juniper SSG5 这类老设备默认账号密码如果被改过又没记录别硬猜走 console 口恢复流程比反复试密码快得多。采集方式上如果设备开了 SSH用 Python 的 paramiko 批量登录执行命令最省事如果只有 console 或 Web那就退化成半自动——Web 界面截图 手工填表但模板结构不变。下面这段是我常用的采集脚本骨架改改命令列表就能适配不同品牌import paramiko import csv from datetime import datetime # 设备清单IP、品牌、用户名、密码 devices [ {ip: 10.0.0.1, brand: huawei, user: admin, pwd: xxx}, {ip: 10.0.0.2, brand: h3c, user: admin, pwd: xxx}, ] # 各品牌命令映射key 是巡检项value 是命令 cmds { huawei: {version: display version, cpu: display cpu-usage, mem: display memory-usage, session: display session table}, h3c: {version: display version, cpu: display cpu-usage, mem: display memory, session: display session}, } def collect(dev): ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(dev[ip], usernamedev[user], passworddev[pwd], timeout10) result {ip: dev[ip], brand: dev[brand], time: datetime.now().isoformat()} for item, cmd in cmds[dev[brand]].items(): stdin, stdout, stderr ssh.exec_command(cmd) result[item] stdout.read().decode(utf-8, errorsignore) ssh.close() return result rows [collect(d) for d in devices] with open(inspect_raw.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows)这段代码的逻辑很直白遍历设备清单按品牌选命令集SSH 登录后逐条执行把原始输出存成 CSV。关键参数是timeout10老设备响应慢设太短会频繁超时errorsignore是为了防止某些设备输出里有非 UTF-8 字符导致解码报错。跑完你会得到一个inspect_raw.csv里面是各设备的原始回显下一步就是从这些回显里提取数值。2.3 从原始回显到结构化数据原始回显不能直接进报告得先解析成“CPU45%”这样的结构化字段。不同品牌回显格式差异很大用正则逐品牌写解析规则最稳。比如华为的 CPU 回显里通常有CPU Usage Stat. Cycle: 5 minutes和CPU Usage : 45%H3C 的格式又不一样。我的做法是每个品牌写一个解析函数输入原始文本输出字典。解析失败的项标N/A不要让它变成空值——空值在报告里看起来像漏采N/A至少说明“采了但没解析出来”方便排查。这一步做完你手里就有一份结构化的巡检数据了。接下来才是模板的事。3. 报告书模版怎么设计字段、判定与自动填充3.1 模板结构三张表加一段结论一份能用的防火墙巡检报告书模版结构不需要花哨。我现在的模板就四块封面信息报告名称、巡检周期、巡检人、设备总数、设备清单表每台设备一行列出型号、IP、固件版本、运行时长、健康指标表每台设备的 CPU、内存、会话、接口状态带正常/异常标记、策略与变更表策略总数、零命中策略、最近变更记录。最后加一段自动生成的结论比如“本次巡检共 12 台设备2 台 CPU 峰值超过 70%1 台存在零命中策略 37 条建议清理”。模板格式用 Word 的.docx最通用因为要交给别人看和存档。Python 里用python-docx库可以直接读写 docx把数据灌进去。如果你更习惯 Markdown也可以先出 Markdown 再转 PDF但很多单位的归档要求是 Word所以 docx 是首选。3.2 用 python-docx 把数据灌进模板先准备一个手工做好的 docx 模板里面表格的表头写好数据行留空。然后用脚本打开模板定位到表格逐行填数据。下面这段是核心逻辑from docx import Document doc Document(防火墙巡检报告模板.docx) # 假设第一个表格是设备清单表从第2行开始填数据 table doc.tables[0] for i, dev in enumerate(devices_data, start1): row table.rows[i] row.cells[0].text dev[ip] row.cells[1].text dev[brand] row.cells[2].text dev[version] row.cells[3].text dev[uptime] # 第二个表格是健康指标表 health_table doc.tables[1] for i, dev in enumerate(devices_data, start1): row health_table.rows[i] row.cells[0].text dev[ip] row.cells[1].text dev[cpu] row.cells[2].text dev[mem] row.cells[3].text dev[session] # 超过阈值标红 if float(dev[cpu].strip(%)) 70: row.cells[1].paragraphs[0].runs[0].font.color.rgb RGBColor(0xFF, 0x00, 0x00) doc.save(f防火墙巡检报告_{datetime.now().strftime(%Y%m)}.docx)逻辑说明doc.tables[0]按模板里表格出现的顺序取表所以模板设计时表格顺序要固定。填数据从start1开始因为第 0 行是表头。标红那段是给异常值加视觉提示RGBColor需要从docx.shared导入。参数上阈值 70% 是我自己的经验值你可以按设备规格调整——低端设备 CPU 长期 60% 就该关注了高端设备 80% 以下都算正常。注意python-docx 对合并单元格的支持不太好模板里尽量不要用跨行跨列的复杂表头否则填数据时row.cells的索引会对不上。3.3 判定逻辑什么算异常报告里不能只列数据得有判定。我的判定规则很简单CPU 持续 5 分钟超过 70% 标黄超过 85% 标红内存超过 80% 标黄超过 90% 标红会话数超过设备规格 80% 标黄接口错包数大于 0 标红零命中策略超过 20 条标黄。这些阈值写在一个配置文件里脚本读取后逐项比对生成“正常/关注/异常”三档标记。这样报告交上去领导一眼就能看到哪台设备需要处理而不是对着一堆数字自己判断。配置文件用 YAML 或 JSON 都行我习惯用 JSON因为 Python 标准库直接支持{ cpu_warn: 70, cpu_crit: 85, mem_warn: 80, mem_crit: 90, session_warn_ratio: 0.8, zero_hit_policy_warn: 20 }脚本读这个文件把阈值和采集数据比对输出每台设备的判定结果。阈值可调的好处是不同单位、不同设备档次可以套不同标准不用改代码。4. 批量巡检与报告生成的避坑记录4.1 避坑一SSH 超时导致采集不全现象脚本跑完部分设备的 CPU、内存字段是空的但设备明明在线。原因老设备 SSH 响应慢exec_command默认没有超时或超时太短命令还没返回就断了。另外有些设备限制并发 SSH 会话数脚本同时连太多会被拒绝。解决给exec_command加timeout30并在设备之间加time.sleep(2)错开连接。如果设备限制并发把采集改成串行别用多线程。4.2 避坑二回显里的分页符打断解析现象华为或 H3C 设备回显里出现---- More ----解析出来的数据缺了后半段。原因设备默认分页显示一屏满了就暂停等按键。解决登录后先发screen-length 0 temporary华为/H3C或set cli screen-length 0Juniper关闭分页再执行巡检命令。这个命令要放在采集命令之前且每条 SSH 会话都要发一次。4.3 避坑三模板表格行数不够现象脚本填数据时报IndexError: list index out of range。原因模板里表格只预留了 5 行但实际有 12 台设备。解决两种做法——一是模板里多留空行比如按最大设备数留 50 行二是脚本里动态加行用table.add_row()。我倾向动态加行因为空行多了打印出来难看。动态加行时注意新行的单元格格式会继承上一行如果上一行有标红新行也会红需要手动重置字体颜色。4.4 避坑四不同品牌固件版本回显格式不一致现象同一品牌不同型号display version的输出格式不同正则匹配不到版本号。原因固件版本升级后回显格式可能变或者同品牌不同产品线格式本来就不一样。解决解析函数写成“多模式匹配”先试模式 A失败再试模式 B都失败就存原始文本并标N/A。别追求 100% 解析率80% 自动加 20% 手工补比追求完美导致脚本频繁报错划算。4.5 避坑五报告里的时间戳和时区现象报告生成时间是 UTC但单位要求北京时间交上去被退回。原因服务器或脚本运行环境时区设置不对。解决在脚本里显式指定时区用datetime.now(timezone(timedelta(hours8)))生成北京时间。别依赖系统时区不同机器跑出来的时间可能不一样。5. 进阶把巡检报告变成趋势分析单次报告只能看当下真正有价值的是把每月数据存下来做趋势。我的做法是每次采集完除了生成 docx再把结构化数据追加到一个 SQLite 库里表结构就是设备 IP、采集时间、CPU、内存、会话数。跑上几个月你就能回答“这台防火墙的 CPU 是不是在缓慢上涨”这种问题而不是只看当月快照。import sqlite3 conn sqlite3.connect(firewall_inspect.db) conn.execute(CREATE TABLE IF NOT EXISTS metrics ( ip TEXT, ts TEXT, cpu REAL, mem REAL, session INTEGER)) for dev in devices_data: conn.execute(INSERT INTO metrics VALUES (?, ?, ?, ?, ?), (dev[ip], dev[time], dev[cpu_val], dev[mem_val], dev[session_val])) conn.commit() conn.close()建好库之后用一条 SQL 就能拉出某台设备近半年的 CPU 走势SELECT ts, cpu FROM metrics WHERE ip 10.0.0.1 ORDER BY ts;把结果丢进 Excel 或 matplotlib 画条线附在报告最后比干巴巴的数字有说服力得多。我现在每季度会基于这个库出一份趋势简报标出“持续增长”和“突然跳变”的设备提前处理过两次内存泄漏都是在还没影响业务的时候发现的。提示SQLite 文件别放在临时目录放一个固定路径并定期备份。巡检数据本身不大一年也就几万行但丢了就得重新积累。最后说个我自己的习惯模板和脚本我会放在同一个目录下用 Git 管起来。每次改阈值或加设备提交一次出问题能回滚。巡检报告这事做一次不难难的是每月都做、做得一致。把采集和填充自动化之后我现在每月花在巡检报告上的时间从两三天压到半小时——跑脚本十分钟检查异常项二十分钟。剩下的时间用来处理报告里标红的那几台设备比填表有意义得多。希望帮到你。本文还有配套的精品资源点击获取 防火墙巡检报告自动化：多品牌设备采集与模板生成实战
简介这份《防火墙巡检报告书模版》面向网络运维工程师、安全运维人员及IT外包服务团队用于规范Juniper防火墙的日常巡检流程与报告输出。模版以表格化条目呈现覆盖软件版本核对、日志与调试开关检查、系统时间与时区、telnet/web/snmp登录控制、多接口监控、双机配置同步、接口与IP地址分配、CPU与内存使用率、系统连接数、区域与域间策略、设备及接口指示灯等近二十项检查内容每项均给出Web与命令行两种检查方法及判定标准可直接套用形成标准化巡检记录。资源包为单一PDF文件共1个文件体积约78KB轻量易传输打印或电子归档均方便。目前已有116人学习下载适合需要快速建立防火墙巡检规范、统一报告格式的运维人员参考使用也可作为团队内部培训与巡检执行的模板依据。1. 防火墙巡检报告书模版从手工填表到半自动出报告的落地路径每月月底运维群里总会准时出现同一句话“这个月的防火墙巡检报告谁写”然后就是漫长的沉默。不是没人会写而是没人想写——十几台防火墙品牌横跨华为 USG、H3C、Juniper SSG、山石、深信服每台都要登进去敲show命令、截图、复制粘贴到 Word 里再手动填 CPU、内存、会话数、策略命中数。一份报告折腾两三天写完还没人看。防火墙巡检报告书模版.pdf 这类文件之所以被反复搜索本质上不是缺一个 PDF 格式而是缺一套“能自动采集、能套模板、能批量出报告”的方法。这篇笔记就按我实际落地的路径把巡检项怎么定、命令怎么采、数据怎么灌进模板、坑在哪一步步拆开讲。适合手里管着几台到几十台防火墙、每月被巡检报告折磨的运维和安服人员。2. 巡检项怎么定一份能落地的报告该采哪些数据2.1 从“报告给谁看”倒推采集字段很多人一上来就打开防火墙把所有能show的东西全导出来结果报告几十页领导翻两页就扔了。我踩过这个坑之后改成先问一句这份报告给谁看通常两类人——一是等保测评或内审要留痕的合规人员二是想知道网络有没有隐患的技术负责人。前者关心“有没有做、什么时候做的、结果是否正常”后者关心“CPU 高不高、会话有没有打满、策略有没有异常命中”。所以巡检项分三层基础信息层设备型号、固件版本、运行时长、HA 状态、健康指标层CPU、内存、会话数/并发连接、接口流量与错包、安全策略层策略总数、命中数为零的策略、最近变更记录、日志告警。这三层对应报告里的三张表不多不少。下面这张表是我现在用的字段清单可以直接抄层级字段采集方式正常判定基础信息设备型号/固件版本show version记录即可基础信息运行时长show system记录即可基础信息HA 主备状态show ha state主主或主备正常健康指标CPU 5 分钟均值show cpu持续低于 70%健康指标内存使用率show memory低于 80%健康指标会话数/并发连接show session低于规格 80%健康指标接口错包/丢包show interface错包增长为 0安全策略策略总数show policy记录即可安全策略零命中策略数show policy hit标记待清理安全策略最近配置变更show config diff记录即可这张表的价值在于它把“巡检”从模糊的“看看设备”变成了可勾选的清单。你拿着它去任何品牌防火墙上找对应命令找不到的就标“该型号不支持”而不是漏掉。2.2 不同品牌命令的对应关系热词里反复出现 Juniper、NetScreen、华为 USG、H3C、山石、锐捷说明大家手里的设备很杂。我整理了一份常用命令对照注意 Juniper SSGNetScreen 系的命令风格和老 ScreenOS 一致和 Junos 完全不同别搞混巡检项华为 USGH3CJuniper SSG (ScreenOS)山石版本display versiondisplay versionget systemshow versionCPUdisplay cpu-usagedisplay cpu-usageget perf cpushow cpu内存display memory-usagedisplay memoryget perf memoryshow memory会话display session tabledisplay sessionget sessionshow session策略display security-policydisplay security-policyget policyshow policy接口display interface briefdisplay interface briefget interfaceshow interface提示Juniper SSG5 这类老设备默认账号密码如果被改过又没记录别硬猜走 console 口恢复流程比反复试密码快得多。采集方式上如果设备开了 SSH用 Python 的 paramiko 批量登录执行命令最省事如果只有 console 或 Web那就退化成半自动——Web 界面截图 手工填表但模板结构不变。下面这段是我常用的采集脚本骨架改改命令列表就能适配不同品牌import paramiko import csv from datetime import datetime # 设备清单IP、品牌、用户名、密码 devices [ {ip: 10.0.0.1, brand: huawei, user: admin, pwd: xxx}, {ip: 10.0.0.2, brand: h3c, user: admin, pwd: xxx}, ] # 各品牌命令映射key 是巡检项value 是命令 cmds { huawei: {version: display version, cpu: display cpu-usage, mem: display memory-usage, session: display session table}, h3c: {version: display version, cpu: display cpu-usage, mem: display memory, session: display session}, } def collect(dev): ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(dev[ip], usernamedev[user], passworddev[pwd], timeout10) result {ip: dev[ip], brand: dev[brand], time: datetime.now().isoformat()} for item, cmd in cmds[dev[brand]].items(): stdin, stdout, stderr ssh.exec_command(cmd) result[item] stdout.read().decode(utf-8, errorsignore) ssh.close() return result rows [collect(d) for d in devices] with open(inspect_raw.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows)这段代码的逻辑很直白遍历设备清单按品牌选命令集SSH 登录后逐条执行把原始输出存成 CSV。关键参数是timeout10老设备响应慢设太短会频繁超时errorsignore是为了防止某些设备输出里有非 UTF-8 字符导致解码报错。跑完你会得到一个inspect_raw.csv里面是各设备的原始回显下一步就是从这些回显里提取数值。2.3 从原始回显到结构化数据原始回显不能直接进报告得先解析成“CPU45%”这样的结构化字段。不同品牌回显格式差异很大用正则逐品牌写解析规则最稳。比如华为的 CPU 回显里通常有CPU Usage Stat. Cycle: 5 minutes和CPU Usage : 45%H3C 的格式又不一样。我的做法是每个品牌写一个解析函数输入原始文本输出字典。解析失败的项标N/A不要让它变成空值——空值在报告里看起来像漏采N/A至少说明“采了但没解析出来”方便排查。这一步做完你手里就有一份结构化的巡检数据了。接下来才是模板的事。3. 报告书模版怎么设计字段、判定与自动填充3.1 模板结构三张表加一段结论一份能用的防火墙巡检报告书模版结构不需要花哨。我现在的模板就四块封面信息报告名称、巡检周期、巡检人、设备总数、设备清单表每台设备一行列出型号、IP、固件版本、运行时长、健康指标表每台设备的 CPU、内存、会话、接口状态带正常/异常标记、策略与变更表策略总数、零命中策略、最近变更记录。最后加一段自动生成的结论比如“本次巡检共 12 台设备2 台 CPU 峰值超过 70%1 台存在零命中策略 37 条建议清理”。模板格式用 Word 的.docx最通用因为要交给别人看和存档。Python 里用python-docx库可以直接读写 docx把数据灌进去。如果你更习惯 Markdown也可以先出 Markdown 再转 PDF但很多单位的归档要求是 Word所以 docx 是首选。3.2 用 python-docx 把数据灌进模板先准备一个手工做好的 docx 模板里面表格的表头写好数据行留空。然后用脚本打开模板定位到表格逐行填数据。下面这段是核心逻辑from docx import Document doc Document(防火墙巡检报告模板.docx) # 假设第一个表格是设备清单表从第2行开始填数据 table doc.tables[0] for i, dev in enumerate(devices_data, start1): row table.rows[i] row.cells[0].text dev[ip] row.cells[1].text dev[brand] row.cells[2].text dev[version] row.cells[3].text dev[uptime] # 第二个表格是健康指标表 health_table doc.tables[1] for i, dev in enumerate(devices_data, start1): row health_table.rows[i] row.cells[0].text dev[ip] row.cells[1].text dev[cpu] row.cells[2].text dev[mem] row.cells[3].text dev[session] # 超过阈值标红 if float(dev[cpu].strip(%)) 70: row.cells[1].paragraphs[0].runs[0].font.color.rgb RGBColor(0xFF, 0x00, 0x00) doc.save(f防火墙巡检报告_{datetime.now().strftime(%Y%m)}.docx)逻辑说明doc.tables[0]按模板里表格出现的顺序取表所以模板设计时表格顺序要固定。填数据从start1开始因为第 0 行是表头。标红那段是给异常值加视觉提示RGBColor需要从docx.shared导入。参数上阈值 70% 是我自己的经验值你可以按设备规格调整——低端设备 CPU 长期 60% 就该关注了高端设备 80% 以下都算正常。注意python-docx 对合并单元格的支持不太好模板里尽量不要用跨行跨列的复杂表头否则填数据时row.cells的索引会对不上。3.3 判定逻辑什么算异常报告里不能只列数据得有判定。我的判定规则很简单CPU 持续 5 分钟超过 70% 标黄超过 85% 标红内存超过 80% 标黄超过 90% 标红会话数超过设备规格 80% 标黄接口错包数大于 0 标红零命中策略超过 20 条标黄。这些阈值写在一个配置文件里脚本读取后逐项比对生成“正常/关注/异常”三档标记。这样报告交上去领导一眼就能看到哪台设备需要处理而不是对着一堆数字自己判断。配置文件用 YAML 或 JSON 都行我习惯用 JSON因为 Python 标准库直接支持{ cpu_warn: 70, cpu_crit: 85, mem_warn: 80, mem_crit: 90, session_warn_ratio: 0.8, zero_hit_policy_warn: 20 }脚本读这个文件把阈值和采集数据比对输出每台设备的判定结果。阈值可调的好处是不同单位、不同设备档次可以套不同标准不用改代码。4. 批量巡检与报告生成的避坑记录4.1 避坑一SSH 超时导致采集不全现象脚本跑完部分设备的 CPU、内存字段是空的但设备明明在线。原因老设备 SSH 响应慢exec_command默认没有超时或超时太短命令还没返回就断了。另外有些设备限制并发 SSH 会话数脚本同时连太多会被拒绝。解决给exec_command加timeout30并在设备之间加time.sleep(2)错开连接。如果设备限制并发把采集改成串行别用多线程。4.2 避坑二回显里的分页符打断解析现象华为或 H3C 设备回显里出现---- More ----解析出来的数据缺了后半段。原因设备默认分页显示一屏满了就暂停等按键。解决登录后先发screen-length 0 temporary华为/H3C或set cli screen-length 0Juniper关闭分页再执行巡检命令。这个命令要放在采集命令之前且每条 SSH 会话都要发一次。4.3 避坑三模板表格行数不够现象脚本填数据时报IndexError: list index out of range。原因模板里表格只预留了 5 行但实际有 12 台设备。解决两种做法——一是模板里多留空行比如按最大设备数留 50 行二是脚本里动态加行用table.add_row()。我倾向动态加行因为空行多了打印出来难看。动态加行时注意新行的单元格格式会继承上一行如果上一行有标红新行也会红需要手动重置字体颜色。4.4 避坑四不同品牌固件版本回显格式不一致现象同一品牌不同型号display version的输出格式不同正则匹配不到版本号。原因固件版本升级后回显格式可能变或者同品牌不同产品线格式本来就不一样。解决解析函数写成“多模式匹配”先试模式 A失败再试模式 B都失败就存原始文本并标N/A。别追求 100% 解析率80% 自动加 20% 手工补比追求完美导致脚本频繁报错划算。4.5 避坑五报告里的时间戳和时区现象报告生成时间是 UTC但单位要求北京时间交上去被退回。原因服务器或脚本运行环境时区设置不对。解决在脚本里显式指定时区用datetime.now(timezone(timedelta(hours8)))生成北京时间。别依赖系统时区不同机器跑出来的时间可能不一样。5. 进阶把巡检报告变成趋势分析单次报告只能看当下真正有价值的是把每月数据存下来做趋势。我的做法是每次采集完除了生成 docx再把结构化数据追加到一个 SQLite 库里表结构就是设备 IP、采集时间、CPU、内存、会话数。跑上几个月你就能回答“这台防火墙的 CPU 是不是在缓慢上涨”这种问题而不是只看当月快照。import sqlite3 conn sqlite3.connect(firewall_inspect.db) conn.execute(CREATE TABLE IF NOT EXISTS metrics ( ip TEXT, ts TEXT, cpu REAL, mem REAL, session INTEGER)) for dev in devices_data: conn.execute(INSERT INTO metrics VALUES (?, ?, ?, ?, ?), (dev[ip], dev[time], dev[cpu_val], dev[mem_val], dev[session_val])) conn.commit() conn.close()建好库之后用一条 SQL 就能拉出某台设备近半年的 CPU 走势SELECT ts, cpu FROM metrics WHERE ip 10.0.0.1 ORDER BY ts;把结果丢进 Excel 或 matplotlib 画条线附在报告最后比干巴巴的数字有说服力得多。我现在每季度会基于这个库出一份趋势简报标出“持续增长”和“突然跳变”的设备提前处理过两次内存泄漏都是在还没影响业务的时候发现的。提示SQLite 文件别放在临时目录放一个固定路径并定期备份。巡检数据本身不大一年也就几万行但丢了就得重新积累。最后说个我自己的习惯模板和脚本我会放在同一个目录下用 Git 管起来。每次改阈值或加设备提交一次出问题能回滚。巡检报告这事做一次不难难的是每月都做、做得一致。把采集和填充自动化之后我现在每月花在巡检报告上的时间从两三天压到半小时——跑脚本十分钟检查异常项二十分钟。剩下的时间用来处理报告里标红的那几台设备比填表有意义得多。希望帮到你。本文还有配套的精品资源点击获取