先确定留痕范围与部署边界

东南亚服务器的自动化部署要能回答三个问题：本次实际部署了什么、配置由谁在何时改动、失败后能否恢复到上一版。建议把代码版本、配置版本、执行人、目标主机、执行结果和回滚结果关联到同一条部署记录中；不要只依赖终端输出，也不要把密码、密钥等敏感值写入日志。

排查部署异常时，先核对目标主机和版本，再检查配置渲染与变更记录，随后查看服务状态和健康检查；确认故障范围后再回滚。以下示例以使用 systemd 的 Debian 或 Ubuntu 服务器为例，应用服务名、目录和健康检查地址均为占位值，执行前应替换为实际配置。操作前确认当前版本可用、上一版仍保留，并确保具备读取日志、切换版本及重启服务的权限。

准备条件

固定部署输入

可重复部署的关键是：同一份代码、同一组配置和同一目标环境，得到可识别、可核对的部署结果。生产环境不要使用“最新版本”这类会随时间变化的输入，应明确指定代码提交号或构建产物版本。

建议在代码仓库中管理以下内容：

• 部署脚本和自动化任务文件；
• 不含敏感值的配置模板及默认参数；
• 服务启动方式、健康检查方法和回滚步骤；
• 部署记录格式与日志保留要求。

敏感配置应由受控的密钥管理方式提供，或者由运维人员在服务器上按权限管理；不要把明文密码提交到仓库、放进命令行参数，或直接输出到任务日志。配置变更应能追溯到提交记录，紧急人工修改也要补录原因、操作者和变更内容。

确认目标主机与现状

执行变更前，先在控制端检查清单和目标主机连通性。以下命令适用于已安装 Ansible 的控制端，inventory/sea.yml 和主机组名称需按实际环境调整：

ansible-inventory -i inventory/sea.yml --graph
ansible -i inventory/sea.yml app_servers -m ping

结果含义：

• 清单中出现非预期主机：先修正清单，不要继续部署。
• 主机检查失败：先处理连接、权限或主机状态问题，避免把连接故障误判为应用故障。
• 检查通过：再核对目标版本、当前服务状态和磁盘空间，确认部署目录所在文件系统有足够空间保存新版本及回滚版本。

涉及配置格式或服务启动参数时，先查明应用实际使用的配置路径和 systemd 单元名称，不应仅凭常见命名猜测。可在服务器上执行：

systemctl list-units --type=service --state=running
systemctl status myapp.service

将 myapp.service 替换为已确认的服务名。若服务不存在或名称不符，应停止操作并核实安装方式、单元文件和运行用户。

配置管理：把变更做成可复核的输入

配置管理要区分“期望配置”和“运行结果”。仓库中保存模板、默认值和变更记录；服务器上的最终配置由自动化任务生成，任务执行前后都应留存版本信息。对于密码、证书私钥等敏感内容，日志只记录变量名称或变更状态，不记录具体值。

以下是 Ansible 配置任务的简化示例。模板文件 templates/myapp.conf.j2 应由项目按应用实际格式提供；示例路径和服务名需替换。该任务只适用于确认服务单元存在、配置路径正确且已安排维护窗口的情况。

- name: Apply application configuration
  hosts: app_servers
  become: true
  serial: 1
  vars:
    app_config_path: /etc/myapp/myapp.conf
    app_service_name: myapp.service

  tasks:
    - name: Render application configuration
      ansible.builtin.template:
        src: templates/myapp.conf.j2
        dest: "{{ app_config_path }}"
        owner: root
        group: root
        mode: "0640"
        backup: true
      notify: Restart application

  handlers:
    - name: Restart application
      ansible.builtin.systemd:
        name: "{{ app_service_name }}"
        state: restarted

这里的 serial: 1 表示逐台处理，适合希望限制单次影响范围的部署；如果目标主机较多，也应先在一台可控主机上验证。backup: true 会在文件变更时留下旧配置副本，但它不能替代仓库记录或定期备份。配置中含敏感值时，应谨慎开启差异输出，避免把秘密写入自动化日志。

如需提前检查计划变更，可先运行语法检查，再使用检查模式观察可能的变更：

ansible-playbook -i inventory/sea.yml deploy.yml --syntax-check
ansible-playbook -i inventory/sea.yml deploy.yml --check --limit app_servers

检查模式是预演，不保证每类任务都能完整模拟实际执行结果。若预演显示意外主机、意外文件路径或大范围变更，应暂停并核对清单、变量优先级和模板内容；不要把“检查模式无报错”当作部署成功。

分步部署与审计留痕

1. 记录部署前状态

部署前记录操作者、开始时间、目标主机、代码提交号、配置提交号、计划变更和当前版本。记录可保存在受访问控制的发布记录系统或审计目录中。至少要能把一次部署与对应的自动化运行日志关联起来。

可在控制端获取代码提交号：

git rev-parse HEAD
git status --short

若工作区存在未提交修改，应先判断这些修改是否属于本次发布。未纳入版本控制的临时改动会造成“相同提交号、实际内容不同”，破坏复现和审计能力。确认版本后，应使用该版本对应的清单和变量执行，而不是临时修改后直接上线。

2. 保存完整执行输出

通过管道保存任务输出时，应启用管道失败状态，防止自动化命令失败但日志命令成功，导致整体返回成功状态。以下示例适用于 Bash：

set -o pipefail
run_id="$(date -u +%Y%m%dT%H%M%SZ)"
ansible-playbook -i inventory/sea.yml deploy.yml \
  --limit app_servers \
  2>&1 | tee "deploy-${run_id}.log"

日志文件本身也要设置访问权限和保留策略。若执行环境会自动保存任务输出，应确认其保存位置、访问权限和保留周期，并确保敏感变量被遮蔽。只保存一份本机临时日志容易在主机故障或人员交接时丢失，重要发布应将记录同步到受控的审计存储。

3. 逐台或分批执行

先在一台目标主机完成部署和验证，再按既定批次扩大范围。部署前核对主机组、限制参数和发布版本；执行中关注任务是否因某一台失败而继续影响其他主机。批次策略应与应用的冗余能力相匹配，不具备冗余能力时，不要假设逐台更新就一定不会影响业务。

任务日志至少应记录：

• 唯一运行编号、操作者和开始结束时间；
• 代码及配置的准确版本；
• 目标主机列表和逐台执行状态；
• 发生失败的任务名称、错误信息及处理结果；
• 是否执行回滚、回滚到哪个版本，以及回滚后的验证结果。

部署后验证与定时检查

验证服务是否真正可用

自动化任务返回成功，不代表应用已正常对外提供服务。部署完成后按由低风险到高风险的顺序核对：

1. 检查服务状态和最近日志。
2. 检查配置文件是否存在、权限是否符合预期。
3. 运行应用自身支持的配置校验或健康检查。
4. 从业务实际访问位置确认关键功能正常。
5. 对照部署记录确认版本、主机和执行结果一致。

服务器上的基础检查命令如下：

systemctl is-active myapp.service
systemctl status myapp.service --no-pager
journalctl -u myapp.service --since "-15 minutes" --no-pager

若服务状态为 active，但业务检查失败，可能是进程虽在运行、应用初始化却未完成，或依赖服务、配置参数存在问题；应继续查看应用日志和健康检查结果。若服务无法启动，先查看最近一次启动错误和配置校验结果，不要反复重启掩盖原始故障。

健康检查命令应使用应用已经提供的本地检查方式。例如，只有在应用确实监听本机对应端口、并提供该检查路径时，才可使用类似命令：

curl --fail --silent --show-error http://127.0.0.1:8080/health

检查地址、端口和返回内容需要按实际应用确认。请求失败可能意味着服务未监听、检查路径不正确或应用未就绪，单凭这一项不能直接判断是网络还是代码问题。

安排定时任务

定时任务适合执行固定、可重复、易审计的检查，例如服务状态检查、配置一致性核验或备份结果检查。生产环境不宜让定时任务自动追随仓库最新版本并直接发布；自动部署应使用明确批准的版本，并保留人工暂停和回滚入口。

在 systemd 环境中，可用 timer 定期调用只读检查脚本。以下示例假设脚本已经过人工验证，且只输出检查结果，不修改应用配置或重启服务。

/etc/systemd/system/myapp-audit.service：

[Unit]
Description=Check myapp deployment state

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/check-myapp-state

/etc/systemd/system/myapp-audit.timer：

[Unit]
Description=Run myapp state check periodically

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

修改 systemd 单元文件会影响该检查任务的调度；应用前应先备份原单元文件，并确认新服务只执行预期检查。启用前可用 systemd-analyze verify 检查文件，再重载 systemd 并启用定时器：

sudo systemd-analyze verify \
  /etc/systemd/system/myapp-audit.service \
  /etc/systemd/system/myapp-audit.timer
sudo systemctl daemon-reload
sudo systemctl enable --now myapp-audit.timer

验证定时器是否加载并查看最近执行记录：

systemctl list-timers myapp-audit.timer
systemctl status myapp-audit.timer --no-pager
journalctl -u myapp-audit.service --since today --no-pager

定时器没有显示下次运行时间、服务执行失败或日志没有更新时，先核对单元文件是否通过校验、定时器是否启用、系统时间是否正确，以及脚本是否可执行。修复后可手动启动服务进行验证；手动执行成功不代表定时器已正确调度，仍需检查定时器状态和后续运行记录。

失败处理：按优先级缩小范围

部署失败后，不要先删除目录或覆盖配置。按以下顺序检查，可以减少误操作：

1. 确认目标和版本。 对照运行记录核对清单、主机组、提交号和限制参数。目标主机不符或版本无法确认时，停止后续操作，先修正部署输入。
2. 确认任务停在哪一步。 查看自动化日志中第一个失败任务，而不只看最后一条错误。若失败发生在模板渲染阶段，优先核对变量和模板；若发生在服务重启阶段，检查配置校验与 systemd 日志。
3. 检查主机资源和权限。 核对部署用户权限、目录权限、磁盘空间及服务单元状态。权限不足应修正最小必要权限，不要用扩大目录权限的方式快速绕过。
4. 区分配置问题与应用问题。 对比本次配置变更、备份配置和上一版应用日志。若配置校验失败，恢复已验证配置或修正模板；若进程启动但健康检查异常，结合应用日志确认是否需要回滚代码。
5. 验证修复结果。 修复后先在单台主机重跑，确认任务结果、服务状态和业务健康检查均通过，再继续其他主机。

发现日志中出现敏感内容时，应立即限制日志访问，按内部流程处理暴露风险，并调整日志脱敏方式。不要为了排障把密钥复制到工单、聊天记录或公开的错误报告中。

失败回滚：恢复上一版并留下结果

回滚应恢复到已验证的代码和配置组合，而不是只把服务重启一次。发布前应保留上一版可用产物、旧配置备份及对应的版本记录；如果上一版文件已被覆盖、配置变更无法追溯，回滚可能无法可靠完成。

采用“版本目录加当前版本符号链接”的应用，可以通过切换链接恢复代码版本。以下是操作示例，适用于应用确实采用此目录结构、服务启动路径指向 current，且目标版本已确认完整的 Linux 主机。路径和版本值必须按现场确认；切换前记录当前链接指向，并确认回滚不会造成数据格式不兼容。涉及数据库结构或不可逆数据变更时，单纯恢复应用文件不足以回滚，应先按应用的变更方案评估数据恢复。

readlink -f /srv/myapp/current

确认上一版目录后，先创建临时链接，再在同一文件系统内替换当前链接。不要将示例中的版本目录直接照搬到生产环境：

sudo ln -s /srv/myapp/releases/REPLACE_WITH_KNOWN_GOOD \
  /srv/myapp/current.rollback
sudo mv -Tf /srv/myapp/current.rollback /srv/myapp/current
sudo systemctl restart myapp.service

替换链接会改变服务下次启动使用的应用版本，可能影响当前业务。执行前应记录旧链接目标并确认上一版存在；若切换后验证失败，按同一方式切回记录的旧目标，并重新检查服务。不要在验证完成前清理旧版本目录。

回滚后按部署验证步骤检查服务状态、日志和业务健康检查，同时记录回滚触发原因、操作者、目标版本和验证结果。若恢复代码后仍然失败，说明问题可能来自配置、依赖或数据状态，应停止连续重试并继续缩小故障范围。

上线验收清单

• [ ] 代码、配置和自动化任务均有明确版本，生产部署输入没有未记录的临时修改。
• [ ] 目标主机清单、操作者、执行时间和运行编号已留档。
• [ ] 执行日志可访问、权限受控，并且没有明文敏感值。
• [ ] 新版本和上一版均可识别，回滚目标经过确认。
• [ ] 配置校验、服务状态、应用日志和业务健康检查均通过。
• [ ] 定时任务只执行预期操作，已验证调度状态和执行日志。
• [ ] 失败处理及回滚过程有记录，未在验收前清理旧版本或备份配置。