Python运维脚本案例有哪些，运维自动化脚本怎么选？
Python脚本在运维中的核心价值，不是取代Shell，而是把“看一眼、判一下、改一处”这类靠人脑判断的重复动作，变成可复用、可审计、可交接的自动化流程；巡检、告警、故障复盘这三个环节的收益最直接，也最容易在两周内看到效果。
带过几个SRE小组之后我有一个挺深的体会：运维团队缺的往往不是工具，而是把零散命令沉淀成脚本的那一步。大部分人不是不会写，是不知道从哪下手，写完了也不知道怎么挂到生产上。下面按监控告警、批量巡检、自动化变更、故障复盘四块拆，每块都给能直接落地的路径和命令。
监控告警：先压噪声，再谈智能化
告警风暴是夜班最大的敌人。一台机器宕机，Zabbix或Prometheus可能同时甩出几十条关联告警，值班的人翻半天才找到根因。这一步用Python脚本做收敛，投入产出比最高。
北京SRE团队Python告警自动化实践：一次收敛改造
某互联网公司北京机房的值班组做过一次改造，思路很朴素：在Alertmanager和通知渠道之间插一个Python小服务，做去重和计数。
- Alertmanager配置webhook，指向内部服务，路径形如
http://ops-gw.internal:8080/webhook。 - 服务用Flask接请求，把
alertname + instance拼成key写进Redis，设10分钟过期。 - 同一个key在窗口期内再次出现，只累加计数，不再重复推送。
- 窗口到期后发一条汇总消息，标题带“同类告警N次”，正文列出受影响实例。
部署路径建议固定：代码放/opt/ops/alert_gateway/app.py，用systemd托管，/etc/systemd/system/alert-gateway.service里写清Restart=always，然后执行systemctl daemon-reload && systemctl enable --now alert-gateway。别用小号crontab拉进程，崩了没人知道。
关键的一段逻辑大概是这样：
key = f"alert:{name}:{instance}"
cnt = r.incr(key)
if cnt == 1:
r.expire(key, 600)
send(title=name, body=f"{instance} 首次触发")
改造之后的效果，用值班同学的话说，“半夜被叫醒的次数明显少了，而且醒来第一眼看到的是摘要不是列表”。业内专家指出，告警收敛的收益主要来自减少无效唤醒，而不是减少告警总量，这个判断在多数团队都成立。
| 处理方式 | 首次响应 | 人力占用 | 夜班可承受度 |
|---|---|---|---|
| 人工逐条甄别 | 依赖值班人经验 | 高 | 差 |
| Zabbix自带依赖关系 | 较快 | 中 | 一般 |
| Python网关收敛+汇总 | 快 | 低 | 较好 |
Python脚本怎么实现服务器批量巡检
巡检是Python脚本最经典的落地场景，因为它天然是“多台机器、同一套命令、要汇总成表”的活儿。手工SSH一百台机器，做一次两小时，做完还没有留痕。
一个能跑起来的巡检脚本骨架
库的选择上，机器数量在几百台以内，paramiko够用；上千台建议直接用Ansible的Python API，别自己造并发轮子。下面是核心结构：
- 主机清单从CMDB接口或
hosts.txt读，一行一个IP，避免硬编码。 - 用
concurrent.futures.ThreadPoolExecutor开20到50个线程，线程数别超过SSH服务端的MaxStartups限制。 - 每个连接设
timeout=8，命令执行单独设超时，防止某台机器卡住拖垮整批。 - 采集命令固定成清单：
df -h、free -m、uptime、systemctl is-active xxx、ss -s。 - 结果统一落成CSV，字段固定，方便后续对比历史数据。
| 巡检项 | 采集命令 | 经验阈值 | 命中后动作 |
|---|---|---|---|
| 磁盘使用率 | df -h | 单分区超85% | 进异常清单，附最大目录 |
| 内存可用 | free -m | available低于总量10% | 标记待扩容 |
| 负载 | uptime | 1分钟负载超核数 | 拉top快照 |
| 关键服务 | systemctl is-active | 非active | 立即通知 |
巡检结果怎么落地才有人看
脚本跑出CSV只是第一步，没人看的巡检等于没做。比较实用的做法是二段式：脚本每天早八点由crontab拉起，先全量落盘，再只把异常行推送到企业微信或飞书的机器人。推送内容控制在十行以内，附上CSV的在线地址。全量报告留在对象存储里，按日期分目录，出问题的时候能回溯三个月前的状态。
踩过的坑：超时、编码、权限
- 连接超时和命令超时要分开设，混在一起排查很痛苦。
- 部分老系统的
LC_ALL不是UTF-8，返回中文会乱码，执行前加export LANG=en_US.UTF-8最省事。 - 需要sudo的命令，用带密码的
exec_command容易被审计卡，建议提前配好免密sudo规则，脚本里只调固定命令。
自动化变更：发布和配置这两件事最值得写脚本
生产环境Python自动化运维脚本的落地场景里，配置变更的优先级其实高于发布。发布有CI/CD平台兜着，配置改动反而常常靠人肉SSH改nginx。
Python运维脚本和Shell脚本到底哪个更好用
这个问题在团队里被问过很多次。我的答案是看层次：胶水层用Shell，逻辑层用Python。
| 维度 | Shell | Python |
|---|---|---|
| 字符串与文本处理 | 管道组合灵活 | 正则和解析更稳 |
| 异常与重试 | 靠set -e，粗糙 | try/except可控 |
| 并发 | 难写 | 线程池、协程现成 |
| 调用API | curl拼参数 | requests库清晰 |
| 交接成本 | 看人 | 中等语法门槛，好读 |
行业共识认为，两千行以上的Shell脚本基本等于技术债，改一次怕一次。一个具体例子：批量改nginx的upstream配置，用Python读jinja2模板渲染，渲染完先在本地跑nginx -t -c校验，通过再分发，分发前把原文件备份成.bak.时间戳，失败自动回滚。这套流程用Shell也能写，但错误处理和回滚逻辑会写得很痛苦。
故障复盘：把两小时的翻日志压到十分钟
复盘最耗时的环节不是开会，是出事之后翻日志拼时间线。这块完全可以用脚本半自动化。
这套东西做出来之后，复盘会的前二十分钟基本不用再“你先说下当时几点发现的”。另外脚本还能顺手把当天的变更记录拉进来做时间对齐，很多事故的根因就是某次没走流程的配置改动。
落地节奏与学习成本
运维工程师学Python要花多少钱
钱其实不是主要成本。官方文档和开源项目的源码都是免费的，市面上的付费课程集中在几百到几千元的区间，企业内部培训也常见。真正贵的是时间和练习环境——写不出能上生产的脚本，多数时候卡在没有一套可以随便折腾的测试机，而不是没看过教程。
比较务实的路径是：第一个月只练文件读写和subprocess调用，第二个月把手上最烦的一个重复操作翻译成脚本，第三个月加上日志和异常处理挂到crontab。三个脚本之后再回头看教程，吸收速度完全不一样。
Python脚本在运维中的应用常见问题
脚本写完不敢上生产，怎么办？
先做只读操作。巡检、采集、生成报告这类不改系统状态的脚本，风险接近于零，先跑两周建立信心。涉及变更的脚本，必须内置三件事：执行前备份、执行后校验、失败自动回滚。缺一个就别上。
小团队没有平台，Python脚本怎么管理？
建一个Git仓库，按功能分目录，每个脚本配一份README写清输入输出和依赖版本。定时任务统一走systemd timer或集中式调度，别散落在各台机器的crontab里。版本用requirements.txt锁死，避免半年后换台机器跑不起来。
Python脚本和Ansible、SaltStack这类工具是替代关系吗？
不是。Ansible解决的是标准化批量执行，Python脚本解决的是“这个判断逻辑我们团队特有、现成模块覆盖不到”的部分。两者组合使用的团队居多：Ansible负责下发和幂等，Python负责前后端的取数、判断和报告生成。选型时先看现成模块能不能覆盖八成需求，覆盖不了再写脚本，重复造轮子的成本往往比想象中高。
回到最初那句话：Python脚本在运维中的位置是“把判断沉淀下来”，而不是炫技。先从最烦的那件小事开始写，跑通一个，剩下的会自己长出来。