项目面里如果写过“参与上线”“做过灰度”，面试官很可能追问：灰度按什么维度切？发现问题怎么回滚？数据库变更怎么兼容？如果只回答“先上一小部分机器”，说明还停在发布动作本身。
灰度发布真正考察的是变更控制能力。新版本一定可能出问题，关键是能否提前限制影响范围，快速发现问题，并且安全退回。
灰度维度要和风险匹配
灰度可以按机器、用户、租户、地区、接口、功能开关等维度切分。按机器灰度适合验证服务运行状态，按用户或租户灰度适合验证业务逻辑，按功能开关灰度适合控制某个具体能力。
如果是企业系统，按租户灰度常常更稳，因为同一个租户内部数据和流程更一致。面向 C 端时，可以按用户尾号、地区或实验分组逐步放量。关键不是选哪种方式，而是知道它能验证什么、不能验证什么。
数据库变更最怕不可回滚
后端发布里，数据库变更往往比代码更危险。删除字段、修改字段含义、强制迁移数据，都可能让旧版本无法运行。更稳的做法是先做兼容性变更：先加字段，不删旧字段；新旧代码同时能读写；等流量完全切到新版本并稳定后，再清理历史字段。
这类变更通常要拆成多次发布。一次性把表结构、代码逻辑、数据迁移全合在一起，回滚会非常困难。面试里能主动提“先兼容，再切流量，最后清理”，会显得更像真实上线经验。
回滚要提前设计
回滚不是出问题时临时想办法。发布前就要知道哪些变更可回滚，哪些只能前滚修复。纯代码问题通常可以回滚；已经写入新格式数据的问题，回滚旧代码可能反而读不懂数据。
因此新功能最好配合开关。发现问题时先关开关，停止影响扩大；如果服务本身有问题，再回滚版本；如果数据已经污染，就需要修复脚本或补偿任务。不同故障路径要提前准备。
发布后观察比发布动作更重要
灰度不是上线后等用户反馈。发布后要看核心接口错误率、响应时间、业务转化、下游调用、数据库慢查询、日志异常和告警。指标正常再扩大流量，不正常就暂停或回滚。
面试里可以这样总结：灰度发布的目标不是慢慢上线，而是可控地验证变更。我会按风险选择灰度维度，保证数据库和接口兼容，使用开关控制功能，提前准备回滚路径，并通过指标决定是否继续放量。这样回答，比“先发 10% 流量”完整得多。
灰度还要关注接口兼容。服务之间如果有调用关系，新版本字段、枚举、错误码变化，都可能让旧服务无法识别。比较稳的做法是新增不破坏旧字段，枚举扩展要让旧代码有默认处理，接口响应不要突然改变语义。
面试里可以主动说：发布前我会确认调用方是否已经兼容，必要时先上线兼容代码，再上线生产方变更。很多线上事故不是代码写错，而是两个服务发布顺序不对。
灰度发布还要有人负责决策。指标异常时，是继续观察、扩大灰度、暂停还是回滚，不能完全靠感觉。提前定义错误率、延迟、业务指标和告警阈值，发布过程中按阈值动作，能减少临场争论，也能避免问题扩大。