我们应该在忙时还是闲时发布？

记得阿里云去年因为一个基础设施变更问题导致了大面积用户故障。网上有很多人在说阿里云「居然」在白天进行线上进行线上变更，非常的不专业。那我们今天就来讨论一下应该在什么时间段如何进行线上变更。

在讨论之前，我们先要对齐几个基本的基础条件：

1. 首先，所有的变更都必然有出问题的风险。按照计算机领域的基本常识，没有一次变更可以确保 100%成功。不管进行多少程度的测试，影响的只是失败概率大小的区别。

2. 其次，所有的变更都具备灰度的能力。不管是机组的分组灰度，还是集群的单机灰度，或者是应用层面的用户灰度。不具备灰度能力的传统行业的变更模式，不在本次讨论范围内。那种传统的发布模式，需要多个环境之间的切换和引流，其实也是一种变相的灰度模式。

3. 最后，从引入问题到发现问题到解决问题需要有一定的延迟。按照经验值，引入问题到发现上报问题，一般有 1 分钟的延迟，从发小到问题止血，一般有 2～5 分钟的延迟。总的延迟我们假定有 3 分钟。

如果采用闲时发布，等到真正开量的时候，就等于是 100%引流。我们分变更问题发生概率为 100%、50%和 10%三种情况讨论，

可以看出：

1. TPS 越大，影响面越大。

2. 灰度量越大，影像面越大。

3. 故障概率越大，越容易发现。

对于 10%故障概率，如果 TPS 过小，比如小于 1，可能无法命中，引流的时间也会相应的延长。这种情况对于大部分的生产系统也不可能发生，这里忽略不聊。

总之：

• 如果 TPS 小于 100：我们采用 1%灰度，基本上影响面可以控制在十几个用户。采用忙时发布 1%引流是合适的。

• 如果 TPS 过小，比如只有 10，采用 5%引流，可以保证发现速度和影响面之间的平衡。

• 如果 TPS 过大，比如有 1K。上百个用户的影响就有些大，这里可以有三种解法：

• 忙时发布，引流比例继续降低，比如 0.1%。

• 忙时发布，采用应用层用户引流。引入测试用户。这种可以降低影响面，但是对于基础设施变更不适用。

• 闲时发布，制造持续的人工流量进行验证。这种方式增加了验证的难度，但是对于基础设施的发布，可以考虑。