发布后出故障只能手工回滚：灰度、金丝雀与数据库变更实战

问题现象：回滚按钮存在，但真正故障时不敢按

应用代码可以切回旧版本，数据库结构、消息格式和缓存内容却可能已经变化。可靠发布首先要求变更可逆或向前兼容。把发布视为流量迁移过程，而不是一次替换全部实例，可以在影响扩大前发现问题。

灰度发布必须有判定指标

先让少量实例承接内部或低风险流量，观察错误率、P99 延迟、业务成功率和资源使用，再逐步扩大。每个阶段设置最短观察时间和自动停止阈值。只看服务存活探针远远不够，应用能返回 200 也可能产生错误业务结果。

数据库使用扩展—迁移—收缩

先增加新字段或新表，并让新旧代码都能工作；随后双写或后台迁移历史数据；确认所有实例已切换后，再停止旧字段写入并最终删除。禁止在发布第一步直接重命名或删除仍被旧版本使用的字段。大表变更要评估锁、复制延迟和磁盘空间。

消息与接口保持兼容

消费者应忽略不认识的可选字段，生产者不要立即改变已有字段语义。重大变更使用新版本主题或接口，并明确迁移窗口。回滚时要考虑新版本已经产生的数据是否能被旧版本读取，否则代码回退仍会失败。

自动化回滚与复盘

发布系统应记录版本、配置、操作者和指标变化，一旦超过阈值自动暂停，必要时回退流量。问：所有故障都适合自动回滚吗？答：数据破坏和外部副作用可能需要先停止写入并人工判断。发布后应复盘为什么测试和灰度没有发现问题，把新场景加入回归与演练。