判据要能当场判断
回退判据的价值在于把“要不要退”这个争论，变成看数据就能回答的问题。常见判据分四类：可用性（关键接口失败率超过阈值并持续一定时间）、性能（响应时延与吞吐偏离基线一定幅度且趋势恶化）、数据一致性（校验不一致、写入失败或延迟超出容忍范围）、业务功能（关键流程无法完成）。阈值应来自历史监控基线与业务合同要求，并与业务方事先确认容忍时长。
基本信息
| 判据类型 | 可用性、性能、数据一致性、业务功能、外部依赖 |
|---|---|
| 阈值来源 | 历史监控基线、业务合同或服务级别要求、迁移前的验收标准 |
| 决策要素 | 唯一决策人、决策时限、回退执行人与通知对象 |
| 执行要点 | 回退前保存现场（日志、配置、数据快照与时间点），回退后验证旧环境 |
| 记录要求 | 判据触发时间、决策过程、回退动作与耗时、后续复盘结论 |
典型割接场景
- 应用与接口割接：以失败率与时延为核心判据
- 数据库迁移：以数据校验与写入能力为核心判据
- 网络链路切换：以丢包、时延与路由收敛为核心判据
- 存储切换：以多路径状态与 IO 性能为核心判据
- 平台版本升级：以关键业务流程可用性为核心判据
判据示例与处理
| 类别 | 判据 | 处理动作 |
|---|---|---|
| 可用性 | 关键接口失败率超阈值并持续约定时长 | 先按预案处置，超时未恢复即回退 |
| 性能 | 响应时延高于基线一定幅度且继续恶化 | 定位瓶颈，确认无可快速修复的原因后回退 |
| 数据 | 校验不一致、写入失败或复制延迟超容忍范围 | 以数据安全为先，通常直接回退并保留现场 |
| 业务功能 | 关键流程无法完成或结果错误 | 处置并验证，超时未恢复即回退 |
| 外部依赖 | 第三方响应异常且已排除对方侧原因 | 评估是否可降级或切换备用通道，否则回退 |
回退前先保存现场：日志、配置、数据快照与关键时间点。没有这些信息，回退后再想查明原因几乎不可能，同一个问题会在下次割接重现。
阈值必须与业务方共同确认：技术视角的可用与业务视角的可用经常不同，容忍时长要用业务影响来定义，并写入变更单作为共同判据。