金丝雀测试｜ Canary Testing

金丝雀测试｜ Canary Testing
- 相关术语
- 关于金丝雀测试的问题吗？

金丝雀测试是一种通过逐步向一部分用户发布更改或更新来检测问题的技术。经常搭配 A/B 测试，它使开发人员能够在完整发布之前根据反馈评估和完善功能。

关于金丝雀测试的问题吗？

基础知识和重要性

什么是金丝雀测试？

金丝雀测试是一种在完全部署之前向一小部分用户或服务器推出新功能或更新的做法。该策略允许团队在受控环境中监控变化的影响并及早发现潜在问题。它因历史上在煤矿中使用金丝雀来检测有毒气体而得名。 主要好处包括降低广泛问题的风险、现实世界的反馈以及在必要时快速回滚更改的能力。成功取决于监控关键绩效指标 (KPI) 和用户反馈，且不会产生重大负面影响。实施涉及选择用户群或服务器的子集、部署更改，然后监控性能和稳定性。先决条件包括拥有强大的部署管道、功能标记功能和监控工具。金丝雀测试的 常用工具 包括 Kubernetes、Istio 和 AWS CodeDeploy 等云提供商服务。可以通过控制部署过程和监控结果的脚本和 CI/CD 管道来实现自动化。通过仔细选择金丝雀组和彻底监控，可以缓解有限的用户反馈和倾斜的性能指标等挑战。最佳实践包括从小用户群开始、使用功能标志以及制定明确的回滚策略。金丝雀测试是 CI/CD 和 DevOps 不可或缺的一部分，促进小型、频繁和安全的发布。在云环境中，它利用云可扩展性和分布。它与A/B testing 的不同之处在于关注稳定性而不是用户体验比较。在微服务中，金丝雀测试对于确保单个服务更新不会破坏整个系统至关重要。

为什么金丝雀测试在软件开发中很重要？

金丝雀测试在软件开发中至关重要，因为它充当早期预警系统，用于在实际生产环境中的问题影响整个用户群之前检测到这些问题。通过向一小部分用户推出新功能或更改，开发人员可以实时监控影响和性能，确保及时识别和解决任何潜在问题。这种方法可以最大限度地减少大范围中断或严重bugs的风险，这可能会导致用户不满意和潜在的收入损失。金丝雀测试的有效性取决于对关键绩效指标 (KPI) 和用户反馈的仔细监控和分析。成功取决于是否存在关键问题以及金丝雀组的积极响应，从而可以放心地进行更广泛的发布。在实践中，金丝雀测试通常在 CI/CD 管道中实现自动化，使用支持功能标记、流量路由和自动回滚的工具。自动化可以快速部署和撤消变更，这对于维持生产环境的稳定性至关重要。通过将金丝雀测试集成到 DevOps 生命周期中，组织可以培养持续改进和风险缓解的文化。它成为迭代开发过程中不可或缺的一部分，确保新功能不仅快速而且安全地交付。这在微服务架构和云环境中尤其重要，其中系统的复杂性和分布式特性可能会放大故障的影响。总之，金丝雀测试是一种以受控方式验证稳定性和用户满意度的战略方法，从而保护用户体验和生产环境的完整性。

金丝雀测试的主要优点是什么？

金丝雀测试的主要优点包括：

风险缓解：通过逐步向一小部分用户推出更改，可以遏制潜在的负面影响，并且不太可能影响整个用户群。
用户反馈：来自真实用户的早期反馈有助于识别早期测试阶段可能未发现的问题。
性能评估：它允许在生产环境中监控新功能或更新的性能影响，而无需全面暴露。
快速回滚：如果出现问题，可以快速恢复更改，而不影响大多数用户。
对版本的信心：成功的金丝雀测试增加了软件在满负载和所有用户群下良好运行的信心。
持续交付：通过实现频繁且安全的代码发布来支持持续交付实践。
有针对性的测试：可以针对特定的用户组，这对于测试与某些人口统计或用户行为相关的功能特别有用。通过利用这些优势，组织可以增强其发布管理流程，确保以高质量交付新功能和更新，并将对最终用户的干扰降至最低。

金丝雀测试与其他类型的测试有何不同？

金丝雀测试与其他类型的测试的不同之处在于它采用增量方法来推出更改。与**A/B testing（同时向不同受众比较两个版本）不同，金丝雀测试在完全部署之前向一小部分用户引入了新版本。这与 集成测试 或 系统测试 形成对比，后者的重点是检查组件或整个系统的互操作性，通常在测试环境中。在 性能测试 中，重点是负载下的系统行为，这可以是金丝雀测试的一部分，但不是其主要目标。 冒烟测试是一项初步测试，旨在揭示严重到足以拒绝预期软件版本的简单故障，而金丝雀测试更多的是关于用户体验和发现类似生产环境中的问题。金丝雀测试也与蓝/绿部署不同，后者维护两个相同的生产环境，并且在测试后流量立即从蓝色切换为绿色。金丝雀测试增量转移流量，监控每一步的问题。最后，与 单元测试 专注于孤立的各个组件不同，金丝雀测试在更改后评估应用程序在生产环境中的整体稳定性和功能，提供安全网来捕获单元或集成测试可能遗漏的问题。本质上，金丝雀测试是一种风险缓解策略**，它允许现实世界的暴露和反馈，同时对用户群的影响最小。

“金丝雀测试”一词的起源是什么？

“金丝雀测试”一词的灵感来自煤炭开采的历史实践。矿工们在工作时会携带笼中的金丝雀；由于这些鸟对一氧化碳等有毒气体更敏感，金丝雀的任何遇险迹象都会作为危险的早期预警，让矿工能够撤离。在软件中，金丝雀测试 类似地涉及在更广泛的推出之前向一小部分选定的用户发布新功能或服务。该策略充当早期预警系统，以检测可能影响更大用户群的潜在问题。如果金丝雀版本遇到问题，只会影响有限数量的用户，并且可以快速回滚或修复，从而最大限度地降低整体系统稳定性和用户体验的风险。

执行

金丝雀测试是如何实施的？

实施金丝雀测试通常涉及以下步骤：

选择用户子集 - 确定将接收新版本软件的一小部分用户。
部署新版本 - 将新版本发布给选定的用户，通常使用功能切换或路由机制来引导流量。
监控性能和行为 - 使用监控工具跟踪应用程序的性能以及出现的任何问题。关键指标可能包括响应时间、错误率和系统资源使用情况。
分析反馈 - 收集和评估用户反馈以及自动监控数据，以评估新版本的稳定性和功能。
决定全面部署还是回滚 - 根据分析，决定是逐步向更多用户部署新版本还是在检测到重大问题时回滚到以前的版本。
逐步增加曝光 - 如果金丝雀发布成功，则慢慢增加接收新版本的用户百分比，并不断监控和分析。
完成发布 - 一旦新版本被认为稳定并且没有发现重大问题，就完成向所有用户的部署。在整个过程中，自动化是关键。自动化部署管道、功能标记系统和监控工具对于顺利高效的金丝雀发布至关重要。脚本或配置管理工具可以管理部署到用户子集以及处理潜在的回滚或进展到完整版本的复杂性。

典型的金丝雀测试流程涉及哪些步骤？

金丝雀测试进程的典型步骤如下：

选择用户子集 - 确定将接收新功能或更新的一小部分具有代表性的用户。
部署到有限的环境 - 将新版本的软件发布到尽可能接近地反映生产的受控环境。
监控性能和行为 - 使用实时监控工具来跟踪系统性能、错误率和用户反馈。
分析指标 - 根据预定义的成功标准评估关键绩效指标 (KPI) 和指标，以确保新版本按预期运行。
扩展或回滚 - 如果金丝雀版本稳定并满足性能目标，则逐步向更多用户推出。如果出现问题，请回滚更改以最大程度地减少影响。
迭代 - 使用金丝雀阶段的见解来改进软件。根据需要重复该过程并进行调整，直到该版本准备好全面推出。在这些步骤中，自动化在部署金丝雀版本、监控其性能以及管理推出或回滚流程方面发挥着关键作用。功能标志、自动部署管道和监控系统等工具对于平稳高效的金丝雀测试流程至关重要。

实施金丝雀测试的先决条件是什么？

实施金丝雀测试的先决条件包括：

类似生产的环境：紧密反映生产的稳定环境，以确保结果准确。
功能标记系统：无需部署新代码即可打开和关闭功能。
监控和日志记录工具：实时洞察应用程序性能和用户行为。
自动部署管道：实现功能的平滑推出和回滚。
流量路由机制：将一部分用户定向到金丝雀实例。
基线指标：建立与金丝雀版本进行比较的性能指标。
回滚策略：在金丝雀失败时恢复更改的预定义计划。
用户细分：能够根据位置或行为等标准选择用户组进行测试。
版本控制系统：管理代码版本并跟踪部署之间的更改。

  # Example of a feature flagging configuration
  features:
    new_ui:
      enabled: false
      rollout_percentage: 10

确保团队具备分析测试结果并对金丝雀性能做出明智决策的技能。应建立有效的沟通渠道，以快速解决测试阶段出现的任何问题。

金丝雀测试常用哪些工具？

金丝雀测试 的常用工具包括：

Spinnaker：一个开源、多云持续交付平台，支持金丝雀部署和测试。
Flagger ：一个 Kubernetes 操作员，可使用 Istio、Linkerd、App Mesh、NGINX、Gloo 或 Contour 自动推广金丝雀部署以进行流量转移。
Istio：一个服务网格，提供必要的流量管理功能来进行金丝雀测试。
AWS CodeDeploy：一种自动将代码部署到任何实例（包括 Amazon EC2 实例和 AWS Lambda）的服务。它支持金丝雀发布模式。
Google Cloud 部署管理器：允许在 Google Cloud 中进行灵活的部署和金丝雀测试。
Azure DevOps：提供在 Azure 云环境中实施金丝雀版本的功能。
Harness：提供智能金丝雀部署和验证的持续交付平台。
GitLab：为 CI/CD 提供一个平台，其中包括金丝雀部署作为其功能集的一部分。
Argo Rollouts：Kubernetes 控制器和 CRD，提供高级部署功能，例如金丝雀和蓝绿部署。这些工具通常与监控和可观察性平台集成，例如Prometheus、Datadog、New Relic和Splunk，这些平台对于分析金丝雀版本的性能和健康状况以对其成功或失败做出明智的决策至关重要。

如何确定金丝雀测试是否成功？

确定金丝雀测试是否成功涉及评估几个关键指标和指标，这些指标和指标反映了生产环境中新功能或服务的稳定性和性能。应预先定义成功标准，可包括：

错误率：与基线相比，成功的金丝雀测试不应导致错误率显着增加。
性能指标：响应时间和系统资源使用情况应保持在可接受的阈值内。
用户体验：金丝雀执行的关键交易不应降低用户体验。
业务指标：关键业务指标（例如转化率或用户参与度）不应受到负面影响。
监控和警报：不应触发严重警报，监控系统应报告正常活动。要评估这些标准，您可以使用跟踪应用程序性能、用户行为和系统运行状况的工具。如果金丝雀发布达到或超过预定义的成功阈值而没有造成中断或降级，则可以认为它是成功的。相反，如果金丝雀未能满足这些标准，则应将其回滚并解决问题，然后再尝试另一个版本。通过持续监控和自动回滚机制实现评估过程自动化，有助于确保对任何检测到的问题做出快速响应。

挑战和解决方案

金丝雀测试过程中遇到的常见挑战有哪些？

金丝雀测试期间遇到的常见挑战包括：

监控和可观察性：确保强大的监控以及早发现问题可能很复杂。如果没有适当的工具，就很难跟踪金丝雀版本的性能和运行状况。
流量路由：配置基础设施以仅将一部分流量转移到金丝雀实例可能很棘手，尤其是在复杂的环境中。
用户体验一致性：为所有用户维护一致的用户体验，无论他们是路由到金丝雀版本还是稳定版本，都是具有挑战性的。
回滚程序：在发生金丝雀故障时实施自动回滚策略需要仔细规划和测试。
指标和决策：决定正确的指标来确定金丝雀发布的成功或失败至关重要，并且通常需要深入了解应用程序的行为。
环境对等：确保金丝雀环境与生产环境紧密匹配，以避免误报或由于环境差异而产生负面影响。
资源分配：为金丝雀分配资源，同时不会过度配置或影响稳定生产环境的性能。
功能标记：在金丝雀阶段管理功能标记以切换不同用户细分的功能可能会变得复杂。
数据一致性：处理金丝雀版本产生或修改的数据，以确保其与稳定版本兼容。
版本同步：保持金丝雀版本与生产版本同步，以防止可能影响测试结果的差异。通过仔细规划和正确的工具应对这些挑战，团队可以有效地利用金丝雀测试来提高软件质量和可靠性。

如何缓解这些挑战？

缓解金丝雀测试中的挑战需要战略规划和认真执行。以下是一些方法：

流程自动化：使用自动化工具部署和监控金丝雀版本，减少人为错误并加快反馈循环。

stages:
canary_deploy
canary_test
canary_promote
使用功能标志：控制新功能向用户子集的公开，从而实现快速回滚并最大限度地减少对用户群的影响。

    if (featureFlags.canaryNewFeature) {
      launchNewFeature();
    }

密切监控性能：实施实时监控和警报以及早发现问题。应仔细检查指标和日志以确保金丝雀的健康。

    watch -n 1 curl -s http://service.status/metrics | grep error_rate

实施稳健的回滚策略：如果金丝雀表明存在问题，则计划恢复到以前的稳定版本。

    kubectl rollout undo deployment/myapp

逐渐增加流量：从一小部分流量开始，随着对版本的信心增加而逐渐增加流量。

    trafficControl.incrementTraffic('canary', 5);

隔离并包含故障：确保金丝雀中的故障不会影响系统的其余部分。使用容器化或虚拟化来隔离环境。

    docker run --rm -p 8080:80 myapp:canary

收集反馈：在金丝雀阶段收集用户反馈，为有关发布成功的决策提供信息。

    feedbackService.collectUserFeedback('canaryRelease');

记录和审查：发布后，记录结果并审查流程以改进未来的金丝雀测试。

Canary Release Review
Success Rate: 99.5%
Issues Encountered: 1 minor UI glitch
User Feedback: Positive 通过解决这些领域的问题，您可以降低与金丝雀测试相关的风险，并确保更顺畅、更可靠的发布。
流程自动化：使用自动化工具部署和监控金丝雀版本，减少人为错误并加快反馈循环。

stages:
使用功能标志：控制新功能向用户子集的公开，从而实现快速回滚并最大限度地减少对用户群的影响。

    if (featureFlags.canaryNewFeature) {
      launchNewFeature();
    }

密切监控性能：实施实时监控和警报以及早发现问题。应仔细检查指标和日志以确保金丝雀的健康。

    watch -n 1 curl -s http://service.status/metrics | grep error_rate

实施稳健的回滚策略：如果金丝雀表明存在问题，则计划恢复到以前的稳定版本。

    kubectl rollout undo deployment/myapp

逐渐增加流量：从一小部分流量开始，随着对版本的信心增加而逐渐增加流量。

    trafficControl.incrementTraffic('canary', 5);

隔离并包含故障：确保金丝雀中的故障不会影响系统的其余部分。使用容器化或虚拟化来隔离环境。

    docker run --rm -p 8080:80 myapp:canary

收集反馈：在金丝雀阶段收集用户反馈，为有关发布成功的决策提供信息。

    feedbackService.collectUserFeedback('canaryRelease');

记录和审查：发布后，记录结果并审查流程以改进未来的金丝雀测试。

Canary Release Review

金丝雀测试的最佳实践有哪些？

金丝雀测试的最佳实践包括：

逐步推出：从一小部分流量开始，并根据部署的成功逐渐增加流量。
监控和警报：实施强大的监控来跟踪金丝雀版本的性能和运行状况。针对任何异常情况设置警报。
自动回滚：拥有自动回滚策略，以防金丝雀失败。这最大限度地减少了对用户的影响。
定义成功标准：明确定义成功的金丝雀测试的构成要素，包括性能基准和错误率。
使用功能标志：使用功能标志来打开和关闭金丝雀版本，而无需重新部署应用程序。
隔离 Canary 实例：确保 Canary 实例与生产环境的其他部分隔离，以防止任何潜在的污染。
在类似生产环境中进行测试：金丝雀测试应在密切反映生产的环境中进行，以获得准确的结果。
版本控制：将金丝雀版本保持在与主应用程序相同的版本控制中，以保持一致性和可追溯性。
反馈循环：建立反馈循环以快速解决金丝雀测试期间发现的任何问题。
文档：记录金丝雀测试过程，包括部署计划、监控策略和回滚程序。通过遵循这些最佳实践，测试自动化工程师可以有效地使用金丝雀测试来最大限度地降低与部署新功能相关的风险并确保流畅的用户体验。

金丝雀测试如何自动化？

自动化金丝雀测试涉及编写部署和监控流程的脚本，以在类似生产的环境中验证新功能的稳定性，同时对用户影响最小。使用 CI/CD 管道 协调将应用程序的新版本发布到一小部分用户或服务器。 第 1 步：配置您的部署工具（例如 Jenkins、GitLab CI、CircleCI）以触发金丝雀发布。这可以是手动步骤，也可以是合并到主分支后自动执行的步骤。 步骤 2：利用 Terraform 或 AWS CloudFormation 等基础设施即代码 (IaC) 工具为金丝雀配置所需的环境。 步骤3：使用Kubernetes等容器编排工具将应用程序的新版本部署到金丝雀环境，该工具可以管理新旧版本之间的流量分配。

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: canary-deployment
  spec:
    replicas: 1
    selector:
      matchLabels:
        app: your-app
    template:
      metadata:
        labels:
          app: your-app
          version: canary
      spec:
        containers:
- name: your-app
          image: your-app:canary

第 4 步：使用 Prometheus 或 Datadog 等监控工具监控金丝雀的性能。设置警报以通知团队任何异常情况。 第 5 步：使用 功能标志 或 流量路由 规则自动化决策过程，以根据预定义的成功标准扩大金丝雀部署或回滚部署。 步骤 6：将反馈循环集成到自动化中，以确保检测到的任何问题都会导致部署停止并向负责的团队发出警报。通过自动化这些步骤，您可以确保一致、可重复的流程，最大限度地减少人为错误并加快开发人员的反馈周期。

金丝雀测试的一些真实示例是什么？

金丝雀测试 的现实示例通常涉及大规模 Web 服务和应用程序。以下是一些场景：

社交媒体平台：社交媒体公司可能会先向一小部分用户推出一项新功能，例如更新的消息系统，然后再将其部署到整个用户群。这使他们能够在完整发布之前以较小的规模监控性能和用户反馈。
电子商务网站：电子商务网站可能会向选定的一组用户引入新的结账流程，以确保它不会对转化率产生负面影响，也不会引入可能扰乱销售的新bugs。
云服务：云提供商在更新其服务时经常使用金丝雀测试。例如，他们可能会为有限数量的用户更新存储服务，以确保在更新所有区域之前不会出现性能下降或停机。
游戏：在线游戏公司可以向一部分玩家推出新的游戏功能、补丁或更新。他们会监控游戏和服务器的稳定性以及新内容的接收情况，然后再将其提供给所有玩家。
移动应用程序：当新版本的移动应用程序准备就绪时，开发人员可能会选择将其发布给一小群用户或特定区域，以测试其在不同设备和各种网络条件下的性能。在每种情况下，目标都是在类似生产的环境中与真实用户验证更新，同时最大限度地降低出现广泛问题的风险。
社交媒体平台：社交媒体公司可能会先向一小部分用户推出一项新功能，例如更新的消息系统，然后再将其部署到整个用户群。这使他们能够在完整发布之前以较小的规模监控性能和用户反馈。
电子商务网站：电子商务网站可能会向选定的用户组引入新的结账流程，以确保它不会对转化率产生负面影响，也不会引入可能扰乱销售的新bugs。
云服务：云提供商在更新其服务时经常使用金丝雀测试。例如，他们可能会为有限数量的用户更新存储服务，以确保在更新所有区域之前不会出现性能下降或停机。
游戏：在线游戏公司可以向一部分玩家推出新的游戏功能、补丁或更新。他们会监控游戏和服务器的稳定性以及新内容的接收情况，然后再将其提供给所有玩家。
移动应用程序：当新版本的移动应用程序准备就绪时，开发人员可能会选择将其发布给一小群用户或特定区域，以测试其在不同设备和各种网络条件下的性能。

高级概念

金丝雀测试如何融入 DevOps 生命周期？

金丝雀测试适合 DevOps 生命周期，作为降低将新软件版本引入生产的风险的策略。它通常位于 持续交付 管道的末端，在其他形式的自动化测试完成之后。一旦应用程序的新版本通过单元、集成和其他形式的测试，它就会逐渐推广到一小部分生产服务器或用户。该子集（“金丝雀”组）在全面部署之前接收更改。在持续部署的上下文中，金丝雀测试充当最终的真实验证步骤。自动监控工具观察金丝雀版本的行为，检查错误、性能回归或其他问题。如果金丝雀版本表现良好，则可以放心地将新版本推广到生产环境的其余部分。如果出现问题，可以回滚更改，对用户群的影响最小。将金丝雀测试纳入 DevOps 生命周期使团队能够：

检测问题在早期测试阶段没有发现的。
限制影响通过仅将潜在缺陷暴露给一小部分用户来消除潜在缺陷。
收集反馈以及来自生产环境的性能指标。
增加信心全面部署之前的发布质量。为了促进金丝雀测试，DevOps 团队经常使用功能标志、流量路由机制和自动回滚功能。这些工具和实践有助于管理金丝雀测试流程并将其与 DevOps 工作流程的其余部分无缝集成。
检测问题在早期测试阶段没有发现的。
限制影响通过仅将潜在缺陷暴露给一小部分用户来消除潜在缺陷。
收集反馈以及来自生产环境的性能指标。
增加信心全面部署之前的发布质量。

金丝雀测试如何与持续集成/持续部署（CI/CD）集成？

将 金丝雀测试 与 CI/CD 管道集成涉及一些战略步骤。首先，确保您的 CI/CD 工具支持金丝雀部署。 Spinnaker、Argo Rollouts 等工具或特定于云的服务可以对此进行管理。在 CI/CD 管道配置中，为金丝雀版本添加 部署阶段。此阶段应将新版本部署到生产环境的小子集。使用 基础设施即代码 (IaC) 工具（例如 Terraform 或 AWS CloudFormation）来定义金丝雀环境。

  stages:
- name: Deploy Canary
      actions:
- type: Deploy
          config:
            environment: Canary

接下来，定义成功的指标和标准，例如错误率或响应时间，并配置监控工具来跟踪这些指标。使用Prometheus、Datadog或类似工具进行实时监控。

  monitoring:
- name: Error Rate
      threshold: '>5%'
- name: Response Time
      threshold: '<200ms'

使用 CI/CD 工具中的脚本或集成解决方案自动分析这些指标。如果金丝雀满足成功标准，则自动将部署到生产环境的其余部分。如果没有，则触发回滚。

  on_success:
- name: Full Rollout
  on_failure:
- name: Rollback Canary

最后，确保您的管道支持通知，以提醒团队金丝雀的性能和采取的任何操作。

  notifications:
- type: Slack
      on_failure: true
      on_success: true

通过执行这些步骤，您可以有效地将金丝雀测试集成到 CI/CD 流程中，从而实现更安全的部署和更快的反馈循环。

金丝雀测试在微服务中的作用是什么？

在微服务架构中，金丝雀测试 在确保新功能、更新或修复安全地部署到生产环境方面发挥着至关重要的作用。通过将一小部分实时流量引导到新版本的微服务，开发人员可以监控和评估其在现实条件下的性能和稳定性，而不会影响整个用户群。由于微服务的分布式和解耦性质，这种有针对性的方法在微服务中特别有效，允许对各个服务进行隔离测试。成功的金丝雀测试是通过比较金丝雀实例和稳定生产实例之间的关键绩效指标 (KPI) 和指标来确定的。如果金丝雀的表现符合预期或更好，则新版本可以逐步推广到其余流量。这种增量策略可以最大限度地降低风险，并在出现问题时提供快速回滚机制。要实施金丝雀测试，您需要：

支持流量分流的部署系统。
跟踪和比较金丝雀性能的监控工具。
自动回滚功能以实现快速恢复。通常，金丝雀测试在 CI/CD 管道中实现自动化，利用功能标志、服务网格基础设施或云提供商服务等工具来控制流量并自动回滚。将金丝雀测试集成到 CI/CD 和 DevOps 实践中可确保安全网的持续交付，符合增量变更和快速反馈的原则。

金丝雀测试在云环境中如何工作？

云环境中的金丝雀测试涉及在完全部署之前逐步向一小部分用户推出更改。这种方法利用了云基础设施的灵活性和可扩展性。它通常是这样工作的：

部署将新版本的应用程序部署到云环境中有限数量的服务器或容器，确保它们与生产环境隔离。
重定向使用基于云的负载均衡器或流量管理工具将一小部分用户流量发送到金丝雀实例。
监控金丝雀的性能密切相关，使用云监控和日志记录服务来跟踪响应时间、错误率和系统运行状况等指标。
评估金丝雀的行为是否符合既定的成功标准，其中可能包括自动性能检查和错误率阈值。
如果金丝雀是 表现良好 ，在持续监控的同时逐渐增加其流量。如果出现问题，回滚通过将流量重定向远离金丝雀来快速实现。
一旦金丝雀被认为稳定，继续进行 全面推出面向所有用户，跨云环境替换旧版本。云平台提供了用于自动化这些步骤的工具，例如用于部署的基础设施即代码（IaC）以及用于评估的集成监控和分析服务。以编程方式控制资源的能力使金丝雀测试自然适合云原生应用程序，从而实现快速迭代和软件交付的弹性。
部署将新版本的应用程序部署到云环境中有限数量的服务器或容器，确保它们与生产环境隔离。
重定向使用基于云的负载均衡器或流量管理工具将一小部分用户流量发送到金丝雀实例。
监控金丝雀的性能密切相关，使用云监控和日志记录服务来跟踪响应时间、错误率和系统运行状况等指标。
评估金丝雀的行为是否符合既定的成功标准，其中可能包括自动性能检查和错误率阈值。
如果金丝雀是 表现良好 ，在持续监控的同时逐渐增加其流量。如果出现问题，回滚通过将流量重定向远离金丝雀来快速实现。
一旦金丝雀被认为稳定，继续进行 全面推出面向所有用户，跨云环境替换旧版本。

金丝雀测试和 A/B 测试之间有什么关系？

金丝雀测试和A/B Testing 都是通过在全面部署之前验证部分用户的更改来降低风险的技术。然而，它们的关系在于其不同的目标和方法。 金丝雀测试 主要专注于通过逐步将新功能或服务推广到一小部分受控用户来识别生产环境中新功能或服务的潜在问题。目标是在现实条件下监控系统的行为以及新的变化，并在问题影响所有用户之前尽早发现问题。另一方面，A/B Testing 用于根据用户行为做出数据驱动的决策。它涉及比较一项功能的两个或多个版本，以了解哪个版本在用户参与度或转化率等特定指标方面表现更好。用户被随机分配到不同的组，每个组都会体验不同版本的功能。虽然这两种技术都涉及向一部分用户公开功能，但金丝雀测试更多的是关于确保生产中的稳定性和性能，而A/B Testing是关于了解用户偏好并优化用户体验。它们可以是互补的；例如，某个功能可能首先通过金丝雀测试来确保其稳定，然后通过A/B Testing来细化其对用户行为的影响。结合这些策略可以带来强大且用户优化的软件版本。

金丝雀测试 ｜ Canary Testing

相关术语