根本原因是环境不一致：PATH、权限、glibc版本、/bin/sh指向（dash/bas）、SELinux上下文、临时目录挂载选项等差异导致脚本或服务行为异常，需逐项验证。
为什么脚本在测试机跑通，一上生产就挂？
根本原因往往是环境不一致，而不是脚本本身有 bug。Shell 脚本极度依赖运行时上下文，PATH、用户权限、glibc 版本、甚至 /bin/sh 指向的解释器（dash vs bash）都可能让同一份脚本行为迥异。
- 用
ls -l /bin/sh确认默认 shell —— Debian/Ubuntu 默认是dash，不支持[[ ]]或数组，而 CentOS 通常是bash - 在脚本开头强制指定解释器：
#!/usr/bin/env bash，避免隐式依赖系统默认 - 别信“PATH 一样”，执行
echo $PATH对比两台机器；更稳妥的是所有命令写绝对路径，比如用/usr/bin/curl而非curl - 检查 glibc 兼容性：
ldd --version | head -n1，若生产环境版本更低，编译好的二进制或 Java 程序会直接报GLIBCXX not found
服务启动成功了，但 curl 不通？查这三处
自动化部署常卡在“看似成功，实则不可用”阶段。启动命令返回 0 不代表服务真在监听、可响应、能连数据库。
- 确认端口监听：
ss -tlnp | grep :8080，不是netstat（已逐步淘汰），且必须带-p看属主，避免被其他进程占坑 - 验证本地连通性：
curl -v http://localhost:8080/health，别只看systemctl is-active—— 它只管进程是否存活 - 检查依赖服务状态：比如 Tomcat 依赖数据库，要单独验证
mysql -h 127.0.0.1 -u app -p appdb -e "SELECT 1"，不能只等应用日志报错才行动
权限问题不是 chmod 777 就完事
盲目加权限反而掩盖真实问题，还引入安全风险。Linux 权限失败的核心，其实是“谁在操作、对什么路径、以什么上下文”三者不匹配。
- 确认服务运行用户：
ps -eo user,comm | grep jenkins，然后检查该用户对/var/lib/jenkins是否有读写权，而非 root 用户有没有权 - SELinux 是静默杀手：
ls -Z /var/log/jenkins查上下文，若显示unconfined_u:object_r:default_t:s0就大概率不对，应为system_u:object_r:jenkins_log_t:s0；修复用restorecon -Rv /var/log/jenkins - 临时目录权限易被忽略：
/tmp或/var/tmp若被noexec或nosuid挂载，Java 应用或 Python 的tempfile会静默失败，用mount | grep tmp核查
日志里没报错，但部署就是卡住？开 debug 模式
很多工具（Jenkins、Cobbler、Ansible）默认日志级别太低，关键信息被过滤掉。别靠猜，要让系统“开口说话”。
- Jenkins 启动慢？在
/etc/sysconfig/jenkins加JENKINS_JAVA_OPTIONS="-Djava.util.logging.Level=FINEST"，再看journalctl -u jenkins -f - Cobbler 部署卡在 PXE？运行
cobbler sync --verbose，并检查/var/log/tftp.log和/var/log/messages中 TFTP 请求是否到达 - Ansible 执行无响应？加
-vvv参数，它会输出每一步的远程命令、环境变量和 stdout/stderr，比看 playbook 更快定位卡点
最常被跳过的一步，是没确认目标机器是否真正“干净”——残留的旧进程、锁文件（/var/run/myapp.pid）、未清理的临时目录，会让新部署在无人察觉时反复失败。上线前花 30 秒执行 ps aux | grep myapp 和 ls -l /tmp/*myapp*，远比事后翻几小时日志省力。
