Linux 自动化运维实战教程

linux自动化运维的关键是可维护性与失败可见性，需严控权限、路径、环境变量；crontab要设shell/path、用绝对路径、重定向日志；ansible连通性排查优先于编写playbook；rsync增量同步须用-a且注意文件系统限制；python脚本在cron中需加-u或配置行缓冲。

Linux 自动化运维不是写一堆 shell 脚本就完事，关键在「可维护性」和「失败可见性」——90% 的自动化故障，源于没处理好权限、路径、环境变量这三样。

crontab 定时任务不执行？先看 SHELL 和 PATH

常见错误现象：crontab 里写的脚本手动运行正常，一到定时就报 command not found 或直接静默失败。

• crond 启动时用的是最小环境，SHELL=/bin/sh，PATH=/usr/bin:/bin，不继承你的 ~/.bashrc
• 别依赖 which 或 alias，所有命令写绝对路径，比如用 /usr/bin/python3 而非 python3
• 在 crontab 开头显式声明环境：SHELL=/bin/bash 和 PATH=/usr/local/bin:/usr/bin:/bin
• 加日志重定向：0 2 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1，否则失败根本看不到输出

Ansible 执行时报错 “Failed to connect to the host via ssh”

这不是 Ansible 问题，是 SSH 连通链路上某环断了。排查顺序比写 Playbook 还重要。

• 先手工 ssh -o ConnectTimeout=5 user@host，确认基础连通性和密钥是否生效
• 检查目标主机的 /etc/ssh/sshd_config 是否允许你用的用户登录（AllowUsers / AllowGroups）
• Ansible 默认用 paramiko 模式，若目标 SSH 服务较新（OpenSSH 9.0+），可能需改用 openssh 连接插件，在 ansible.cfg 加 transport = openssh
• 如果用 sudo 提权，确保 become_method: sudo 且远程用户在 /etc/sudoers 里有免密权限（如 %wheel ALL=(ALL) NOPASSWD: ALL）

用 rsync 做增量同步，为什么每次都在传全量？

rsync 的「增量」依赖文件时间戳和大小双重判断，但默认行为容易被绕过。

• 加 -a 是必须的（等价于 -rlptgoD），缺了 -t 就不保留 mtime，下次同步会认为所有文件都变了
• 如果源或目标挂载自 NFS/CIFS，注意这些文件系统可能不支持纳秒级时间戳或硬链接，导致 rsync 无法准确比对
• 避免用 --delete-after 配合 --checksum：前者删完才校验，后者强制全量比对 checksum，性能崩盘
• 推荐组合：rsync -av --delete --exclude='*.tmp' /src/ user@host:/dst/；加 -v 初次调试，上线后换 -q

Python 脚本在 cron 里跑失败，但 print() 看不到输出

Python 的 stdout 默认行缓冲，cron 下无 TTY，print 不刷缓存，日志就卡在内存里。

• 启动时加 -u 参数强制未缓冲：/usr/bin/python3 -u /opt/scripts/check_disk.py
• 或者在脚本开头加 import sys; sys.stdout.reconfigure(line_buffering=True)（Python 3.7+）
• 别只靠 print，用 Logging 写文件，且 handler 显式设 delay=False，避免日志延迟落盘
• 如果脚本依赖 virtualenv，务必在 cron 里激活完整路径：/opt/venv/bin/python3 -u /opt/scripts/task.py

真正卡住运维自动化的，从来不是语法或工具本身，而是环境差异带来的隐式假设——比如以为所有机器都有 /usr/local/bin 在 PATH 里，或者以为 date +%s 在所有 shell 下返回整数。把这些“理所当然”一条条打掉，自动化才算立得住。