ansible运维需统一用playbook管理，优先幂等模块并提取变量；systemd服务须设restart=always等三参数；日志须配logrotate或rsyslog；cron任务需声明shell/path并用绝对路径。
用 ansible 而不是手敲命令
人工执行 ssh 连机器、apt install、改 /etc/nginx/conf.d/，看似快，但下次换环境或加节点就卡住。人记不住自己上周在哪台机上多装了一个 python3-pip，也记不清 systemctl restart 是在 reload 之前还是之后做的。
实操建议：
- 所有运维动作统一走
ansible-playbook，哪怕只管一台机——inventory文件里写localhost ansible_connection=local就行 - 避免在 playbook 里写
shell模块调curl或echo >>；优先用apt、copy、template这类幂等模块 - 变量提取到
group_vars/或host_vars/，别硬编码在 task 里，比如把端口号从port: 8080改成port: "{{ http_port }}"
systemd 服务配置必须带 Restart=always 和 StartLimitIntervalSec
很多人写完 systemctl enable myapp.service 就以为稳了，结果进程崩一次就再没起来——因为默认 Restart=no，且 systemd 对频繁崩溃的保护机制（StartLimitIntervalSec）没显式设，导致第 5 次失败后直接放弃拉起。
实操建议：
- 服务文件里至少明确这三行：
Restart=always、RestartSec=5、StartLimitIntervalSec=60 - 不要依赖
ExecStartPre做复杂判断（比如检查端口占用），它失败会导致启动中止；真要校验，放进应用自身启动逻辑里 - 用
systemctl show myapp.service -p Restart确认值已生效，别只看文件写了没
日志路径和轮转规则必须写死在 rsyslog 或 logrotate 配置里
靠 journalctl --since "2 weeks ago" 查问题？journald 默认只存内存+有限磁盘，重启后旧日志大概率丢。更糟的是，有人在脚本里用 echo >> /var/log/myapp.log，结果磁盘被撑爆——因为没人配 logrotate。
实操建议：
- 应用日志统一输出到文件时，必须配
/etc/logrotate.d/myapp，包含daily、rotate 30、compress、missingok - 如果用
rsyslog转发，确保$ActionFileDefaultTemplate和$ActionFileEnableSync设对，否则高并发下会丢日志 - 禁止在 cron 里写
find /var/log -name "*.log" -mtime +7 -delete——这不叫轮转，叫定时删库
crontab -e 里的路径必须用绝对路径，且显式声明 SHELL 和 PATH
*/5 * * * * backup.sh 在你本地 bash 下能跑，放到 crontab 就报 command not found——因为 cron 默认 PATH=/usr/bin:/bin，压根找不到 /opt/python3.11/bin/pip，连 date 都可能调错版本。
实操建议：
- 每条 cron 任务开头加上：
SHELL=/bin/bash、PATH=/usr/local/bin:/usr/bin:/bin - 脚本里所有命令用绝对路径：
/usr/bin/python3 /opt/scripts/healthcheck.py，别信which python3的结果 - 重定向输出必须写全：
> /var/log/backup.log 2>&1，否则 stderr 会静默丢失，你还以为任务根本没运行
可重复不是靠“我每次都这么操作”，而是让机器自己验证前提、拒绝异常状态、出错时留下明确线索。最常漏掉的其实是环境变量继承和权限上下文——sudo crontab -e 和普通用户 crontab -e 的 $HOME 完全不同，连 ~/.aws/credentials 都可能读不到。
