cron执行脚本无反应但手动正常，因cron环境隔离：无path、不加载.bashrc、home可能异常；需用绝对路径、显式设path、加日志重定向。
为什么 cron 执行脚本没反应，但手动运行却正常？
cron 环境和当前 shell 完全隔离：没有 $PATH、不加载 ~/.bashrc、$HOME 可能指向 root 或空值。常见现象是脚本里调用的 python、jq、mysqldump 直接报 “command not found”。
- 用绝对路径写所有命令：把
python script.py改成/usr/bin/python3 /opt/scripts/backup.py - 显式设置环境变量：在 crontab 条目开头加
PATH=/usr/local/bin:/usr/bin:/bin - 测试环境一致性：在 cron 的上下文中运行
env，对比你手动执行时的输出 - 日志必须加：每条 cron 任务末尾追加
> /var/log/backup.log 2>&1，否则失败无声
rsync 同步大量小文件变慢，怎么压测和调优？
rsync 默认单线程遍历 + 传输，遇到几十万级 *.log 或 node_modules 类目录，瓶颈常在 stat() 系统调用和 SSH 加密开销，而非带宽。
- 先确认是不是 rsync 自身问题：用
rsync --stats -av --dry-run /src/ user@host:/dst/看耗时分布 - 关键参数组合：
--compress（对文本有效）、--partial（断点续传）、-e "ssh -o Compression=no -c aes128-gcm@openssh.com"（禁用 SSH 压缩，换轻量加密） - 更激进的方案：改用
tar | ssh管道，绕过 rsync 文件比对逻辑：tar -cf - /src | ssh user@host "tar -xf - -C /dst" - 注意：
--delete和--delete-after行为差异极大，前者可能误删，后者更安全但多一次扫描
Ansible 执行时报 “Failed to connect to the host via ssh”，但 ssh 命令能通
Ansible 默认使用 paramiko（纯 Python SSH 实现）或系统 ssh，但两者读取的配置文件、密钥格式、代理设置完全不同。
- 检查 Ansible 使用的是哪种连接方式：
ansible -m ping target -vvv输出里找"connection type" - 如果用 paramiko：它不读
~/.ssh/config，也不支持ed25519-sk密钥；换成ansible_ssh_executable=/usr/bin/ssh强制走系统 ssh - 常见坑：
ControlMaster在 ~/.ssh/config 中启用后，Ansible 并发任务会卡死，临时禁用：ssh_args="-o ControlMaster=no" - 密钥权限必须是
600，Ansible 比普通 ssh 更严格；错误信息里若含"Permission denied (publickey)"，先chmod 600 ~/.ssh/id_rsa
Python 脚本在运维中被 kill -9，如何快速定位是 OOM 还是超时？
Linux 内核在内存不足时会触发 OOM Killer，日志写入 dmesg，不是 syslog 或应用日志；而超时通常是 systemd 或外部监控工具所为。
- 立即查内核日志：
dmesg -T | grep -i "killed process"，如果看到类似Killed process 12345 (python) total-vm:2048000kB, anon-rss:1800000kB，就是 OOM - 对比
/proc/<pid>/status</pid>中的State和OOM_score_adj，高分进程优先被杀 - 避免 OOM：给关键脚本设内存限制，比如用
systemd-run --scope -p MemoryMax=500M python monitor.py - 如果没找到 dmesg 记录，检查
systemctl status your-service或定时任务日志里是否有TimeoutSec触发的终止记录
实际运维里最麻烦的不是某个命令不会用，而是多个系统层（shell 环境、SSH 协议栈、内核调度、Python 运行时）的默认行为互相打架，得一层层剥开看日志源头。
