让你的下一次部署可重复

收集可识别的输入

使用可在非生产环境中构建的应用程序、对源代码及其产物仓库的访问、版本化配置模式和外部密钥存储。保留一个已知可用的发布版本。这些是自动化的输入；PrivacyNodes 不通过本网站提供部署 API 或流水线运行器。

固定产物，而不是依赖可变标签，例如 latest。Docker 文档说明使用摘要固定以标识确切的基础镜像，同时需要刻意审查更新。可重现性和修补都是责任：永远保留旧的易受攻击镜像不是维护计划。

技术参考： Docker 构建最佳实践.

在更改流量之前编写发布记录

这是一种文档格式，不是可执行脚本。从已审查的产物中填充占位符。仅源代码修订并不能描述环境变化。包括观察到的迁移时长、预期的锁行为、配置差异和最后可用的产物。

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

将记录存储在应用程序停止时仍可访问的地方。引用受保护的恢复凭据，但不要包含其值。指定可以停止提升的维护人员，以及计划回滚不再有效的时点。

将准备与提升分开

首先构建并检查产物。在启动新进程之前验证配置和密钥引用。仅应用为此发布审查过的模式步骤。在目标环境中启动新版本，并在切换流量之前检查依赖；避免将未经审查的破坏性迁移与普通镜像更新合并。

使用 Compose 时，容器已启动并不代表就绪。有意义的健康检查和 condition: service_healthy 可以使依赖等待有用，但无法验证客户工作流。应用程序仍必须处理启动后依赖变得不可用的情况。

技术参考： Docker Compose 启动顺序.

验证的不只是端口绿灯

对于报告 API，检查一次已认证的测试请求、对目标 schema 的一次读取、一次小型排队导出及其文件访问。使用专用测试命名空间并抑制生产环境通知。检查重叠版本是否可能意外重复计划任务。

在检查前编写预期输出：正确的账户范围、预期的示例记录、一次完成的导出且无未授权的跨账户数据。之后记录实际输出和耗时。如果 worker 反复失败或迁移导致 API 读取到陈旧值，首页返回 HTTP 200 是不够的。

明确恢复决策

如果进程无法启动，保持流量仍走工作版本。如果工作流检查失败，停止推广并保留已脱敏证据。与旧构件兼容的增量 schema 可能允许应用回滚。在不兼容的转换之后，旧代码可能不安全；遵循已审查的前向修复或数据恢复计划。

不要无限重复失败的迁移。确定已提交的内容、重试是否安全以及用户是否在新 schema 下写入。 迁移指南 通过列变更阐释这一边界。不要因回滚按钮存在就认为数据可以逆转。

留下另一位维护人员可以遵循的记录

将已部署构件和配置标识符与计划记录进行比对。保留检查、失败尝试和所选恢复操作。将最后一个工作构件置于明确的保留策略之下；验证未完成时不要删除它。

一次有效的演练应让另一位经授权维护者能够解释输入、重复检查并找到恢复说明，而无需翻查你的 shell 历史。它不能证明零停机或未来成功。当 schema、worker 行为或依赖项发生变化时，重新审视它。接下来，收窄 部署身份的权限.