小区新装了12台AP，物业让老张三天内搞定全楼WiFi覆盖。他手动一台台连后台、改SSID、调功率、设信道……到第三天凌晨两点，还卡在6楼弱电井的固件升级失败上。隔壁IT公司小李听说后笑了：‘我们用Ansible脚本，23台AP，17分钟全配完，连密码都按楼层自动生成。’
自动化到底干了些啥
说白了，就是把人手一遍遍敲命令、点网页、填表单的动作，写成脚本或配置模板，让机器自己跑。比如批量下发统一的SSID和密码策略，自动识别干扰源并切换最优信道，AP上线后自动加入指定VLAN，甚至根据楼层平面图，给每台设备分配专属发射功率。
真香的几处地方
人手配5台AP，可能不出错；配50台？漏改一个DHCP网关，整层断网两小时。自动化不会手抖——配置文件写对一次，复制50次结果都一样。某连锁奶茶店新开17家门店，运维用Python+REST API脚本，一键拉起整套WiFi策略：访客网络限速、员工终端白名单、微信认证对接，连广告页面都按城市自动替换。
还有那种半夜要改配置的场景。写字楼晚上10点后AP负载骤降，系统自动把2.4G频段功率下调3dB，减少对隔壁公司的干扰；早8点前又悄悄调回来。人可没法天天守着时钟等那一刻。
翻车现场也不少
最怕“一锅端”。某学校用自动化工具统一推送新固件，结果忘了老款AP不兼容，37台设备集体变砖，IT老师扛着笔记本挨个进弱电箱刷机刷到天亮。
再比如模板里写了‘关闭WPS’，但某型号AP的API关闭WPS实际会连带禁用整个无线接口——这种坑，不实测根本发现不了。还有人把测试环境的IP段直接套进生产脚本，一执行，所有AP路由表被清空，全校WiFi掉线47分钟。
怎么用才不踩坑
先小范围试：挑3台同型号AP，手工跑通全流程，再录成脚本。加个‘预检模式’——脚本运行前先扫描设备型号、当前固件版本、是否在线，不满足条件直接退出，不硬来。
别追求全自动：关键步骤留个确认钩子。比如‘即将重启全部AP，确认？[y/N]’，回车前还能 Ctrl+C 拦住。配置文件和脚本本身，存Git里，每次改完写清楚‘为什么改’，半年后查问题不用抓瞎。
# 示例：Ansible中安全重启AP的片段（仅影响标记为test_group的设备）
- name: Check AP model before reboot
uri:
url: "https://{{ inventory_hostname }}/api/v1/device"
return_content: yes
register: ap_info
when: "'AP-220' in ap_info.json.model"
- name: Reboot only if pre-check passed
uri:
url: "https://{{ inventory_hostname }}/api/v1/reboot"
method: POST
when: ap_info.json.model == 'AP-220'最后提醒一句：自动化不是替代人，是让人从重复劳动里腾出手，去盯真正该盯的事——比如6楼那个总掉线的角落，是不是得换台高增益AP，而不是又去改第8遍信道。