标签：#07-第七篇章-自动化运维与编程
第330篇：AI Ops：智能网络运维的演进之路
网络运维经历了从"人工运维"到"自动化运维"的演进，如今正迈入"智能化运维"（AIOps, Artificial Intelligence for IT Operations）的新阶段。回顾整个第七篇章"自动化运维与编程"的发展脉络：
阅读全文 →
第329篇：网络知识图谱构建与应用
网络运维中涉及的数据极其分散：设备台账在 CMDB 系统、拓扑关系在网管平台、故障案例在工单系统、配置信息在 Git 仓库、告警数据在告警平台。这些异构数据之间的关联关系隐藏在人工经验中，无法被系统自动利用。
阅读全文 →
第328篇：大模型辅助网络故障诊断实践
大语言模型（Large Language Model, LLM）的出现为网络故障诊断带来了革命性的变化。传统故障排查高度依赖工程师个人经验，排障过程往往是"看告警 → 猜原因 → 试操作 → 验证"的循环。LLM 凭借其强大的自然语言...
阅读全文 →
第327篇：ChatOps：用飞书/钉钉机器人操作网络
ChatOps 的核心思想是：将运维操作从"登录服务器执行命令"转变为"在聊天工具中通过对话完成"。运维人员在飞书或钉钉群聊中发送一条消息，机器人自动执行对应的运维任务并返回结果。这种方式降低了运维操作的门槛，提高了操作的可追溯性和协...
阅读全文 →
第326篇：自动化测试：用 pytest 验证网络状态
在传统运维模式中，配置变更后是否"正确生效"，往往依赖工程师手工登录设备执行 `display` 命令逐一核对。这种方式不仅效率低下，而且容易因疲劳或疏忽遗漏检查项。
阅读全文 →
第325篇：配置变更审批与回滚流程自动化
网络变更是运维工作中风险最高的操作之一。据统计，超过 70% 的网络故障由配置变更引起。传统的变更审批流程依赖邮件或工单系统，审批周期长、信息传递不完整、回滚依赖手工执行。
阅读全文 →
第324篇：Git 版本控制管理网络配置
Git 是软件工程中最重要的工具之一，它解决了代码的版本管理、团队协作和变更追溯问题。当网络配置被纳入代码化管理（NaC，见第323篇）后，Git 自然成为网络配置版本控制的首选工具。
阅读全文 →
第323篇：网络即代码（Network as Code）理念
"基础设施即代码"（Infrastructure as Code, IaC）已被云计算领域广泛接受。从网络工程师的视角，Network as Code（NaC）将同样的理念应用到网络设备上：网络配置不再是通过 CLI 逐条输入的手工作...
阅读全文 →
第322篇：CI/CD 在网络变更中的应用
传统网络变更流程存在明显痛点：变更窗口集中在深夜、回滚困难、缺乏自动化验证、人工操作易出错。这些问题的根源在于网络变更长期被视为"手工操作"，而非"可验证的软件交付"。
阅读全文 →
第321篇：全网拓扑自动发现与绘图
在网络规模从几十台设备膨胀到上千台后，手工绘制拓扑图不仅效率极低，而且极难保持准确性。第320篇我们介绍了 IPAM 自动化的核心思路：将 IP 地址资源纳入程序化管控。而拓扑自动发现正是 IPAM 的自然延伸——当你知道哪些 IP ...
阅读全文 →
第320篇：IP 地址管理（IPAM）自动化
第319篇介绍了配置备份与合规检查。在网络运维中，IP 地址管理（IP Address Management, IPAM）是又一个高频且易出错的操作：随着网络规模扩大，手工维护的 Excel 表格不仅效率低下，而且极易出现地址冲突、记...
阅读全文 →
第319篇：配置备份与合规检查自动化工具
第318篇介绍了如何用 Python 自动化巡检设备运行状态。设备配置是网络运维的另一个核心资产——配置丢失可能导致网络中断，未授权变更可能引入安全隐患。因此，配置备份和合规检查是自动化运维的两大基石。
阅读全文 →
第318篇：用 Python 开发自动化巡检脚本
第317篇介绍了华为 MDA 框架的设备管理方式。在实际运维中，每日/每周对网络设备进行巡检是必不可少的工作：检查设备 CPU/内存利用率、接口错误计数、路由数量、协议状态、温度等指标，及时发现潜在故障。
阅读全文 →
第317篇：模型驱动编程（MDA）在华为设备上的实现
第315-316篇分别介绍了 gNMI/gNOI 协议和 Telemetry 流式数据推送。这些协议是模型驱动网络管理的传输层，但实际开发中，直接操作 gRPC 底层 API 过于繁琐。厂商通常会提供更高级的 SDK（软件开发工具包）...
阅读全文 →
第316篇：Telemetry 订阅与流式数据推送
第315篇介绍了 gNMI 协议的双向流式能力。在网络运维中，最核心的需求之一是实时采集设备指标——接口流量、CPU 利用率、内存使用、温度、光功率等。传统的 SNMP 轮询（Polling）方式存在固有缺陷：固定的轮询间隔导致要么数...
阅读全文 →
第315篇：gNMI/gNOI：谷歌开源的网络管理协议
第314篇介绍了 OpenConfig 和 IETF 标准模型。谷歌在大规模网络运营中发现，传统的 NETCONF（XML over SSH）和 RESTCONF（JSON over HTTP）在性能上无法满足超大规模数据中心的需求：...
阅读全文 →
第314篇：OpenConfig 与 IETF 标准模型
前几篇介绍了 NETCONF 和 RESTCONF 这两种协议如何将 YANG 模型作为操作蓝本。然而，YANG 模型本身需要有人来编写——谁来定义这些模型？不同厂商对同一个网络功能（如接口、路由、VLAN）的模型定义是否一致？
阅读全文 →
第313篇：用 RESTCONF 修改接口配置
第311篇介绍了 RESTCONF 作为基于 HTTP 的 YANG 数据操作协议，第312篇演示了 NETCONF 的配置采集。本篇聚焦 RESTCONF 最实用的场景——修改接口配置。
阅读全文 →
第312篇：用 NETCONF 采集设备配置
第311篇介绍了 NETCONF 协议的架构和操作模型。在实际运维中，NETCONF 最常见的应用场景之一就是采集设备配置——从网络设备的 running/candidate 数据区中读取结构化配置数据，用于备份、审计、对比分析等目的。
阅读全文 →
第311篇：NETCONF 与 RESTCONF 协议
第310篇介绍了 YANG 数据模型如何为网络配置提供结构化描述。然而，仅有数据模型还不够——我们需要一种协议来传输这些结构化数据、执行读写操作、并保证操作的原子性与一致性。这就是 NETCONF 和 RESTCONF 的使命。
阅读全文 →
第310篇：YANG 数据模型基础
在前几篇中，我们通过CLI命令、SSH连接和文本模板管理网络设备。CLI的本质是"自由文本协议"——不同厂商使用不同的命令语法、不同的输出格式。即便Netmiko和NAPALM做了大量适配工作，底层仍然依赖正则表达式解析文本。
阅读全文 →
第309篇：Ansible Tower/AWX——自动化调度
Ansible Playbook在命令行下运行十分高效，但当自动化规模扩大后，多个运维团队共享同一套Playbook时，纯命令行方式暴露出明显短板：无权限管控、无执行审计、无可视化调度、无集中式日志。
阅读全文 →
第308篇：Ansible 网络模块——Playbook 管理设备
在前几篇中，我们逐步积累了Python编程、SSH连接、多厂商抽象、模板引擎和结构化数据格式的能力。但这些能力分散在不同工具中，需要一个统一的框架来串联。
阅读全文 →
第307篇：YAML 与 JSON——结构化数据格式
网络自动化的数据流可以概括为：**读取数据 → 处理数据 → 输出配置 → 下发设备**。其中"数据"需要一个标准化的载体格式，既要方便人类编写和阅读，又要被程序高效解析。
阅读全文 →
第306篇：Jinja2 模板引擎——配置模板化
在前几篇中，我们掌握了连接设备、批量执行命令的方法。但当配置内容变得复杂——比如为50台交换机分别生成包含VLAN、接口、BGP、OSPF等数十行配置的完整配置时，逐条拼接字符串的方式既难以维护又容易出错。
阅读全文 →
第305篇：NAPALM——统一网络设备管理接口
Netmiko解决了"连接设备"的问题，但它仍然要求工程师针对不同厂商编写差异化的命令。如果需要采集路由表、接口统计信息、ARP表等结构化数据，工程师仍需自行解析不同厂商的CLI输出格式。
阅读全文 →
第304篇：Netmiko 批量执行配置命令
第303篇中，我们使用Paramiko直接管理SSH连接和Shell交互。然而，当需要对接华为、思科、Juniper等多品牌设备时，每个厂商的CLI提示符、配置模式、命令语法各不相同，手工编写适配代码的工作量巨大。
阅读全文 →
第303篇：Paramiko 库——SSH 连接网络设备
在网络自动化的工具链中，SSH协议是最基础、最通用的通信通道。无论设备品牌是华为、思科、Juniper还是Nokia，只要开启SSH服务，Python就能通过Paramiko库建立加密通道，远程执行命令或下发配置。
阅读全文 →
第302篇：Python 基础——网络工程师的第一行代码
如果说网络自动化是一座大厦，Python就是它的钢筋混凝土。在全部网络自动化工具中——无论是Paramiko、Netmiko、NAPALM还是Scapy——Python都是最底层、最通用的语言基座。
阅读全文 →
第301篇：网络运维自动化的 Why 与 How
承接第300篇对AI时代数据中心趋势的探讨，我们看到了数据中心正从传统"烟囱式"架构向云原生、智能化方向演进。然而，再先进的硬件与算法，若缺乏高效的运维体系支撑，也无法释放其真正的价值。当网络设备规模从几十台膨胀到数千台、配置项从数百...
阅读全文 →