大型应用的发布或者部署一般都需要制定特定的发布策略圈定发布范围发起变更来试错，从而减少因为不可预见的缺陷引发的故障影响面。
在技术方案评审的时候，对于复杂的需求，一定要考虑到系统升级发布方案，特别是涉及到配置项结构，数据库表模型，API变更的，需要考虑好灰度时，新旧版本的兼容性。复杂的需求，灰度往往是一个周期较长的过程，需要考虑好长时间的新旧版本，是否会出现不一致的场景已经应对方案。
错误的方案会导致即使发布经过了灰度流程，但是也不能发现问题，甚至有可能灰度本身反而会引起线上问题。
【最佳实践】
- 灰度方案设计时要注意是否向前兼容。
- 对于向前不兼容的场景，在设计灰度方案时要结合业务特性，使得灰度流量不要逃逸到正常机器上。如在营销工具升级中，可以按照商品分流，同一件商品要么都在灰度工具，要么都在旧工具。
- 涉及到写数据的灰度，如果不能做到向前兼容，可以通过数据加version，来保证新版本的数据由新逻辑处理。
- 灰度方案要有可逆向方案，