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 下返回整数。把这些“理所当然”一条条打掉，自动化才算立得住。
