金丝雀发布 vs A/B 发布策略

Question

我正在研究不同类型的发布策略，但在金丝雀和A/B策略之间感到困惑。它们两者看起来很相似。

到处都说金丝雀“通过将新版本发布给少量用户来测试部署”，而A/B则是“针对特定客户群体的A/B测试策略。”

那么它们之间的区别在哪里，以及两种策略的用例是什么？

参考文献：https://azure.microsoft.com/en-in/overview/kubernetes-deployment-strategy/

- Vikas Gupta

Answer 1

A/B测试通常旨在检查用户对新UI、功能等的反应（以某种方式，他们喜欢程度有多高）。但是您知道新版本的工作原理。因此，您实际上会将应用程序的两个版本随机发送给所有用户。可以是50-50、80-20、90-10或其他任何比例。有时候功能甚至不相关。您可能想要看看哪个版本吸引了更多的客户等等。

Canary测试更专注于新功能的效果如何以及它是否有效。通常是90-10、80-20、A >> B，从不是50-50，因为如果出现问题，您不希望一半的用户有糟糕的体验。因此，您不能确定新版本是否按预期工作。

最重要的区别（这几乎没有人谈论）是金丝雀测试具有会话关联性。因此，它不会将两个版本都发送给所有用户，而是随机向一些用户发送新版本，并将他们保留在同一版本。

- suren

---

请纠正我，但是 A/B 测试也会有会话亲和性吗？我知道这些旨在服务于两个不同的目的，金丝雀测试可以是在内部测试后从开发和分段环境升级到生产中发生的一种测试，而 A/B 测试只是通过将流量发送到用户子集来查看人们对功能的反应。您希望在修复错误后发布金丝雀部署，但 A/B 测试可能只是对使用产品的人如何对变化做出反应的测试。 - Anshuman Kumar

如果我想使用类似Istio的东西来应用A/B测试，那么实现的方法只是在配置方面有所不同吗？ - Anshuman Kumar

@AnshumanKumar A/B测试不应该具有会话亲和性。通常情况下，您会在预生产环境中修复错误。这就是为什么预生产和生产环境应该相同，这样您就可以重新生成这些内容。不确定我是否理解Istio的问题。Istio可以使用子集进行A/B测试，但会话亲和性仅基于HTTP标头，因为来自外部的流量始终会命中入口网关。 - suren

Istio确实支持基于cookie和header的会话关联，但是如果在非常基本的级别上，要实现金丝雀发布或A/B测试中的两个应用程序版本，我们基本上需要指定发送到每个版本的流量百分比（在Istio的情况下，使用VirtualService）。但是，如果在A/B测试中没有会话关联，则用户可能会得到与上次不同的应用程序版本，对吗？ - Anshuman Kumar

我有点让讨论偏离了Istio，但要点是，如果我们在A/B测试中没有会话亲和力，用户就无法收到他们选择的应用程序版本，对吗？例如，如果我是XYZ社交媒体公司，最初发布“全新”的故事功能作为选择加入功能，如果用户选择加入，他们每次重新打开应用程序时都应该能够获得故事功能。我不否认其他观点，因为A/B测试和金丝雀旨在服务于不同的业务用例。 - Anshuman Kumar

@AnshumanKumar 嗯，我认为这仍然是金丝雀发布，因为它是一个添加故事的新功能。但是你希望用户能够说“我想尝试”。如果你要放弃一个版本并留下另一个版本，那么它将被视为A/B测试。在这种情况下，你会希望他们尝试两个版本并做出决定。 - suren