部署、备份与恢复

生产配置要点、不可变镜像发布流程、发布清单、回滚操作，以及独立数据备份的边界。

生产发布前准备

生产配置的权威文件是 infrastructure/alicloud/docker-compose.core.yml，发布和回滚入口分别是同目录的 deploy.sh 和 rollback.sh。环境模板是 env.example。由实例运营者在受保护的位置配置生产值——不要复制仓库历史环境、数据库备份或开发默认值。

生产环境需要 Core 数据库、Redis、对象存储、私有邮件适配器、Web、Nginx 和观测服务。你需要自己设置域名、HTTPS、持久卷权限和网络边界。本文不会指定他人的服务器、SSH 身份或部署地址。

核对关键配置

配置	用途与要求
`CORE_DATABASE_URL`、`REDIS_URL`	Core 和协调服务的连接，不能用旧拆分服务的 schema 代替
`CORE_SESSION_SECRET`、`OTP_PEPPER`、`STORAGE_GRANT_SECRET`、`CORE_CALLBACK_SECRET`	生产环境至少 32 个 UTF-8 字节，四项彼此不同，不能使用开发默认值
`EMAIL_PROVIDER_URL`、`EMAIL_PROVIDER_TOKEN`	Core 到私有邮件投递适配器的连接；生产 token 至少 32 字节
`DEFAULT_USER_QUOTA_BYTES`	非负十进制整数，明确新用户的默认额度
`CORE_ADMIN_EMAILS`	新用户初次创建时的管理员邮箱配置；不会自动改写已有角色
`REGISTRY`、`IMAGE_TAG`	已通过发布门的镜像仓库与固定提交标签

邮件适配器还需要按其模板配置真实的投递提供商。fake-email 只能用于测试，不要因为 API 接受了发送请求就宣布真实邮箱验收通过。

部署与发布证据

先通过质量检查、隔离 smoke、浏览器验收并发布对应镜像。IMAGE_TAG 必须是 sha- 加 40 位小写十六进制的真实已发布提交，不要用 main、latest 或本地未发布提交代替。

: "${IMAGE_TAG:?Set the tested immutable release tag}"
bash infrastructure/alicloud/deploy.sh "$IMAGE_TAG"

脚本会执行发布锁、镜像摘要解析、迁移、启动、健康检查和版本检查，并原子记录 current.env 与历史 manifest。并发发布会以退出码 75 拒绝——遇到这种情况等当前发布结束就好，不要删锁强行并发。

上线后要核对实际镜像摘要和 manifest、服务健康和版本，并完成真实邮箱登录、小文件上传、后台完成、下载内容一致、公开/私有权限检查。公共的 /healthz 只检查 Nginx 边界；/version、/live、/ready、/metrics 和 /api/v1/internal/* 是私有或运维接口，不要为了外部探针把它们公开。

回滚不是恢复数据库

回滚目标必须存在于历史 manifest 中。设置 TARGET_TAG 为那个已验证标签后执行：

: "${TARGET_TAG:?Set a recorded rollback release tag}"
bash infrastructure/alicloud/rollback.sh "$TARGET_TAG"

脚本沿用不可变镜像和健康检查合同。应用回滚不保证自动逆转数据迁移或恢复已改写的文件；迁移兼容性应该在发布前核对好。不要删除持久卷来"回滚"。

备份与恢复

版本列表、镜像和发布 manifest 都不是完整的用户数据备份。运营者需要分别保护数据库、对象数据、必要配置和密钥，定义一致性时间点与恢复顺序，并在隔离环境中演练。不要把备份提交到源码库或上传为公开文档附件。

目前没有可验证的统一一键备份命令，也不承诺零数据丢失、固定 RPO/RTO 或自动灾难恢复。每次备份都要记录范围、校验和、访问权限和实际恢复结果——光有备份文件不能证明能恢复服务。