题目重点：单host Apache部署场景中定位“上传成功但新功能没上线”，在禁止再发布时核对运行版本与更新机制。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 已授权登录排查，但训练限制不允许直接再发布；先读进程/端口/日志/包与发布agent，不用重复curl上传替代根因调查。
- Apache可能只是静态服务/反代，真正app进程与监听端口需识别，IP直连/用户域名的请求路径可能不同。
解题路线
- 先复现具体URL、响应版本header/页面checksum，并比较主机本地端口、Apache入口与外部请求，确定旧版在哪一层。看Apache vhost/proxy映射，避免检查了错误进程。
- 定位app PID、启动命令、运行目录、artifact路径/版本与监听；上传文件路径/权限/hash和运行进程加载的文件要连接起来。上传HTTP成功并不代表agent检测、校验、解包、切换和重启完成。
- 调查负责更新的cron/服务/agent/watch流程：触发是否运行、权限、时间戳或manifest条件、锁/失败返回、解包目标与symlink，读相应日志按一次releaseId追踪。禁止再发布时保留现场查证。
- 进程版本确实新却外部旧时查缓存/静态asset hash、反代路由或另实例；进程旧则focus发布pipeline，不先刷浏览器当通用解法。
- 改进建议为immutable artifact+checksum、原子指针切换、健康检查/版本可观测、失败回滚与审计。建议需具体可验证状态，不盲目kill进程或清目录。
手动走一遍
包v2在uploads，但cron比较错误目录mtime未触发，PID仍加载releases/v1；再次手动重启可能暂时好却掩盖探测错误。证据应包括上传hash、agent判断与实际exec路径。
规模与取舍
调查按请求链和一次发布时间线缩小范围，不全盘搜所有日志；日志读量受时间窗口/过滤控制。发布机制需保证切换原子和可恢复，单host本身仍是可用性单点。
易错点与追问
容易失分的边界
- 题已禁止再发布仍重传覆盖现场。
- Apache版本与业务app版本混同。
- HTTP上传2xx直接推断运行新包。
继续深挖
- 如果running file已被替换但进程仍旧映像，怎样确认进程加载状态？
- 如何验证新发布成功后流量确实切到目标版本，而非只看部署脚本退出0？
