
金丝雀发布
|
381
过。如果我们试图延长运行金丝雀部署的时间,这种情况将变得更加棘手。例如,
如果我们是在星期一进行发布,则可能会将系统工作日的行为与上个周末的行为进
行比较,从而产生了大量噪声。在这个例子中,用户周末使用服务的方式和平时可
能完全不同,从而在这个金丝雀过程中引入了噪声。
之前
/
之后评估过程本身也会引入一个问题,即较大的错误峰谷(由评估之前
/
之后
引入)是否可能比更长时间的小错误率(由小金丝雀引起的)更好。如果新版本是
完全不能工作的,那么我们能够多快地检测到并且回滚?一个前
/
后金丝雀的过程可
能会更快地检测出问题,但是恢复的总时间可能仍然很长,这类似于一个较小的金
丝雀。在此期间,用户体验会变差。
用渐进式金丝雀更好地选择指标
与我们理想的属性不符的指标仍然有可能具有很高的价值。我们可以通过使用更微
妙的金丝雀过程来引入这些指标。
我们可以使用包含多个阶段的金丝雀过程,来验证根据指标进行推断的能力,而不
是简单地只评估一个金丝雀阶段。在第一阶段中,我们对该版本的行为其实并没有
信心或认知。因此,我们希望使用一个较小的阶段,从而最大程度地降低可能造成
的负面影响。在一个很小的金丝雀中,我们更喜欢那些能最清楚地反映问题的指标:
应用程序的崩溃、请求失败等。一旦成功的经过了这个阶段,在下一阶段里将用更
大数量的金丝雀群体,从而提升我们对这个变更影响分析的信心。
依赖关系和隔离
所测试的系统也并不可能运行在真空里。由于实战的原因,金丝雀群体和控制群体
可能共享着后端、前端、网络、数据存储和其他基础设施