线下测试与灰度发布的本质

[[人工响应的两分钟极限与发布风险]]指出发布是MTBF最大的敌人，因此提高可用性的另一半功夫要花在变更管理上。线下测试永远比线上调试容易一百倍、也安全一百倍——如果团队还没有完整的线下测试环境（包括代码测试、数据兼容性测试、压力测试等），建议先花时间把这个搞定，不要急着接新业务，因为可用性的阶段性提高，靠的不是运维团队而是产品团队，能在线下完成的测试，绝不能拍脑门直接拿到线上去试。灰度发布是发布众多保险中的最后一道，而不是唯一一道——如果只是为了灰度而灰度、故意人为拖慢进度，反而会造成线上多版本长期共存，可能引入新的问题；如果灰度发布是匀速推进的，说明根本没理解灰度发布的意义——正确的做法是按业务特点采取指数型增长（1%→10%→100%）。这里最容易被忽视的一点是：灰度阶段的第一批用户（Canary/金丝雀）不是随机选出来的，而是要根据业务特点、数据特点，挑选一批有极强代表性的实例去做”小白鼠”——如果要发布一个只给亚洲用户使用的功能，用美国或欧洲集群做发布实验就完全没有意义；甚至每次发布的金丝雀用户，都可能因为这次发布的具体特点不同而重新人为挑选，灰度发布真正要做的事情，远比”按机器台数划分比例”要多得多。回到本质：灰度发布是上线前的最后一道安全防护机制，既不能太慢导致产品团队过度依赖它、把它当成挡箭牌，也不能太随机以至于失去代表性、失去意义——灰度发布的关键全在细节里，而不在”有没有做灰度”这个表面动作上。