📚 课程目录第1章课程导入与自动化运维全景

1. 课程导入与自动化运维全景

企业网络运维正在经历从“人工登录设备逐台敲命令”向“代码驱动、平台编排、数据闭环”的转变。以一所拥有三个校区、约120台Cisco Catalyst交换机和40台路由器的中型企业为例：传统方式下，一次全网VLAN调整需要工程师逐台SSH登录、核对当前配置、修改并保存，平均耗时6～8小时，且极易因漏改某台接入交换机导致终端无法获取地址。当网络规模扩大到数百台设备、每天产生数十次变更请求时，人工模式在效率、一致性和可审计性上都会迅速失效。

本课程的目标不是把网络工程师变成软件开发工程师，而是让具备CCNA/CCNP级别网络基础的人员，能够用Python、Ansible、NETCONF/RESTCONF、YANG模型与Cisco DNA Center等工具，把日常重复性运维任务转化为可复用、可验证、可回滚的自动化流程。学完本课程后，你应当能够独立完成：批量设备信息采集与合规检查、基于模板的配置下发、变更前后差异比对、故障自动定位与告警联动，以及将上述能力封装为可持续运行的自动化任务。

企业网络运维的核心挑战

自动化不是目的，解决运维痛点是目的。企业网络运维的挑战可以归纳为四类，它们彼此关联，共同构成自动化的需求来源。

规模与重复性：接入层交换机配置高度相似，但数量庞大。手工逐台操作的时间成本随设备数线性增长，而自动化脚本的边际成本接近于零。
一致性与漂移：设备运行一段时间后，常因临时排障、紧急变更产生配置漂移。没有基线比对机制，漂移会累积成难以排查的隐性故障。
变更风险与可追溯：一次错误的路由策略或ACL变更可能影响整栋楼宇。人工变更缺乏统一的预检查、审批、回滚与审计记录。
多工具割裂：监控、配置、工单、IPAM各自为政，数据不互通，导致“告警了不知道谁改的、改了什么、怎么回退”。

这四类挑战对应四种自动化能力：批量执行、基线合规、安全变更、数据集成。本课程的章节结构正是围绕这四种能力逐步展开。

Catalyst自动化运维的目标与能力分层

Cisco Catalyst系列设备提供了从CLI到模型驱动接口的多种可编程入口。理解这些入口的层次关系，是选择合适自动化手段的前提。最底层是传统CLI，通过SSH执行命令，兼容性最好但输出为非结构化文本；往上是SNMP，适合只读监控但写操作能力弱；再往上是NETCONF/RESTCONF，基于YANG模型，返回结构化数据，支持事务与候选配置；最上层是Cisco DNA Center及其Intent API，提供网络级抽象，如站点、设备、模板、策略，适合跨设备编排。

自动化运维的目标可以概括为：把“人找设备”变成“策略找设备”。工程师描述期望状态（例如“所有接入端口启用PortFast和BPDU Guard”），由自动化系统负责计算差异、下发配置并验证结果。这一目标要求工具链同时具备设备连接、数据解析、模板渲染、差异计算、结果校验和日志记录能力。

课程结构与学习路径

本课程共30章，按“基础准备—数据采集—配置自动化—验证与排障—平台集成”五个阶段推进。第1～4章建立环境与工具链，包括Python基础、SSH连接、实验拓扑搭建；第5～10章聚焦数据采集与解析，覆盖Netmiko、TextFSM、Genie、SNMP与RESTCONF；第11～18章进入配置自动化，讲解Jinja2模板、Ansible Playbook、NETCONF/YANG配置下发与差异比对；第19～24章处理验证与排障，包括合规检查、配置漂移检测、日志分析与告警联动；第25～30章面向平台集成，涉及DNA Center Intent API、Git版本管理、CI/CD流水线与自动化运维体系设计。

每章都围绕一个可执行任务展开，而不是单纯介绍工具语法。例如学习Ansible时，你会实际编写一个Playbook，向三台Catalyst交换机下发统一的NTP和Syslog配置，并用show命令验证结果。学习NETCONF时，你会用ncclient获取接口配置的YANG模型数据，修改后提交候选配置，再对比变更前后的差异。

实验环境与工具链准备

为了让所有实验可复现，建议统一使用以下环境。操作系统为Ubuntu 22.04 LTS或Windows 11 + WSL2；Python版本3.10以上；实验拓扑使用Cisco Modeling Labs（CML）或EVE-NG，运行IOS-XE 17.x镜像的Catalyst 8000V或CSR1000V。若没有模拟器，也可使用Cisco DevNet沙箱中的Always-On实验室，通过VPN接入真实设备。

工具链安装命令如下，建议在Python虚拟环境中执行：

python3 -m venv netauto
source netauto/bin/activate
pip install netmiko napalm ncclient ansible jinja2 requests textfsm
ansible-galaxy collection install cisco.ios

实验拓扑建议包含三台设备：一台核心交换机（Catalyst 8000V）、两台接入交换机（Catalyst 8000V），核心与接入之间运行OSPF，接入交换机下挂一台Linux主机模拟终端。管理网络使用192.168.100.0/24网段，设备管理地址分别为192.168.100.11、192.168.100.12、192.168.100.13。所有设备启用SSH、NETCONF和RESTCONF，用户名netadmin，密码使用实验专用密码。

建议在实验前用Git初始化一个仓库，将每章的脚本、Playbook和配置模板纳入版本管理。这样每次变更都有记录，也便于对比不同章节的代码演进。

验证环境是否就绪，可以执行以下Python片段。它使用Netmiko连接第一台设备并执行show version，若返回包含“Cisco IOS XE”的输出，说明SSH连接与凭据配置正确。

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "192.168.100.11",
    "username": "netadmin",
    "password": "实验密码",
    "secret": "enable密码",
}

with ConnectHandler(**device) as conn:
    conn.enable()
    output = conn.send_command("show version")
    print(output[:200])

如果连接失败，按以下顺序排查：先用ping确认管理地址可达；再用ssh netadmin@192.168.100.11手动登录，确认SSH服务已启用且ACL未阻断；检查设备是否配置了transport input ssh；最后确认Python环境中netmiko版本与设备IOS-XE版本兼容。常见错误“Authentication failed”通常来自密码错误或AAA配置问题，“Timeout”则多为网络不可达或SSH端口被过滤。

实验环境中不要使用生产网络的真实密码，也不要在脚本中硬编码密码。后续章节会介绍使用环境变量、Ansible Vault或DNA Center凭据存储来管理敏感信息。

完成环境准备后，你已经具备后续所有章节的实验条件。接下来将从Python与网络设备交互的基础开始，逐步构建完整的Catalyst自动化运维能力。