晚上十点，通知群里弹出一条消息：核心机房的一台汇聚设备需要调整接口配置，新增三个业务VLAN的透传，同时把某个下行端口的速率从千兆改成万兆自协商。我打开终端，先翻出设备运维台账，再打开终端工具，登录设备、进配置模式、敲命令、核对回显、保存配置。一轮下来二十分钟过去了，如果还有第二台、第三台设备要做同样的操作，那就得把同样的命令再敲一遍。这种日子过了小半年，直到我开始认真用Python做网络设备自动配置，才算是把自己从重复劳动里解放出来。
这篇文章我不会讲什么高深的理论，就结合我自己实际跑过的脚本和踩过的坑，把从零开始做网络设备自动配置的完整路径梳理一遍。包括工具选型、环境准备、备份巡检、批量变更、回滚预案，以及几个真正让我头疼过的问题。不管你是刚入行的网络工程师，还是已经写了一段时间脚本但总觉得哪里不对，这篇应该都能对得上胃口。
1. 为什么说自动配置的难点从来不是"写脚本"
很多人一听到"用Python自动配置网络设备"，第一反应就是"我要学编程"。但实际上，把脚本写出来只是最表层的一步，真正难的在于想清楚你为什么要自动化、自动化的边界在哪里、出了问题怎么收场。
1.1 手工配置的三个翻车现场
先说说我经历过的手工配置翻车现场，你应该也见过类似的情况。
第一个翻车现场是命令打错。不是每个人都有完美的打字习惯，特别是在连续配置几十台设备、每台设备要敲十几条命令的情况下，很容易出现某条命令漏了个参数，或者把switchport access vlan 10打成了switchport access vlan 1。这种错误在单台设备上不显眼，但如果批量做了，后面排查起来就是一场灾难。
第二个翻车现场是配置漏项。设备配置通常不是一条命令就能搞定的，往往是"进入接口、设置模式、划分VLAN、配置描述、开启接口"这一连串动作。手工操作的时候，做到第五台设备可能就忘了给接口加描述，或者忘了保存配置。这种漏项平时看不出来，等设备重启后配置丢失，或者排障时发现接口状态不对，整个人都是崩溃的。
第三个翻车现场是变更不可控。同一批设备、同一个变更需求，不同的人去做可能给出完全不同的配置方式。有人说接口描述用中文，有人说用英文，有人说要加前缀，有人说不用。结果就是设备配置风格五花八门，后面运维排障的人根本不知道某些接口当初为什么要这么配。
1.2 自动化到底改变了什么
我说的自动化，不是让你写个脚本去模拟手工过程，而是把"人"从命令级操作中抽离出来，去定义"设备应该变成什么样"。
传统做法是：
登录设备 → 进入接口 → 敲命令 → 核对回显 → 保存配置自动化的做法是：
写一份配置模板 → 写一份设备清单 → 脚本自动登录设备 → 下发配置 → 校验结果 → 输出报告这两者最大的区别在于，传统做法是人去适配设备，每次操作都要心里默念"下一步该敲什么"；自动化把操作逻辑固化成了代码，同样的逻辑跑一百台设备和跑一台设备几乎不增加额外人力。
1.3 哪些配置环节最适合先用脚本接管
不是所有网络操作都适合立刻自动化。以我的经验，下面这几类场景是收益最大、风险也相对可控的：
- 配置备份：定期把所有设备的配置抓回来存档，即使脚本有bug，最坏的结果也就是备份失败，不会影响现网业务。
- 批量巡检：检查接口状态、CPU利用率、内存使用率、VLAN配置一致性，这些操作是只读的，安全性最高。
- 标准化变更：比如批量创建VLAN、批量配置接口归属、批量下发ACL，只要模板设计得合理，变更结果可控。
- 版本升级前的配置导出：升级前的配置文件留档，方便出问题后回退。
先把这个思路理清楚，再动手写代码，你会少走很多弯路。我见过不少同行一上来就想写一个"全自动配置平台"，结果光是处理各种厂商的命令差异就耗光了所有热情。
2. 工具链怎么选：除了Netmiko，我还用了什么
确定要搞自动化之后，第一个问题就是选工具。这个领域里Python生态已经非常成熟了，但很多人会因为选择太多而无从下手。我自己的选型经历大概是这样的：先用了最底层的Paramiko，后来换成Netmiko，再后来引入了NAPALM和Nornir，最后发现不同场景用不同工具才是正解。
2.1 为什么建议跳过纯Paramiko时代
Paramiko是一个Python实现的SSH协议库，它可以让你通过SSH连接到任意设备并执行命令。很多网工的第一版脚本都是Paramiko写的，我也一样。它的优点是灵活，缺点同样是灵活——因为太底层了，所以连"等待设备输出完"这种事情都要自己处理。
看一段Paramiko的经典代码：
import paramiko import time ssh = paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(hostname="192.0.2.10", username="admin", password="password") # 这里需要手工等待一段时间，否则命令还没执行完就开始读取了 time.sleep(1) stdin, stdout, stderr = ssh.exec_command("display current-configuration") time.sleep(3) output = stdout.read().decode() print(output) ssh.close()这段代码有两个让人头疼的问题：一个是time.sleep()的等待时间全靠猜，网络慢的时候输出没读完，网络快的时候又白等半天；另一个是设备交互式的命令（比如进入系统视图逐条配置）用exec_command很难优雅处理。
我当时用Paramiko写了个配置脚本，每次执行都要手动调整sleep时间，还经常偶发读取不完整。直到同事推荐我试试Netmiko，我才意识到原来这些坑早就有人填平了。
2.2 Netmiko是大多数场景的首选
Netmiko是基于Paramiko封装的一个高级库，它最大的贡献就是解决了"和设备交互"这件事。它会自动检测设备的命令提示符，发送命令后等到输出结束再返回，完全不需要time.sleep去猜时间。
用Netmiko连接设备并下发配置，代码大概是这样的：
from netmiko import ConnectHandler device = { "device_type": "huawei", "host": "192.0.2.10", "username": "admin", "password": "password", "port": 22, } with ConnectHandler(**device) as conn: output = conn.send_command("display interface brief") print(output)短短几行，就把设备的登录、交互、读取全部搞定了。Netmiko内置了非常多的设备类型，常见的厂商设备基本都支持。send_command用于执行只读命令，send_config_set用于下发配置。比如批量配置接口：
config_commands = [ "interface GigabitEthernet0/0/1", "port link-type access", "port default vlan 100", "description to-core-switch", ] output = conn.send_config_set(config_commands)Netmiko的另一个优势是它把一些通用行为处理得非常好，比如进入配置模式的命令、退出配置模式的命令、保存配置的命令。你只需要告诉它厂商类型，这些细节它都会自动处理。
2.3 NAPALM：当你想用统一接口操作不同厂商设备时
Netmiko解决了"怎么和设备交互"，但还没有解决"怎么屏蔽厂商差异"。不同厂商的配置命令差别非常大，展示格式也不一样，如果你要给跨厂商的网络做统一自动化，逐台写命令适配会让代码非常臃肿。
NAPALM则提供了一个统一的操作接口。它把获取接口信息、获取配置、备份配置、下发配置等能力都封装好了，你只需要指定设备的厂商驱动，就可以用同一套代码操作不同厂商的设备。
from napalm import get_network_driver driver = get_network_driver("ios") device = driver( hostname="192.0.2.10", username="admin", password="password", optional_args={"port": 22}, ) device.open() print(device.get_interfaces()) print(device.get_config(retrieve="running")) device.close()NAPALM还支持用"结构化数据"的方式来理解设备状态。比如get_interfaces()返回的不再是一堆终端文本，而是Python字典，你可以直接通过interfaces["GigabitEthernet0/0/1"]["is_up"]判断接口状态，不用去做文本解析。
我在做跨厂商的配置一致性巡检时，NAPALM帮了大忙。以前我需要为每种厂商各自写一套正则表达式来解析输出，用了NAPALM之后，解析逻辑是统一的，代码量直接降了一个量级。
2.4 Nornir与Ansible：属于"批量编排"的下一层
Netmiko和NAPALM都是"单台设备"的维度，虽然你可以写个for循环连多台设备，但并发控制、失败处理、结果汇总都需要自己实现。这时候就该批量编排工具上场了。
Ansible是业界用得最多的自动化工具，它通过playbook定义"对哪些设备做什么操作"，本身是声明式的，对不熟悉编程的人更友好。但它要求控制端有Python环境、被管设备支持SSH协议，而且它的执行模型是"推送式"的，和网络设备的交互体验比较独特。
Nornir则是一个纯Python的自动化框架，你可以直接在用Python写逻辑的同时享受批量并发、设备清单管理、结果追踪这些能力。它比Ansible更"程序员友好"，不需要学习YAML的playbook语法，所有逻辑都是Python代码。
我个人在需要写复杂处理逻辑的场景会优先选Nornir，在纯批量化下发且逻辑简单的场景用Ansible的现成模块或者直接用Netmiko循环。
2.5 我实际使用的工具组合
如果你问我个人目前的主力配置，大概是这样的：
| 场景 | 工具 |
|---|---|
| 单台设备快速操作、日常排障 | Netmiko |
| 跨厂商配置一致性巡检 | NAPALM |
| 批量配置下发、并发执行 | Nornir |
| 定时备份、定期巡检 | Cron + Netmiko 脚本 |
| 图形化展示、多人协作 | 基于Flask封装的内部小平台 |
这个组合不是一步到位的，而是踩了无数坑之后沉淀下来的。我的建议是：你不需要一步到位把所有工具都学会，先从Netmiko入手跑通一个备份脚本，再逐步引入NAPALM做结构化采集，最后再考虑批量编排。
3. 拿到设备运维权限后，先从备份和只读巡检做起
工具选好了，接下来要解决的是"拿什么练手"的问题。我的建议非常明确：不要一上来就写批量配置下发脚本，先从备份和只读巡检开始。原因很简单，只读操作即使写错了也不会影响现网，你可以在安全的前提下熟悉整个工具链。
3.1 环境准备：Python虚拟环境与依赖安装
先创建独立的Python虚拟环境，避免把系统Python环境搞乱：
mkdir network_automation cd network_automation python3 -m venv venv source venv/bin/activate然后安装核心依赖：
pip install netmiko napalm nornir这里多说一句，强烈建议用虚拟环境。我早期踩过一个坑，直接在系统Python环境里装了一堆库，后来某个库版本升级把另一个库的依赖搞坏了，导致好多脚本跑不起来。虚拟环境相当于给每个项目一个独立的"箱子"，互不干扰。
3.2 设备侧需要准备什么
脚本要能连上设备，设备侧得满足几个基本条件：
- 开启SSH服务：现在基本没有设备不支持SSH了，但默认端口和认证方式可能不同，最好统一规划。
- 准备专用账号：给自动化脚本单独建一个账号，权限按需分配。不要用最高权限账号跑巡检，万一脚本有bug，影响面会小很多。
- 确认命令回显格式：不同厂商的
display或show命令输出格式不同，要先手工跑一遍，心里有数。
另外，我建议把设备密码放到独立配置文件中，不要硬编码在脚本里。最简单的做法是放到环境变量或者一个本地配置文件中，然后给文件设置严格权限。
3.3 一个能反复执行的备份脚本
这是我最推荐的第一个自动化脚本：全设备配置备份。逻辑非常简单，遍历设备清单，逐台连接并抓取配置，按日期保存到本地目录。
from netmiko import ConnectHandler from datetime import datetime import os DEVICES = [ { "device_type": "huawei", "host": "192.0.2.10", "username": "admin", "password": "password", "name": "core-sw-01", }, { "device_type": "huawei", "host": "192.0.2.11", "username": "admin", "password": "password", "name": "core-sw-02", }, ] save_dir = f"backup/{datetime.now().strftime('%Y%m%d')}" os.makedirs(save_dir, exist_ok=True) for device in DEVICES: try: with ConnectHandler(**device) as conn: config = conn.send_command("display current-configuration") file_path = os.path.join(save_dir, f"{device['name']}.cfg") with open(file_path, "w", encoding="utf-8") as f: f.write(config) print(f"{device['name']} 备份成功") except Exception as e: print(f"{device['name']} 备份失败: {e}")这个脚本很简单，但已经涵盖了自动化的核心要素：设备清单管理、连接处理、命令执行、结果保存、异常捕获。你可以在此基础上加日志、加邮件告警、加失败重试。
3.4 只读巡检：从文本输出到结构化状态
备份配置只是第一步，更实用的巡检脚本是去检查设备状态。比如我想检查所有设备的接口是否有哪些处于Down状态、CPU是否过高。
Netmiko执行命令后返回的是文本，要从中提取关键信息，最常用的方式是textfsm模板解析，或者直接用正则表达式。以接口状态为例：
from netmiko import ConnectHandler import re device = { "device_type": "huawei", "host": "192.0.2.10", "username": "admin", "password": "password", } with ConnectHandler(**device) as conn: output = conn.send_command("display interface brief") # 逐行匹配接口状态 down_interfaces = [] for line in output.splitlines(): match = re.search(r"(GigabitEthernet\S+)\s+(\S+)\s+(\S+)", line) if match: interface, status, protocol = match.group(1), match.group(2), match.group(3) if status == "down" or protocol == "down": down_interfaces.append(interface) if down_interfaces: print(f"发现Down接口: {down_interfaces}") else: print("所有接口状态正常")实际生产中建议配合SNMP或者其他监控平台做趋势分析，但小型网络里这种命令行巡检已经足够好用。
4. 批量改配置的完整流程：从设备清单到回滚预案
备份和巡检跑通之后，你才有资格去碰"改配置"这件事。批量变更的流程设计和单台操作完全不一样，因为一旦下发错误，可能就是几十台设备同时出问题。这一节直接把我实际执行批量配置时的完整流程拆给你看。
4.1 第一步：先定义"设备清单"，而不是先写命令
我的习惯是先把所有设备信息集中管理起来，用一个单独的Python模块或者YAML文件维护设备清单。YAML格式对非程序员更友好，我用得比较多。
devices: - name: core-sw-01 host: 192.0.2.10 device_type: huawei role: core - name: access-sw-01 host: 192.0.2.20 device_type: huawei role: access然后用一段通用代码加载：
import yaml with open("devices.yaml", "r", encoding="utf-8") as f: config = yaml.safe_load(f) devices = config["devices"]设备清单独立维护的好处是，脚本逻辑和设备信息解耦。新增加设备不需要改代码，改设备密码也不需要碰逻辑。
4.2 第二步：用"配置模板"管理变更内容，而不是在代码里写死命令
批量变更最怕两件事，一是命令写错，二是不同设备的差异参数搞混。我的做法是把变更内容抽象成模板，用Python的字符串格式化或Jinja2模板引擎去渲染。
举例，我要给一批接入交换机创建VLAN 100，并把这个VLAN加到所有上行口。设备之间的差异可能只是交换机编号或接口名，我把这些参数留成变量：
vlan {{ vlan_id }} name VLAN_{{ vlan_id }} {% for port in uplink_ports %} interface {{ port }} port link-type trunk port trunk allow-pass vlan {{ vlan_id }} {% endfor %}在Python里渲染这个模板：
from jinja2 import Template template_str = open("vlan_template.j2", encoding="utf-8").read() template = Template(template_str) rendered_config = template.render( vlan_id=100, uplink_ports=["GigabitEthernet0/0/1", "GigabitEthernet0/0/24"], ) print(rendered_config)模板化之后的变更内容，在正式下发前你还可以人工review，看渲染出来的完整命令集是否正确。这比直接在脚本里写一大堆send_config_set(["vlan 100", ...])要安全得多。
4.3 第三步：先单台试点，再分批灰度
我的强制原则是：任何批量变更，先在一台设备上试点，确认无误后，再扩展到一小批设备，最后才全部执行。这个流程看起来慢，实际上是最快的——因为一旦配置命令写错，你只需要修复一台设备。
试点脚本和批量脚本可以复用同一套函数：
from netmiko import ConnectHandler def apply_config(device, config_lines): with ConnectHandler(**device) as conn: output = conn.send_config_set(config_lines) conn.save_config() return output # 先对试点设备执行 pilot_device = { "device_type": "huawei", "host": "192.0.2.20", "username": "admin", "password": "password", } apply_config(pilot_device, rendered_config.splitlines())试点通过后，再对剩下的设备循环执行，同时把每台设备的结果记录下来。
4.4 第四步：变更后立即校验，而不是下完就走
配置下发完成不等于变更成功，还要做校验。我的校验动作一般包括三件事：
- 重新拉取配置，确认配置确实在设备上生效了。
- 检查关键接口状态，确认没有因为配置导致接口Down或协议震荡。
- 检查设备日志，确认没有异常告警。
最直接的方式是下发完再连一次设备，执行几条只读命令：
with ConnectHandler(**device) as conn: result = conn.send_command("display vlan") if "100" in result: print("VLAN 100 已生效") else: print("VLAN 100 未生效，需要回滚")4.5 第五步：回滚预案一定要先写进脚本
网络变更最忌讳的是"变完了再想要怎么回滚"。我的做法是，任何变更脚本执行前，先把目标设备当前的配置文件抓取回来，保存为回滚文件。如果变更后校验失败，直接重新下发回滚文件里的原始配置。
简化版的回滚逻辑：
def rollback(device, backup_config_file): with open(backup_config_file, "r", encoding="utf-8") as f: original_config = f.read() with ConnectHandler(**device) as conn: # 进入配置模式并逐条下发原配置 conn.send_config_set(original_config.splitlines()) conn.save_config()当然，回滚也有风险，比如设备上新增的动态状态可能不在备份配置里。所以更稳妥的做法是：在变更窗口内保留足够的观察时间，发现问题立即回滚，而不是等第二天再处理。
5. 网络自动化的几个"你以为没问题"的坑
工具选好了、脚本也能跑了，但真正让网络自动化落地困难的往往是那些"你以为没问题"的小细节。我在这个过程中踩过的坑，挑几个典型的说一下。
5.1 SSHSession超时：设备多的时候并发不能拍脑袋
最早我用Netmiko写批量巡检脚本，设备数量到了几十台的时候，脚本越跑越慢，有些设备直接连接超时。我以为是网络问题，后来排查发现是并发模型不对——我用的是单线程循环逐台连接，一台设备卡住，后面全部排队。
后来我引入Nornir，它默认就是并发执行，我用下面的配置把并发数调大：
runner: plugin: threaded options: num_workers: 20再跑批量巡检，速度有了明显提升。不过这里有个新问题：并发数不是越大越好。网络设备的管理CPU普遍不强，如果你同时开几十个SSH会话去抓配置，设备CPU会飙升，甚至影响正常转发。稳妥的做法是num_workers设置从10开始试，观察设备CPU占用，再逐步调大。
5.2 命令回显和分页：一页显示不全怎么办
网络设备的命令回显一般都有分页机制，比如一次性显示几十行后会停下来等你按空格或回车。Netmiko对此是有处理的，它会自动检测分页提示符并发空格键翻页，大多数情况下没问题。
但某些老设备或不常见厂商的设备，分页提示符格式特殊，Netmiko可能识别不了，导致命令卡在中间。解决办法是在连接设备时禁用分页。不同的设备有不同的命令，以常见厂商为例，一般是执行screen-length 0 temporary或terminal length 0。
在Netmiko里可以这样处理：
device = { "device_type": "huawei", "host": "192.0.2.10", "username": "admin", "password": "password", "global_delay_factor": 2, } with ConnectHandler(**device) as conn: conn.send_command("screen-length 0 temporary") output = conn.send_command("display current-configuration")global_delay_factor也是一个隐藏但重要的参数，设备响应慢的场合把它调大，能减少因超时导致命令读取不完整的问题。
5.3 厂商命令差异：同一件事不同说法
这是跨厂商自动化最大的拦路虎。同样是配置接口IP地址，不同厂商的命令风格差异很大。解决思路有两个：
一是用NAPALM这类提供统一抽象层的库，把差异封装在驱动里。缺点是NAPALM支持的厂商和功能有限，不是所有命令都覆盖。
二是自己维护一份"命令映射表"，把同一操作在不同厂商下的命令写清楚。我在做多厂商支持的时候就是这么干的：
COMMAND_MAP = { "huawei": { "set_hostname": "sysname {name}", "create_vlan": "vlan {vlan_id}", "show_interface": "display interface brief", }, "ios": { "set_hostname": "hostname {name}", "create_vlan": "vlan {vlan_id}", "show_interface": "show ip interface brief", }, }然后用设备类型动态取命令模板，脚本逻辑保持统一。
5.4 密码和密钥管理：别把密码硬编码在脚本里
很多初学者的脚本长这样：
password = "123456"这在小规模实验环境里无所谓，但一旦脚本要上生产、要共享给同事，密码就会随着代码库到处流传，迟早出问题。我现在统一用环境变量或者独立的配置密钥文件：
export NET_DEVICE_PASSWORD="xxx"脚本里读取环境变量：
import os password = os.environ.get("NET_DEVICE_PASSWORD")更进一步，可以引入密钥管理服务，但网络自动化早期用环境变量加严格权限控制已经够用了。
5.5 日志和审计：自动化的锅谁来背
自动化执行的速度快，影响范围大，所以日志和审计比手工操作更重要。我现在跑任何批量脚本，都强制要求输出一份操作日志，内容包括：操作时间、操作人、操作对象、执行的命令、回显的关键信息、执行结果。
import logging logging.basicConfig( filename="change_audit.log", level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s", ) logging.info("开始对设备 core-sw-01 执行 VLAN 100 创建") logging.info("下发配置: %s", rendered_config) logging.info("校验结果: VLAN 100 已生效")这套日志在你需要复盘变更、定位问题的时候，价值会体现得非常明显。我经历过一次批量变更后网络出现间歇性丢包，就是靠审计日志逐个回放当时下发的命令，才找到是哪台设备的哪条命令引起的问题。
6. 让脚本落地成每天在跑的东西：我的几点体会
到这一步，你可能已经能写出不错的自动化脚本了，但离"真正落地到日常运维"还差一步。这一节分享几个让我从"写脚本"走向"跑服务"的体会。
6.1 给脚本加上"可重复执行"的属性
运维脚本最大的特点是：它不止跑一次，而是要反复跑。所以脚本必须具备幂等性——也就是说，跑第一次和跑第十次的结果是一样的。
比如创建VLAN的脚本，如果设备上已经有VLAN 100了，第二次执行就不应该报错，也不应该重复创建。做法是在下发前先查询一遍设备现状：
with ConnectHandler(**device) as conn: output = conn.send_command("display vlan") if "100" not in output: conn.send_config_set(["vlan 100", "name VLAN_100"]) else: print("VLAN 100 已存在，跳过创建")这种"先检查、再变更"的写法，能极大降低重复执行的风险。
6.2 用定时任务把备份和巡检做成"无人值守"
我最开始是手动跑备份脚本，跑了几天就发现经常忘。后来把它挂到定时任务里，每天早上自动执行一次配置备份，有失败就发邮件告警。
Crontab配置大概是这样的：
0 2 * * * cd /opt/network_automation && /opt/network_automation/venv/bin/python backup_configs.py >> logs/backup.log 2>&1选凌晨两点的原因是这个时间段网络流量相对小，设备管理面的CPU也空闲，执行时间较短不容易影响业务。
定时任务跑起来之后，你才真正体会到自动化的价值——不用每天惦记着"今天备份了没"，而是每天早晨看一眼昨天的备份报告就够了。
6.3 从"一堆脚本"到"一个项目"
脚本数量多了之后，我强烈建议把零散的单文件脚本重组成一个结构清晰的Python项目。我自己的目录结构大致如下：
network_automation/ ├── devices.yaml ├── templates/ │ ├── vlan_template.j2 │ └── interface_template.j2 ├── scripts/ │ ├── backup_configs.py │ ├── daily_inspection.py │ ├── apply_vlan.py │ └── rollback.py ├── logs/ └── backup/在这个过程中，把公共的连接逻辑、设备加载逻辑、日志逻辑抽成公共函数，避免每个脚本都重复写一遍ConnectHandler。代码质量和可维护性一下子就上去了。
6.4 最后再分享一个小技巧：先记录"操作前状态"
无论是备份、巡检还是变更，我都有一个习惯：操作前先把设备的当前状态记录一份。比如变更前记录一下接口状态、VLAN列表、路由表摘要。操作之后再记录一份，两个文件做对比，能非常直观地看到"这次变更到底改变了什么"。
对比用Linux自带的命令就能完成：
diff before_status.txt after_status.txt甚至可以用Python做个简单的差异输出：
import difflib before = open("before_status.txt").readlines() after = open("after_status.txt").readlines() diff = difflib.unified_diff(before, after, lineterm="") print("\n".join(diff))这个习惯让我避免了好几次"明明改了配置但没达到预期效果"的尴尬。你先记录、后对比，设备配置的真实变化就藏不住。
网络设备自动配置这条路，我走下来最大的感受是：脚本能力只是入场券，真正让自动化发挥价值的是"流程设计"和"风险控制"。你把备份、巡检、变更、回滚这一套闭环都跑顺了之后，Python对你来说就不再是写几行代码的问题，而是重新定义自己和网络设备协作方式的问题。如果你正准备上手，不妨从今晚的第一个备份脚本开始。
