用于自托管的生产就绪应用移交清单

实际上的“生产就绪移交”意味着什么

生产就绪的移交意味着运维可以在不猜测的情况下运行应用。他们能部署已知版本、确认健康状态、响应告警，并在出现失败或回滚需求时恢复服务。如果这些操作依赖于某个开发者的记忆，移交就还没完成。

把移交当成一个包，回答一个问题：如果原开发团队消失一周，运维还能保持系统安全可用吗？

一个完整的包通常覆盖应用做什么、什么算“健康”、发布流程（部署、校验、回滚）、配置存放位置、密钥如何处理，以及如何监控、备份和响应事件。

同样重要的是移交不包括的内容。移交不是承诺要添加功能、重构、重新设计界面或“以后再清理”。那些是有各自范围的独立项目。

在宣布完成前，要就归属和响应时间达成共识。例如：运维负责稳定性并执行部署；产品团队负责路线图变更；开发团队在移交后提供限定时间的支持以处理修复与问题。

创建简单的系统清单（什么在何处运行）

运维只能管理他们能看到的东西。一页简明的清单能在部署、事故和审计时避免猜测。保持用词清晰、具体。

列出系统中每个运行部分以及它们的所在位置：后端 API、Web 应用、后台任务、定时作业，以及移动应用如何连接。即使 iOS/Android 通过应用商店分发，它们仍依赖相同的后端。

包含应用无法运行的外部服务。如果你使用 PostgreSQL、队列、对象存储或第三方 API（如 Stripe、消息、邮件/SMS、Telegram），写清服务的确切名称和用途。

记录网络要求以免托管变成试错：需要的域名（app、api、admin）、端口和协议、谁负责续期 TLS 证书、DNS 在哪管理，以及任何入站/出站允许列表。

最后，用真实数字写下预期负载：峰值每分钟请求数、活跃用户数、典型载荷大小、当前数据库大小和预期增长。即使是大致范围也能帮助运维设置限制与告警。

如果你使用 AppMaster 构建，列出生成的后端、Web 应用和集成，这样运维知道哪些组件必须一起部署。

打包环境配置（但不要泄露密钥）

生产环境通常在枯燥的配置环节出问题：那些只存在于某人脑中的配置。把配置当作交付物。运维应能看到有哪些设置、各环境差异，以及如何安全地修改它们。

先把现有的每个环境命名清楚，即便你认为某些环境是临时的。大多数团队有 dev、staging、production，以及像 “production-eu” 或 “staging-us” 的副本。注明哪个环境用于发布测试、数据迁移和演练。

提供一个单一的配置参考，列出变量名和安全的示例值（绝不是真实凭证）。把占位符标注清楚。

你的移交包应包括：

• 列出环境及各自用途
• 配置键参考（环境变量或配置文件键）、预期类型和非机密示例值
• 环境间的已知差异（功能开关、速率限制、缓存大小、邮件模式、日志级别）
• 缺少某个键时的默认行为
• 配置存放位置及部署时如何应用

添加一个简单的变更流程。例如：通过工单请求、服务负责人评审、先在 staging 应用，然后在计划窗口里提升到 production，并有错误率上升时的回滚方案。

如果你导出并自托管 AppMaster 应用，遵循同样规则：随生成的源码一起交付一套干净、记录完备的配置键，让运维能在不同环境中一致运行。

密钥与凭证：存储、轮换与访问

密钥是把干净移交变成安全事故的最快方式。目标很直接：运维应知道应用需要哪些密钥、它们存放在哪、谁能读取，以及如何在不停机情况下更换它们。

从一份能在一分钟内浏览完的短密钥清单开始。对每项说明它解锁什么（数据库、SMTP、Stripe、JWT 签名密钥）、放在哪里（vault、云密钥存储、Kubernetes Secret、加密文件）以及谁负责轮换。

把轮换步骤写成菜谱式的操作而不是政策文本。包含确切顺序、旧密钥必须保持有效的时长，以及证明生效的那一步检查。

轮换检查清单（示例）

对每个密钥使用此模式：

• 在批准的密钥管理器中创建新密钥并存储。
• 部署配置更改，让应用使用新值。
• 验证：登录、支付或 API 调用成功且错误率保持正常。
• 撤销旧密钥并确认其无法再使用。
• 记录轮换日期、执行者和下次到期日。

明确加密预期。密钥在密钥存储中应为静态加密，应用与依赖间的传输应受 TLS 保护。切勿将密钥放入源码、构建产物或共享文档中。

定义紧急访问（break-glass）流程。如果故障阻止正常访问，明确谁可以批准紧急访问、时限以及事后必须审计的内容。

部署包：产物、版本与回滚

运维只能管理能被重现的东西。好的部署包让三个问题易于回答：我们到底在运行什么、如何再次部署、如果出问题如何快速回退？

包含清晰的“物料清单”来描述构建产物。写明产物类型及如何校验，而不仅仅是存放位置：

• 产物详情：容器镜像名/标签（或二进制/包名）、应用版本、构建日期、校验和
• 源码引用：用于构建的发布标签或提交哈希，以及任何重要的构建标志
• 支持的目标：VM、容器（Docker）或 Kubernetes，并标明推荐默认项
• 部署步骤：先决条件（运行时、数据库、存储）、确切顺序与典型部署耗时
• 数据库迁移：如何运行（启动时自动或手动）、日志存放位置以及如何确认成功

添加一个小且具体的示例。例如：“通过更新镜像标签部署 v1.8.2，运行迁移，然后重启 web worker。如果健康检查在 10 分钟内失败，则回退到 v1.8.1 并停止迁移任务。”

无猜测的回滚

回滚方案应该像凌晨两点能跟着走的操作说明。应写明：

• 触发回滚的信号（错误率、健康检查失败、登录故障）
• 上一个已知良好版本及其存放位置
• 数据库变更是否可逆，以及不可逆时的应对方案

如果应用使用 AppMaster 构建并导出源码以自托管，应包含生成代码版本、构建说明和运行时期望，以便运维日后能重建相同发布。

监控与告警：测什么、何时通知值班

移交未完成，直到运维能看见应用运行状况并在用户抱怨前收到警报为止。

就需要保留哪些日志以及它们落在哪里达成共识（文件、syslog、日志平台）。确保日志时间同步并包含请求或关联 ID，以便端到端追踪事故。

通常需要应用日志（关键事件与失败）、错误日志（堆栈与失败任务）、访问日志（请求与状态码）、审计日志（管理员操作与导出）和基础设施日志（重启、节点压力、磁盘问题）。

接着，定义一小组反映用户体验和系统健康的指标。如果只能选五个：延迟（p95/p99）、错误率、资源饱和度（CPU/内存/磁盘）、队列深度和外部可用性检查。

告警规则应明确无歧义：触发条件、严重性（通知或工单）、谁值班、以及何时升级。附上“已知良好”的仪表盘快照和一段简短说明，描述什么是正常（典型延迟范围、期望错误率、常见队列深度）。这些上下文可减少噪音告警并帮助新响应者快速行动。

备份与恢复：让恢复可重复

备份不是你“拥有”的东西，而是你能按需从中恢复的能力。

写清确切范围：数据库、文件存储（上传、报表、发票）以及那些人们容易忘记的部分，比如不在源码中的配置和读取受保护数据所需的加密密钥。

用通俗术语说明目标。RPO 是你能承受丢失的数据量（例如 15 分钟）。RTO 是你能接受的恢复时长（例如 1 小时）。选择与业务达成一致的数字，因为它们驱动成本与工作量。

包含：

• 备份内容、存放位置与保留策略
• 谁可以执行备份与恢复，以及如何批准访问
• 逐步恢复流程与校验检查
• 恢复日志存放位置，以及“成功”的定义
• 常见失败模式（错误密钥、缺失存储桶、模式不匹配）及修复方法

如果你导出并自托管 AppMaster 构建的应用，包含 PostgreSQL 恢复步骤及任何外部存储桶和用于加密字段的密钥。

安排一次恢复演练。记录时间、故障点和你所改动的内容，以便下次恢复更快、更从容。

运行手册与值班：运维如何处理真实事故

移交只有在有人能在凌晨两点被叫醒并在不猜测的情况下解决问题时才算真实。运行手册把部落知识转成一套值班可以遵循的步骤。

从最常见的事故开始：全面不可用、请求变慢、或某次部署导致故障。保持每个运行手册简短，把最快能得出结论的检查放在顶部，让响应者在几分钟内获得信号。

一个好运行手册包括什么

保持结构一致，以便在压力下快速浏览：

• 用户看到的症状以及如何确认（例如：错误率超过 X%、结账失败）
• 首要检查（服务状态、最近部署、依赖健康、磁盘/CPU、数据库连接）
• 后续检查（查看哪些日志、关键仪表盘、最近的配置变更、队列深度）
• 决策点（何时回滚、何时扩容、何时禁用某功能）
• 升级路径（谁是应用负责人、谁是基础设施负责人、何时通知他们）

如果应用是从 AppMaster 导出或自托管，包含生成服务运行在哪儿、如何安全重启它们，以及各环境预期的配置值。

事故之后：记录关键事实

保留一份简短的事后检查表。记录时间线、最后一次变更、确切错误信息、受影响的用户以及解决方法。然后在细节还新鲜时更新运行手册。

访问控制与权限：谁能做什么

运维只有在能明确谁能操作什么以及如何记录访问时才能掌控系统。

写清实际使用的角色。对很多团队而言，以下几类已足够：

• 部署者：部署经批准的版本并触发回滚
• 数据库管理员：执行模式变更与恢复备份
• 只读：查看仪表盘、日志和配置但不能编辑
• 事故指挥：在故障时批准紧急操作

用简单步骤记录“门禁策略”：谁授予访问、在哪授予（SSO、云 IAM、数据库用户、CI/CD、管理面板）、谁能撤销，以及离职时如何确认已移除访问权。

别忘了非人工访问。列出每个服务账户和任务/集成/监控使用的令牌，说明最小权限原则（例如“只能读取桶 X”）。如果你导出 AppMaster 源码以自托管，包含定义这些身份的环境变量或配置文件位置，但切勿在移交文档中粘贴密钥值。

同时设定审计日志预期：必须记录哪些操作（登录、部署、配置变更、DB 管理操作）、谁能读这些日志、保留期、日志存放位置以及在事件或审查时如何请求日志。

安全与合规基础（通俗易懂）

安全说明应能被非专业人士读懂，同时具体到运维能执行。写一页摘要回答：我们存储什么数据、存放在哪里、谁能访问？

从数据类型开始：客户档案、支持工单、支付元数据、文件。点明敏感类别如 PII（姓名、邮箱、电话）、凭证和公司关注的任何受监管数据。如果你导出了源码以自托管（包括来自 AppMaster 的），说明这些数据在数据库中的存放位置以及哪些服务能读取它们。

然后用实务性的语言写保留与删除规则。说明保留什么、保留多长时间、删除如何执行（软删除 vs 硬删除、延迟清除、备份）。若有法律保全或审计需求，注明谁批准例外。

日志常常泄露比数据库更多的信息。明确哪些日志可能包含 PII（访问日志、错误日志、分析事件），以及如何减少或掩码这些信息。如果某字段绝不能被记录，明确写出该规则。

把审批流程写清：

• 身份验证变更需要指定审批人。
• 与支付相关的变更（Stripe 密钥、Webhook 端点、退款逻辑）需要指定审批人。
• 角色与权限模型变更需要指定审批人。
• 安全补丁窗口与紧急变更规则应成文。

如果只能额外做一件事，那就添加证据注记：审计日志存放位置以及当有人要求证明时如何导出。

示例移交流程：运维在一周内接手

运维接管由小型产品团队构建的客户门户并将其迁移到新的自托管基础设施。目标不仅是“能跑”，而是“运维能在不求助开发的情况下运行”。

一周的节奏

第 1 天：运维在新环境中完成一次干净的首次部署，仅依靠移交包。应用启动，但登录失败，因为缺少邮件服务的环境变量。该项被加入 env 模板，部署重复直到从零开始能成功运行。

第 2 天：故意触发第一个告警。运维进行受控故障（停止某服务或阻断外发邮件）并确认：指标显示问题、告警抵达正确渠道且信息包含下一步操作。

第 3 天：沙盒中的某个令牌过期。由于凭证位置与轮换步骤都有文档，运维在不猜测、不暴露密钥的情况下完成替换。

第 4 天：DNS 切换。一个错误记录指向旧 IP，导致部分用户无法访问。运维使用运行手册按正确顺序验证 DNS、TLS 和健康检查。

第 5 天：第一次备份恢复测试。运维恢复到一个全新数据库并证明门户能加载真实数据。

一周后“完成”的样子

应用运行了 7 天且没有需要神秘修复的问题，有一次成功的恢复、清晰的告警以及可被运维独立执行的可重复部署流程。

导致深夜事故的常见移交错误

把“我们把一切都告诉了运维”与“运维能独立运行”混为一谈，是把平静的移交变成凌晨两点火情的最快方式。

自托管移交后的常见失败模式包括：密钥散落在电子表格或聊天中；回滚依赖开发者；备份存在但从未测试恢复；告警整天在响因为阈值未调好；以及只有某人才知道的环境细节（端口、DNS 名称、cron 计划、云权限）。

例如：你从 AppMaster 导出源码自托管，首次部署成功。但两周后某次配置修改导致登录失败。如果密钥在聊天中流转且回滚需要原开发者，运维就会花数小时恢复到“昨天可用”的状态。

在说“移交完成”前的快速检查

在关闭工单前，运行一次简短的“从零开始”演练。把移交包交给一名运维工程师和一个干净环境（新 VM、新 Kubernetes 命名空间或新云项目）。如果他们能在限定时间内（例如 2 小时）部署、观察并恢复应用，你就接近完成了。

使用这些检查项：

• 仅用打包好的产物、配置文档和运行手册（包括回滚）从零构建并部署。
• 验证每个密钥都在约定位置，并且轮换步骤已写明并经过测试。
• 打开仪表盘并确认它们能回答基本问题：是否在线、是否变慢、是否有错误、资源是否不足？
• 触发一次安全的测试告警以确认通知路径、负责人与免打扰时间如预期工作。
• 在独立环境中执行一次真实恢复测试，然后记录确切步骤与期望结果。

如果你导出了生成的源码以自托管，还要确认运维知道构建输入、版本和发布标签的记录位置，以保证未来发布可重现。

后续步骤：明确归属并保持包的时效性

与将要接手值班的人进行一次最终的演练。把它当成一次彩排。用你交付的确切包验证部署、回滚、恢复与告警都能按步骤运行。

一次完整的演练通常包括：用相同步骤在测试环境和生产环境分别部署，然后回滚到上一个版本并验证应用继续工作；在干净环境中从备份恢复并验证一个简单的真实检查（登录、创建记录、发送消息）；触发一次安全测试告警；以及确认事故时日志与仪表盘的位置。

把归属写清楚。为每个运行手册（部署、事故、恢复）以及每条告警路径（主值班、备份、非工作时间行为）指定具体负责人。如果没有人负责某条告警，它要么被忽略，要么打扰到错误的人。

写一份简短的 Day 2 计划，让运维知道第一周后要改进的事情：调优阈值、检查成本、清理旧产物、审查访问。保持精简并限定时间。

如果你用 AppMaster (appmaster.io) 构建，包含导出的源码或确切的部署目标细节（云供应商、区域、构建设置、所需服务），以便运维在不依赖原始项目工作区的情况下重现应用。设定一个简单的更新节奏，以便在需求变更时更新移交包，防止运行手册与现实脱节。