我曾经经历过一次并不顺利的新服务上线。
代码和测试都已经完成，真正发布时却发现环境配置、外部依赖和数据准备没有完全对齐。单独看，每一项都不复杂；集中到上线窗口，任何遗漏都会让团队临时判断。
后来再负责类似项目，我开始提前整理上线清单。
代码不是唯一发布对象
一次功能上线可能同时包含应用代码、数据库变更、配置、定时任务、消息订阅、权限和初始化数据。
这些内容通常由不同角色准备，也可能使用不同发布系统。如果只跟踪代码版本，其他变化很容易依赖口头确认。
上线清单首先要回答：这次究竟有哪些东西发生变化，每项由谁执行，执行以后怎样确认成功。
顺序本身就是方案的一部分
涉及上下游时，同样的改动按照不同顺序发布，结果可能完全不同。
新接口是否兼容旧调用方，数据库字段应该先加还是后加，消费者能否识别新消息，配置在代码发布前生效会发生什么，都需要提前说明。
“各团队同时上线”通常不是可靠方案。真实发布很难完全同步，因此系统应尽量允许新旧版本短暂共存。无法兼容时，则要明确暂停窗口和恢复条件。
上线前要知道如何观察
功能已经发布，页面能够访问，并不足以确认上线成功。
需要提前确定关键观察项：错误量有没有变化，核心流程是否完成，消息是否积压，数据是否按预期生成。若等上线以后再临时寻找指标，最需要判断的时候反而缺少依据。
监控与业务验证也应区分。接口返回成功不代表业务状态正确，技术指标稳定也不代表用户已经能够完成操作。
回滚不能只写“回滚版本”
应用代码通常可以切回旧版本，已经写入的新数据却未必能够自动恢复。数据库结构、消息和外部调用一旦发生，回滚可能比上线更复杂。
清单需要说明哪些变化可逆，哪些只能向前修复。对于不可逆步骤，执行前应有额外确认，也要准备失败后的处理方式。
清单不应无限增长
每次事故后增加一项检查很容易，几年以后清单可能变得很长，其中许多内容已经被平台自动保证，或者不再适用于当前系统。
可以自动验证的，应逐渐交给工具；只适用于特定项目的，不必成为全团队永久要求。清单需要定期删除，而不是只增加。
它的作用不是证明流程已经执行，而是在上线前把容易被分散忽略的条件集中展示。
一次可控发布，不是保证绝不出错，而是知道发生了什么变化，如何确认结果，以及出现偏差时怎样停止。