Python是运维提效利器，用subprocess/paramiko批量远程操作、psutil统一采集指标、jinja2+yaml管理配置、logging+cron实现巡检闭环，关键在流程设计与避坑。
Python 是系统管理员提升运维效率的利器，尤其在批量管理、状态监控、配置同步等场景中，比 Shell 脚本更易维护、扩展性更强。关键不在于写多复杂的代码，而在于用对工具、理清流程、避开常见坑。
用 subprocess 和 paramiko 批量执行远程命令
日常要查 50 台服务器的磁盘使用率、重启某个服务，手动 SSH 太低效。subprocess 适合本地命令编排，paramiko 则负责安全连接远程主机。
- 避免硬编码密码：用密钥认证 + ssh-agent 或通过环境变量传密钥路径
- 连接失败要捕获异常（如 AuthenticationException、SSHException），别让一个节点卡住整个任务
- 命令输出建议统一用 UTF-8 解码，防止中文乱码；超时设置 timeout=10 防止挂起
- 示例：用 paramiko 并发检查 df -h 输出，只打印使用率 >90% 的行
用 psutil 统一采集本机系统指标
不用再拼接 free、top、df 命令，psutil 提供跨平台接口，一次调用就能拿到内存、CPU、磁盘、网络、进程等核心数据。
- cpu_percent(interval=1) 要调两次才有意义——第一次是初始化，第二次才返回真实值
- disk_usage('/') 返回字节单位，记得除以 1024**3 转 GB，并保留一位小数提升可读性
- 获取进程列表时加条件过滤（如 p.info['name'] == 'nginx'），避免遍历全部进程拖慢脚本
- 适合封装成 get_system_health() 函数，返回 dict，方便后续写入日志或上报 Prometheus
用 jinja2 + yaml 管理配置文件生成
当 Nginx、Supervisor、Ansible Playbook 等配置需按环境（dev/staging/prod）差异化生成时，硬写多个模板文件难维护。jinja2 模板 + YAML 数据分离是轻量级但高效的解法。
rebuild库存生产管理系统3.9.5
下载
rebuild是一款高度可配置化的企业管理系统!可免费商用!低代码/零代码快速搭建企业中台、OA办公自动化、CRM客户关系管理、WMS库存管理、TMS运输管理、SCM供应链管理，甚至是 ERP 企业资源计划!REBUILD 侧重于业务需求实现，而非基础技术框架或项目启动模板，通过 REBUILD 可以真正实现零代码快速搭建，无需编程、无需编译代码，甚至无需了解技术。 使用开始使用 REBUIL
立即学习“Python免费学习笔记（深入）”；
- YAML 文件存变量（如 port: 8080, log_level: warning），模板里用 {{ port }} 引用
- 用 safe_dump 保存 YAML，避免单引号包裹字符串导致格式错乱
- 模板中用 {% if env == 'prod' %} 控制段落，比 shell 中 if-else 更清晰
- 生成前先校验 YAML 是否合法（pyyaml.load() + try/except），防止上线后配置解析失败
用 logging + cron 实现无人值守巡检
自动化不是写完就完事，得知道它每天有没有跑、哪里出错了。把 print 替换成 logging，配合系统 cron，就能形成闭环。
- 日志级别设为 INFO（非 DEBUG），避免刷屏；用 RotatingFileHandler 自动轮转，防止单个日志过大
- cron 表达式推荐用 0 2 * * *（每天凌晨 2 点），避开业务高峰，也方便白天查日志
- 关键步骤加日志标记，例如 "✅ Disk check completed" 或 "❌ Failed to connect to db-server"
- 错误日志可额外触发邮件（smtplib）或企业微信机器人（requests.post），但首次建议先确保日志落地再加通知
不复杂但容易忽略。写脚本前先想清楚：谁来运行？在哪运行？失败了怎么发现？答案明确了，剩下的就是选对库、写稳逻辑、留好日志。
