简介这份资源面向备战职业院校技能大赛《网络建设与运维》赛项的选手与指导教师核心解决赛题答案自动导出与配置复盘问题。包内共44个文件以21个sh与9个ps1脚本为主覆盖Linux、Windows及网络设备配置导出另含7个zbak备份、5个mp4实操录屏、1个txt说明与1个zip附赠包整体约10.95MB结构清晰便于按设备类型检索。已有154人学习下载说明其在备赛群体中具备一定参考价值。读者可借助脚本理解如何读取配置文件与日志、提取关键信息并按赛制格式整理答案同时通过录屏直观学习网络设备、Windows与Linux服务的配置导出流程配合备份文件与说明文档排查权限与兼容性问题适合需要系统梳理导出思路、查漏补缺的中高级网络竞赛选手。1. 网络建设与运维国赛脚本文件从手工敲命令到一键导出的分水岭带过几届网络建设与运维赛项的选手之后我发现一个很反直觉的现象训练时间最长的那批人往往不是赛场上分数最高的。原因不在技术而在交付方式。这个赛项的设备配置、服务搭建、故障排查如果全靠现场手敲光是重复输入就能吃掉三分之一的时间更别说紧张状态下敲错一个掩码、漏掉一条 ACL 的代价。所谓国赛脚本文件本质就是把「已经验证过的配置流程」固化成可重复执行的文本让选手把脑力留给判断和排错而不是消耗在肌肉记忆上。导出答案视频则是另一层——它把操作过程变成可回看、可复盘、可交付的证据链。这套东西适合正在备赛的选手、带队的指导老师也适合任何需要把网络配置流程标准化的运维人。接下来我会把脚本怎么写、答案怎么导、坑在哪按能直接抄作业的方式讲清楚。2. 脚本文件到底装什么配置骨架、变量与执行顺序2.1 先分清三类脚本别混在一个文件里很多人一上来就把所有命令堆进一个 txt结果换一台设备就全废。常见做法是按职责拆成三类第一类是设备初始化脚本负责清空配置、设置主机名、管理 IP、开启所需服务这部分几乎不随拓扑变化第二类是业务配置脚本负责 VLAN、路由协议、ACL、NAT 这些跟题目强相关的部分变量最多第三类是验证脚本跑完配置后自动执行一批 show 命令把关键状态输出到日志方便比对。拆开的好处是复用。拓扑变了只改业务脚本设备型号变了只改初始化脚本里的接口命名。我一般会在目录里这样组织# 目录结构示例纯文本组织不依赖任何平台 scripts/ init/ # 初始化清配置、主机名、管理地址 init_switch.txt init_router.txt business/ # 业务VLAN、路由、ACL、NAT vlan_plan.txt ospf_area0.txt verify/ # 验证show 命令与期望输出 check_ospf.txt check_vlan.txt这个结构不绑定任何厂商工具你用什么终端软件都能按顺序喂进去。关键是执行顺序不能乱初始化必须在业务之前验证必须在业务之后。顺序错了轻则配置被覆盖重则设备直接失联。2.2 变量抽出来脚本才能跨拓扑复用脚本里最忌讳写死 IP 和 VLAN ID。把会变的东西抽成变量用占位符标记执行前统一替换。比如 VLAN 规划# vlan_plan.txt 模板{} 内为待替换变量 vlan {vlan_id} name {vlan_name} interface {uplink_port} switchport mode trunk switchport trunk allowed vlan {vlan_id}替换时用脚本批量处理避免手工改漏# replace_vars.py把模板里的占位符替换成实际值 # 参数说明template 模板文件mapping 变量字典out 输出文件 def render(template, mapping, out): with open(template, encodingutf-8) as f: text f.read() for key, val in mapping.items(): text text.replace({ key }, str(val)) with open(out, w, encodingutf-8) as f: f.write(text) # 实际调用VLAN 10 对应端口 Gi0/1 render(vlan_plan.txt, {vlan_id: 10, vlan_name: office, uplink_port: Gi0/1}, vlan_10.txt)逻辑很直白读模板、逐项替换、写新文件。参数上要注意两点一是占位符命名统一用下划线别混用大小写二是替换顺序无所谓但变量值里不能包含占位符本身否则会二次替换出问题。这套做法在拓扑频繁调整的训练阶段特别省事改一个字典就能生成一整套配置。2.3 执行顺序与幂等性重复跑不能把设备跑崩脚本要能重复执行。比如初始化脚本里清配置的命令如果设备已经清空再跑一次不能报错中断。常见做法是在关键命令前加容错或者在脚本层面判断当前状态。以清空配置为例# init_switch.txt 片段先尝试清空再设置基础信息 erase startup-config reload # 注意reload 会重启设备训练环境可接受生产环境慎用这里有个血泪经验reload之后设备重启需要时间脚本如果紧接着发下一条命令大概率丢包。稳妥做法是在 reload 后留一个等待或者干脆把初始化拆成两段中间人工确认设备起来再跑第二段。幂等性不是学术概念它直接决定你训练时敢不敢反复跑脚本。3. 导出答案视频把操作过程变成可复盘的证据3.1 导出前先想清楚视频要证明什么导出答案视频不是录屏那么简单。赛项评分看的是操作结果和过程所以视频至少要能证明三件事配置是在哪台设备上做的、命令执行后的状态是什么、整个过程没有跳步或作弊。常见做法是录屏加终端日志双轨录屏记录操作动作终端日志记录命令和回显。两者时间戳对得上证据链才完整。我一般会要求选手在视频开头先展示设备列表和拓扑中间每完成一个模块就执行一次验证命令结尾再整体跑一遍验证脚本。这样视频本身就是一份结构化的答案回看时能快速定位到某个模块。3.2 录制参数怎么设分辨率、帧率与文件大小录制参数直接影响视频能不能用。分辨率太低看不清命令回显太高文件又太大。实测下来终端录屏用 1280x720 或 1920x1080 都行帧率 15 到 30 足够因为终端画面变化不剧烈。关键是字体要够大终端字号调到 16 以上保证压缩后还能看清。参数推荐值说明分辨率1920x1080终端和拓扑图都能看清帧率15 fps终端场景足够文件更小码率2000-4000 kbps低于 2000 回显会糊音频关闭赛项通常不需要省空间格式mp4通用性好便于提交这些值不是死的训练时可以录一段回看如果命令回显模糊就提高码率如果文件太大就降帧率。先保证可读再考虑体积这是原则。3.3 导出后的自检清单三个必查项视频导出后别急着交先自己查三遍。第一查时间连续性有没有跳帧或中断中断处往往就是操作卡壳的地方第二查命令完整性关键配置命令是否都出现在画面里有没有被窗口遮挡第三查验证结果结尾的验证输出是否和预期一致。这三项任何一项不过视频就得重录。提示录制时把无关窗口全部关掉尤其是聊天工具和浏览器标签避免泄露无关信息也避免干扰画面。4. 脚本与视频的配合让答案可复现、可验证4.1 用脚本生成配置用视频记录执行脚本和视频不是两件事而是一条流水线。脚本负责「配置应该长什么样」视频负责「配置是怎么被执行的」。训练时我要求选手先用脚本生成配置文件再照着脚本在设备上执行同时录屏。这样脚本和视频能互相印证视频里敲的命令应该和脚本文件里的内容一致。如果视频里的命令和脚本对不上说明选手临场改了配置这时候要么更新脚本要么重录视频。一致性是这套方法的核心价值它让答案从「一次性操作」变成「可复现流程」。4.2 验证脚本自动比对期望输出光有配置还不够得证明配置生效了。验证脚本的思路是执行一批 show 命令把输出保存下来和期望输出做比对。简单实现# verify.py执行 show 命令并检查关键字段 # 参数说明cmd 要执行的命令expect 期望包含的关键字 import subprocess def check(cmd, expect): # 实际环境中这里替换成你的终端连接方式 out subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue).stdout ok expect in out print(f[{PASS if ok else FAIL}] {cmd} - 期望包含: {expect}) return ok # 检查 OSPF 邻居是否建立 check(show ip ospf neighbor, FULL) # 检查 VLAN 是否创建 check(show vlan brief, office)逻辑是执行命令、抓输出、查关键字。参数上要注意expect要选稳定出现的字段比如FULL比具体邻居 ID 更可靠因为邻居 ID 可能随环境变化。这个脚本跑一遍哪些模块过了、哪些没过一目了然比人工看回显快得多。4.3 把脚本、视频、验证结果打包成一份答案最终交付的答案应该是三件套脚本文件、导出视频、验证结果日志。脚本说明配置内容视频证明执行过程日志证明结果正确。三者放一起评阅的人不用猜直接看就行。训练时按这个标准准备赛场上即使时间紧张也能保证交付物完整。5. 避坑与排查脚本和视频最容易翻车的五个地方5.1 脚本跑一半报错后面全乱现象脚本执行到某条命令时设备报错后续命令继续发但上下文已经错了比如接口没进对后面的配置全配到全局模式。原因脚本没有容错一条命令失败不影响下一条但设备状态已经偏了。解决在关键命令后加验证或者把脚本按模块分段每段执行完人工确认再跑下一段。训练时宁可慢一点也别让错误累积。5.2 视频录到了敏感信息现象导出视频里出现了不该出现的窗口、文件名或账号信息。原因录制前没清理桌面或者终端标题栏带了路径。解决录制前关掉所有无关程序终端标题改成中性名称录制区域只框住终端和拓扑图。这个习惯要养成不然重录很浪费时间。5.3 变量替换后配置对不上现象脚本生成的配置里 IP 或 VLAN 不对设备起不来。原因变量字典里某个值写错或者模板占位符拼写不一致导致没替换成功。解决替换后先肉眼扫一遍生成的文件重点看 IP、掩码、VLAN ID。也可以写个检查脚本扫描生成文件里是否还有未替换的{}占位符。5.4 视频文件太大传不出去现象录完发现文件几个 G提交时超限。原因分辨率或码率设太高或者录了无关的长片段。解决按第 3 章的参数表设置录完后用工具压缩或者只保留关键片段。训练时就按提交要求录别等最后才发现超限。5.5 验证脚本的期望值写太死现象验证脚本总是 FAIL但人工看设备状态是对的。原因期望字段选得太具体比如写了完整的邻居 ID 或时间戳环境一变就不匹配。解决期望值选稳定字段比如状态词FULL、up而不是动态值。验证脚本的目的是确认功能正常不是做精确字符串匹配。6. 进阶技巧用版本管理管脚本用时间戳管视频脚本写多了改来改去容易乱。我后来养成一个习惯用 git 管脚本目录每次训练前 commit 一次训练中改了什么一目了然。视频文件用时间戳命名比如20240520_1430_ospf.mp4按时间排序就能还原训练过程。这两个习惯看着简单但能省下大量「上次改的是哪版」的纠结。再进一步可以把验证脚本的输出也存成带时间戳的日志和视频文件名对应。这样回看时视频看到某个时间点直接找对应日志不用重新跑一遍设备。训练后期我基本靠这套方法复盘哪个模块弱、哪次操作慢翻记录就知道。最后一个具体技巧脚本里的注释要写「为什么」而不是「是什么」。比如# 这里先配 trunk 再配 access因为题目要求先通再隔离这种注释在复盘时比# 配置 trunk有用得多。我吃过亏隔一周再看自己的脚本只写「是什么」的注释完全想不起当时的判断依据只能重跑一遍。希望帮到你。本文还有配套的精品资源点击获取