发布前的准备条件
镜像必须带明确版本号，不要用浮动标签。回滚的前提是能找到上一个可用镜像，标签模糊会让回滚变成重新构建。
配置与镜像分离，数据库连接、密钥、外部地址通过环境变量或配置中心注入。同一镜像应该能部署到测试与生产而不需要重新构建。
数据库变更要向前兼容：新增字段先允许为空，旧代码继续能跑。破坏性变更拆成多次发布，先兼容再清理。变更脚本要同时准备验证语句，执行后立刻确认字段和索引符合预期。
滚动策略的参数
最大不可用与最大超出两个参数共同决定发布期间可用副本的下限与上限。设成零和一是最保守的组合，发布慢但不影响容量。
副本数少的服务要走保守策略，副本充裕时可以适当放宽以加快发布速度。容量规划和发布速度需要权衡。
新副本的启动探测要有初始延迟，给应用留出预热时间。业务有缓存预热、连接池初始化时，探测过早会让实例在没准备好的时候就接流量。
优雅停机的处理
收到终止信号后先停止接受新请求，等待存量请求处理完成再退出。等待时间要小于编排平台给的宽限期，否则会被强制杀掉。
长连接、流式响应、双向通信都可能在滚动期间断开，客户端要有重连和续传逻辑。服务端尽量在可预期的时间点做断连。
注册中心或负载均衡里的摘除存在延迟。应用侧先标记为不健康，等待一个撤流窗口后再真正停止，能减少发布期间的零星报错。客户端的重试要避开已摘除的实例，使用带退避的重试而不是立即连打。
观测与发布判定
发布过程中盯住错误率、响应时间、实例健康数三条线。任一指标越过基线就应该暂停而非继续推进。
分批推进是比一次性全量更稳的做法。先放一小部分流量，观察一段固定时长，确认无异常再扩大比例。
日志和链路追踪要能按版本号过滤，出现问题时能快速确认影响范围是否只限新版本。版本信息写进启动日志和响应头，排查时很省事。
回滚触发与事后复盘
回滚要预先定义触发条件，比如错误率超过某阈值持续若干分钟，避免现场争论。触发后由负责发布的人直接执行，不层层审批。
回滚镜像容易，回滚数据库难。设计了向前兼容的变更之后，代码回滚不需要回滚表结构；如果确实改了结构，要提前准备好反向脚本。
回滚完要核对流量与数据。发布期间写入的数据是否被旧代码正确处理，需要抽查确认，不能只看健康检查通过。
每次发布异常都记录下触发原因、发现方式、恢复耗时。积累几次之后就能看出是探测配置问题、依赖初始化问题还是容量问题。把可自动化的检查固化到发布流水线里，比如健康检查通过后自动跑一轮冒烟用例。
