为什么票务升级不能只准备一个旧安装包
票务系统同时处理实时交易、支付回调、库存、退款和现场核销。新版本若写入旧版本无法理解的数据，即使应用文件成功回退，业务仍可能继续报错。因此回滚设计必须覆盖数据库结构、数据含义、缓存、消息、定时任务、外部接口和设备版本。
发布前的五项硬条件
- 变更可追踪：明确版本、需求、影响范围、负责人、窗口和审批记录。
- 数据库兼容：优先新增再迁移，避免上线时直接删除或重命名旧字段。
- 重复请求安全：订单、支付、退款、核销和消息消费具备幂等能力。
- 配置可回退：开关、渠道参数和任务计划纳入版本控制，禁止只在服务器手改。
- 回滚已演练：在接近生产的环境实际执行，而不是只在文档中描述。
推荐的灰度顺序
| 阶段 | 流量范围 | 重点验证 |
|---|---|---|
| 影子验证 | 复制请求，不产生真实业务动作 | 新旧计算结果和性能差异 |
| 内部灰度 | 测试账号、内部票种 | 基本交易闭环和权限 |
| 低风险灰度 | 小渠道、单窗口或单景点 | 真实支付、退款、核销 |
| 扩大灰度 | 按渠道或景区逐批提升 | 容量、差异和告警 |
| 全量观察 | 全部流量 | 至少覆盖一个业务高峰与结算周期 |
停止条件必须提前量化
不能等“感觉不对”才决定回滚。应提前定义订单创建失败、支付后未出票、库存负数、核销结果未知、队列积压、数据库延迟和外部接口异常的阈值。达到阈值后由谁停止放量、谁决定回滚、谁通知现场，均应在值守表中写清。
三类回滚要分别处理
- 应用回滚：恢复旧镜像或旧代码，并确认健康检查和流量切换。
- 配置回滚：恢复功能开关、渠道路由、限流和定时任务，防止旧代码读取新配置。
- 数据补偿：对灰度期间产生的订单、库存和消息逐笔修复；不建议直接用数据库备份覆盖实时交易。
发布后观察什么
按版本标签拆分订单成功率、支付补单、退款差异、库存告警、核销延迟和客服反馈。只看服务器 CPU 无法证明业务正常。观察结束后保留变更记录、指标截图、异常与处理过程，形成下一次升级的基线。
安全边界：数据库直接回退可能覆盖上线后新增的真实订单。除非经过严格的数据隔离与停机决策，优先采用兼容设计和逐笔补偿。