📚 课程目录第2章自动化改造总体方案设计

自动化改造总体方案设计

好，咱们进入第二章。上一章我们梳理了设备注册的现状和痛点，说白了就是「人肉操作太多，容易出错，效率还低」。那这一章，我就聊聊怎么从架构层面去解决这些问题。

我个人习惯，做任何自动化方案之前，先想清楚三件事：设计原则是什么、用什么技术、整体怎么串起来。这三件事定了，后面写代码、配流程才不会跑偏。

架构设计原则

我在项目中遇到过不少「自动化搞到一半发现跑不动」的情况。后来我总结了几条铁律，分享给你。

解耦与分层：别把注册逻辑和底层硬件驱动写死在一起。我见过一个项目，换了个交换机型号，整个注册脚本都得重写。所以，一定要把「设备发现」「信息采集」「配置下发」「状态校验」拆成独立模块。每个模块只干一件事，出了问题也好排查。
幂等性：这是自动化的命根子。什么叫幂等？就是同一个操作执行一次和一百次，结果是一样的。比如注册一台设备，如果它已经注册过了，再次执行应该直接返回「已注册」，而不是报错或者重复插入数据。我曾经因为没注意这个，导致CMDB里一台设备出现了三条记录，排查了一下午。
可观测性：自动化跑起来之后，你不能两眼一抹黑。每一步执行了什么、花了多久、成功还是失败，都得有日志和指标。我建议从一开始就把日志结构定义好，别等出问题了再补。
渐进式替换：别想着一天之内把所有设备都切到自动化。先挑一个机房、一种设备类型试点，跑顺了再推广。这个原则帮我避免了好几次「上线即回滚」的尴尬。

核心原则速览

原则	一句话解释	我的经验
解耦与分层	模块独立，各司其职	换硬件不用改主流程
幂等性	重复执行结果不变	避免CMDB数据脏乱
可观测性	每一步都有迹可循	日志结构提前定好
渐进式替换	小范围试点再推广	降低回滚风险

技术选型

技术选型这块，我踩过不少坑。选对了，事半功倍；选错了，后面全是坑。我的建议是：用成熟的、社区活跃的、团队熟悉的技术。

Ansible：配置下发与编排引擎

为什么选Ansible？说白了，它无代理，不需要在设备上装客户端，通过SSH就能干活。这对网络设备来说太重要了。你想想看，几百台交换机，每台都装agent，运维成本和安全隐患都很大。

我习惯用Ansible做两件事：

设备初始化：比如配置管理IP、开启SNMP、设置NTP。这些是注册的前置条件。
配置合规性检查：注册完成后，用Ansible的assert模块检查关键配置是否到位。

# 一个简单的设备初始化Playbook示例
- name: 设备初始化 - 设置管理IP和SNMP
  hosts: network_devices
  gather_facts: no
  tasks:
    - name: 配置管理接口IP
      ios_config:
        lines:
          - interface Vlan1
          - ip address 10.0.0.1 255.255.255.0
          - no shutdown

    - name: 启用SNMP只读社区
      ios_config:
        lines:
          - snmp-server community public RO

Python：胶水代码与复杂逻辑

Ansible擅长编排，但遇到复杂的逻辑判断、数据处理、API调用，还是得Python上场。我一般用Python写自定义模块和调度脚本。

举个例子，设备注册时可能需要从Excel导入IP列表，或者调用内部工单系统的API。这些Ansible做起来比较别扭，但Python一行requests就搞定了。

我的小技巧：把Python脚本封装成Ansible的custom module，这样既能享受Ansible的编排能力，又能用Python处理复杂逻辑。两全其美。

CMDB：配置管理数据库

CMDB是整个自动化的数据核心。所有设备注册的信息最终都要落到CMDB里。我建议选一个支持API、有资产模型、能自定义字段的CMDB。比如开源的iTop或者商业的ServiceNow。

CMDB里至少要有这些字段：

设备唯一标识：序列号或MAC地址
管理IP：用于后续运维
设备类型：交换机、路由器、防火墙
注册状态：待注册、已注册、注册失败
注册时间：方便追溯

注意：CMDB的数据质量决定了自动化的上限。如果CMDB里都是脏数据，自动化跑得再快也是白搭。我建议在注册流程中加入数据校验环节，比如IP格式检查、序列号唯一性检查。

整体流程图设计

好了，原则定了，技术选型也明确了。接下来就是怎么把它们串起来。下面这张图是我设计的整体流程，你可以参考一下。

这个流程看起来简单，但每个步骤都有讲究。我挑几个关键点说说。

设备发现：我习惯用Ansible的ping模块先扫一遍IP段，能ping通的设备才进入下一步。这样可以避免浪费时间在不可达的设备上。
信息采集：用Python通过SNMP或SSH获取设备的序列号、型号、固件版本。这里要注意，不同厂商的MIB库不一样，需要写适配器。
数据校验：校验采集到的信息是否完整、格式是否正确。比如序列号不能为空，IP不能是0.0.0.0。我曾经因为没做校验，把一堆空数据写进了CMDB，后来清理了整整两天。
写入CMDB：通过CMDB的REST API写入数据。这里要保证事务性，要么全部写入成功，要么全部回滚。我一般用Python的requests库配合重试机制。

避坑指南：我曾经在写入CMDB时没做去重，导致同一台设备被注册了两次。后来我在写入前加了一步「查询设备是否已存在」，如果存在则更新，不存在则插入。这个逻辑虽然简单，但能避免很多麻烦。

嗯，到这里，总体方案设计就聊完了。你可能会问，这些模块怎么部署？怎么保证高可用？别急，这些内容我会在后面的章节里详细展开。这一章你只要记住：原则是骨架，技术选型是肌肉，流程图是血脉。三者缺一不可。