数据与配置检查
上线前最容易出错的往往不是代码本身，而是数据与配置。检查项应包括数据库变更脚本是否已在预发环境完整执行、新旧字段是否兼容、配置项是否与目标环境一致。配置差异是线上事故里最容易被忽略的一类原因。
涉及数据迁移时，要确认迁移是否可重复执行、失败后是否可中断恢复，以及过程中业务能否继续读写。可重复执行这一点尤其重要，它决定了出问题时能否安全重试，也决定了排查时敢不敢反复操作。
还要检查默认值与开关状态。新功能应当以关闭状态上线，确认稳定后再逐步开启，避免发布即全量暴露风险。开关的命名与用途也要有记录，否则后续没人敢动，开关会长期停在临时状态。
依赖与容量检查
把系统依赖列成清单逐项确认：第三方接口、缓存、消息队列、存储、证书是否在有效期内。任何一项异常都可能让发布后的表现与测试环境不一致，而这类问题往往在发布后才第一次暴露。
容量方面要关注连接数、磁盘空间与限流阈值。如果某个指标接近上限，应当在发布前处理，而不是等告警发生。 容量问题在低峰期往往看不出来，风险会在高峰期集中释放。
对外部接口的调用频率也要复核。测试环境的调用量远低于线上，很容易忽略对方是否存在频率限制，一旦触发限流，表现可能是部分请求静默失败，排查起来相当耗时。
监控与告警检查
发布前确认关键链路的监控已经覆盖，包括接口成功率、响应时间、错误日志与核心业务指标。没有监控的改动，出问题时只能靠用户反馈发现。可观测性是发布的前提，而不是后续优化。
同时确认告警接收人是否正确、值班安排是否明确。告警发到一个没人看的地方，与没有告警差别不大。值班信息应当写进发布记录，而不是靠临时通知，否则容易出现所有人都以为别人在看的情况。
日志中要避免输出敏感信息，同时保证排查所需的上下文足够。这两点需要在上线前检查，事后补救成本很高，尤其是敏感信息一旦写入就很难彻底清理。
回滚与值守安排
每次发布都要有可执行的回滚方案，并明确回滚的触发条件与决策人。方案要具体到操作步骤，而不是只写一句有问题就回滚。回滚能力决定了发布敢不敢做小步快跑。
发布后的观察窗口也要约定，例如关键指标在半小时内平稳才视为完成。窗口期内保持值守，比事后追查更省成本，也更容易在影响扩散前及时止损。
最后记录本次发布的内容、时间与参与人。这份记录在后续排查与复盘时价值很高，也能让跨时区的协作者了解变更上下文，不必再逐个人询问。
