从“脚本小子”到“乐高玩家”：聊聊我的Python网络自动化巡检心得，核心就俩字：解耦！

引言

 

本文旨在向大家分享原子化网络巡检架构的设计思路。通过解构网络巡检诊断流程的核心要素模块，构建可编排的自动化流水线，并延伸至可视化流程编排的进阶实现。

 

巡检转维的“爱恨情仇”

 

搞网络这些年，巡检和转维这俩活儿，着实让人又爱又恨。爱的是入网巡检作为网络运维的第一道“护城河”，能在第一时间有效识别风险隐患，确保设备合规入网，为现网稳定运行保驾护航；恨的是其重复、繁琐、体量庞大的特性，常令人苦不堪言。

相信不少同行和我一样，都尝试过用Python脚本来自动化巡检用例或流程，试图把自己从“人肉CLI”中解放出来。笔者所在的公司亦是如此——近5年网络设备数量增速巨快，单板、光模块等零部件数量更是无比庞大。在数字化加速的背景下，我也从处理故障、变更的传统网工，转变为全职负责网络转产验收及平台建设的专项网工。历经多年积累与沉淀，公司的入网转产已从“人工为主，工具为辅”蜕变为如今的“工具主导，人工为辅”。目前，自动化巡检用例已达95%，九成的交付场景已实现了自动验收→自动转维的平台自动作业流程。

然而，自动化之路并非坦途，相信大家和我一样都踩过如下这些“深坑”：

1. “祖传脚本”综合症： 写完巡检脚本，当时美滋滋。结果设备型号一换、基线一更新、或者巡检要求加个新检查项... 完犊子！脚本得大改！改着改着就成了无人敢碰的“屎山”，自己都不想看第二眼。这就是典型的“脚本小子”困境——高度定制化导致代码质量脆弱不堪、隐患横生、任何微小的基线改动都需要修改代码。

2. “复制粘贴”工程师： 不同场景（比如查端口状态和查BGP邻居），需求不同，逻辑不同。结果就是每个需求都得吭哧吭哧从头写新脚本，测试用例，评审，上线...或在一个大脚本里疯狂堆叠代码。效率低下、重复造轮子、极易引入新Bug。

3. “黑盒子”恐慌： 脚本写得稍复杂点，过俩月自己都忘了内部逻辑如何流转。更别提交接给其他同事，人家一看密密麻麻的代码就头大，维护和交接成本巨高。

这种传统的、强耦合的脚本化巡检模式，已然面临严峻的效率瓶颈与技术断层。

 

顿悟：解耦是核心，拥抱“乐高”哲学！

 

 

在无数次踩坑后，我终于顿悟：网络自动化巡检/转维的核心竞争力，不在于编写多么高深的代码，而在于将“业务逻辑” 与“代码实现” 彻底分离！用行业术语说，就是“解耦”。

如何实现解耦？原子化 + 可视化编排 + 工作流引擎 ，必是不二之选！

 

解构网络巡检：在包罗万象的每一个巡检业务中提炼出殊途同归的原子动作

 

在探讨方案前，我们先梳理网络巡检的典型范畴：

• 设备基础信息： OS版本、补丁、License、整机及部件型号（含配比）。

• 设备硬件状态： 电源、风扇、单板、接口、光模块状态等。

• 配置信息： 网络管理、交换、路由、可靠性、安全、QoS等配置是否符合基线。

• 协议状态： OSPF、BGP、BFD等协议运行状态。

• 表项规格及产品特性： 如大路由表能力、框式设备单板互通模式、IPv6资源等。

• 架构及工程合规： 检查交付单元（网元、带宽、收敛比、物理连线、IP资源、AS号、BGP团体字等）是否符合企业网络架构设计与工程规划。

• 运维平台纳管： 确认设备是否已在CMDB、日志、告警、自动化作业等平台纳管。

• 深度巡检： 由现网告警/故障触发的软件级或芯片级深度检查。

• 其他未列举项

从业务角度看，网络巡检涵盖方面不可谓不复杂，从软件到硬件、从静态配置到协议状态、从单个网元到整网的方方面面，可谓包罗万象。

然而，从执行流程看，无论任务简单或复杂，核心无非是执行以下几类“原子动作”：

1，获取信息 (Fetch)：

• 通过CLI执行命令获取信息（display version, display interface...）。

• 从CMDB或其他API获取设备信息（IP、型号、位置...）。

• 从监控系统获取性能数据（CPU、内存...）。

• 从基线系统获取数据（配置基线、工程规划...）。

2，处理信息 (Process/Transform)：

• 文本处理： 切分、拼接、删减。

• 文本解析： 使用正则表达式或TextFSM等库，将CLI返回的非结构化文本转换为结构化的数据（字典、列表），如JSON格式，便于后续处理。

• 变量转换： 对已解析变量进行条件过滤、数据类型转换、键值映射等操作，生成新变量。

• 动态代码 (可选)： 对于极其复杂的处理，可通过Python的exec()函数封装动态代码执行引擎（谨慎使用，但威力强大）。

• 命令渲染： 使用Jinja2模板，结合中间变量生成待下发的命令集。

3，逻辑控制 (Control Flow)：

• 选择器： 实现条件分支（类似if...elif...else），决定下一步执行哪个原子动作。

• 循环器： 实现循环逻辑。

4，判断决策 (Decide/Output)：

• 合规检查： 判断配置或状态是否符合规范（例如：是否配置了ACL？SNMP版本是否正确？BGP团体字中是否包含特定字段如上联AS号？）。

• 合规条件： 基于解析后的结构化数据进行逻辑判断（“端口状态是否为down？”，“CPU利用率是否>80%？”）。将合规条件抽象为对变量数据的运算（字符串包含、整数比较、列表操作等）。

• 输出结果： 生成报告、触发告警、或驱动后续动作（如自动修复）。

 

核心思想：构建可复用的“原子积木”

重点来了！上述列出的每一个“原子动作”（如“获取CLI回显”、“文本解析”、“条件判断”、“变量聚合”等），都应该被设计成独立的、高度可复用的“小积木”（即模块化函数或组件）！

“搭积木”式编排：可视化与工作流引擎

拥有了这些标准化、原子化的“小积木”，巡检用例的构建方式将发生革命性变化——无需再编写冗长、耦合的脚本，而是进行可视化“搭积木”！

想象一个类似Visio或流程图工具的可视化界面：

1. “零件盒”： 左侧区域存放所有预定义好的原子动作积木，例如：【下发命令】、【获取CMDB信息】、【TextFSM解析】、【选择器】、【合规条件判断】、【聚合数据】...

2. “画布”： 中央工作区。

3. 构建流程：用箭头将需要的积木按业务逻辑顺序连接起来，形成一个有向无环图 (DAG)，清晰表达执行流程。

4. 节点配置： 双击每个积木进行具体参数配置（如命令字符串、模板路径、判断条件等）。

5. 保存与执行： 给这个流程图命名（如内存使用率巡检），点击“保存”即可，后续需要执行时通过执行引擎调用这个流程图即可。

 

解耦架构的显著优势

告别“脚本小子”，拥抱“乐高大师”：

• 业务与代码分离： 原子动作的底层实现（由少数“积木开发者”维护）与上层的巡检逻辑编排完全解耦。网络工程师（即使不懂Python）也能通过拖拉拽和配置完成复杂巡检的设计。

• 业务逻辑可视化： 流程图本身就是清晰、直观的设计文档，彻底告别“黑盒子”。

 

复用度爆表，效率飙升：

• 一次开发，处处使用： 构建新的巡检用例时，只需在“零件盒”中选取现有积木进行组合与配置，效率极高，彻底摆脱“复制粘贴工程师”的窘境。

 

灵活敏捷，响应快速：

• 需求变更易如反掌： 例如内存阈值需从20%调至15%，只需修改积木的配置参数即可，整个流程无需改动。

• 环境适应性强： 设备型号升级导致解析规则变化？仅需更新对应的TextFSM模板文件，所有使用该解析积木的巡检任务将自动生效。

 

门槛降低，维护无忧：

• 易于理解与交接： 流程图是最佳的活文档，新人一目了然。维护时能快速定位问题积木，检查配置或查看日志。

• 协作更顺畅： 不同角色（架构师、工程师、开发者）能在统一的可视化模型上高效沟通。

 

无缝延伸至自动化转维：

• 转维即检查项组合： 转维本质是一系列检查用例的组合。利用相同的“原子积木”和“可视化编排”思路，可轻松将CheckList自动化，生成标准化的转维报告，极大提升转维效率和可靠性。

 

结语

 

编排的本质是知识沉淀 -- 把老师傅的诊断经验变成可复用的原子能力，OK，今天先写这么多，后续将继续在文章中分享网络自动化巡检及修复业务的原子化技巧及可视化编排方案等，谢谢大家。