现实总是比我们想象的更真实。在软件世界中尤其如此——在白板上或测试环境中看起来完美的东西往往会变成……当它处理生产工作负载的不可预测性时，就不那么完美了。这就是为什么蓝绿色部署那功能标志（或切换）,金丝雀部署已经成为现代软件团队的重要工具:它们允许团队在部署出错时快速回滚更改——或者至少最小化客户影响。
在New Relic，我们相信canary部署为我们提供了最有效的方法，以最少的破坏方式部署新服务给我们的客户。在canary部署中，您将首次在“金丝雀“跨水平缩放服务的节点。您可以随机将流量随机分发到金丝雀节点或将其基于一些预定义的标准（例如，将Canary流量部署到您所识别为愿意早期采用者或特定基础设施集的用户的流量。当您验证金丝雀不会引起问题时，您将在所有用户访问该新代码之前向更多实例推出更改。如果新的代码为您的用户或基础架构出现问题，部署少数金丝雀实例使其更加容易回滚更改。
但是，什么才是有效的金丝雀部署呢?在这里，我们将看看我们在New Relic开发的一些最佳实践，这些实践使用canary快速移动，同时最大限度地减少对用户和平台的干扰。
有效金丝雀部署的考虑因素
在他的谈话中“良好的金丝雀:从金丝雀大量人口中吸取的教训”从srecon18.那Ště锅Davidovič，谷歌的网站可靠性工程师，定义了他所谓的，“金色之三人”。
Štěpán解释说，有效部署canary的关键是在三个不同关注点之间找到合适的平衡:
- 金丝雀时间：较慢的金丝雀卷展览意味着更好的数据但速度降低。
- 金丝雀尺寸：使用更大的金丝雀实例集可以更好地代表总体人口，但也增加了坏金丝雀的影响。
- 度量标准选择：使用更大的指标集来评估金丝雀实例和非金丝雀实例，可以提高金丝雀部署的预测精度，但也可能在评估中引入噪声和错误信号。
考虑到这些问题，下面是我们在New Relic使用金丝雀时所依赖的9个最佳实践。
canary部署的9个最佳实践
1.总是在部署时使用金丝雀。避免认为“这个变化很小，我们不需要金丝雀”——这几乎总是错误的判断。如果不能使用金丝雀来测试对服务的更改，请认为该服务存在高风险，并直接进行可靠性工作，以便使用金丝雀来部署服务。我们要求各个团队想出一个合适的金丝雀策略所有而不是根据具体情况做出决定。
2.金丝雀随着交通周期部署。如果您看到正常的工作负载高峰和低谷，请在高峰流量之前确定金丝雀周期的时间，并覆盖高峰流量期间的一部分。
3.避免在服务池或工作量中的异常值上关注大公。如果您的工作量的特定部分代表服务的配置文件中的持续的异常值，请确保您所选的金丝雀实例不会对这些异常值不成比例地关注。Canaries应涵盖您服务处理的主要模式/类型的工作量。例如，如果数据库服务有一个或两个碎片，则在剩余部分被读取的同时重写，则每个工作负载模式中的每种都应该至少有一个金丝雀。
4.对于关键服务，部署更多的金丝雀并监控它们的时间更长。这一点似乎是显而易见的，但是部署到关键服务的金丝雀的寿命应该比部署到非关键服务的金丝雀的寿命更长。更长的提示时间将更好地检测诸如缓慢内存或资源泄漏等问题，以及此类变化对工作负载的影响。对于高度关键的服务，我们建议金丝雀的持续时间为4到24小时。对于所有其他服务，我们建议至少1小时的时间。类似地，您应该为关键服务部署更多的金丝雀。
5.您如何评估您的金司，不应该是当下或临时决定的刺激。定义并记录您将用于评估金丝雀实例和非金丝雀实例的指标。在大多数情况下，错误率、响应和事务时间以及吞吐量是需要度量的正确核心指标。根据需要，根据服务的特定配置文件添加额外的度量。
6.您的金丝雀进程应支付5％至10％的服务工作量。例如，如果服务层通常由100个实例组成，则您应该在这些实例的5到10上金丝金丝雀。一本金丝雀，仅覆盖1％至2％的工作量更可能错过或最小化一些重要案例;如果它不像预期工作，那么覆盖超过10％的工作量的金丝雀可能具有太大的影响。
7.您的金丝雀种群应该足够小，以至于初始金丝雀集的完全失败不会淹没剩余的服务节点。使用金丝雀的整个点是新部署的更改可能比目前生产的代码稳定。如果Canaries失败，或者您需要快速滚动它们，则不希望在服务层的其余部分中创建级联失败。一般而言，这意味着您需要在服务层中有空闲容量，该服务层至少等于将由初始金丝雀集处理的工作负载百分比。
8.实际情况下，金丝雀过程应该包括一个以上实例的金丝雀种群。有些服务层足够小，您可以用一个金丝雀实例来满足实践#6和#7。但是，对于扩展范围更大的关键服务，使用多个金丝雀有助于减少根据离群工作负载或主机配置评估金丝雀的机会。
9.如果你使用特性标志或蓝色/绿色部署，使用它们与金笛一起结合起来。使用要素标志时，通常您可以将新的代码路径部署到服务的所有实例，并且该标志用于控制新代码路径的使用情况。遗憾的是，如果将新代码介绍到整个服务层，并且该代码路径被证明是有问题的（例如，回归线连接线程或其他资源），整个服务将受到影响。换句话说，您不能保证在您的功能标记的代码和其余的服务之间具有批量。
使用蓝绿色部署时，即使您的回滚机制是快速的，将整个服务层翻转到新版本，即使您的回滚机制是快速的，您的服务的依赖项可能需要时间才能恢复;贮藏可能需要加热;你可能会遇到一个奔腾如雷服务重启时。
记住这一点，使用金丝雀来预测特性标志或蓝色/绿色部署出现问题的可能性。
定义为您工作的策略
在我们目前的规模、复杂性和对可靠性的强调下，这些最佳实践对我们New Relic来说是有意义的。当然，对您的组织有意义的具体情况可能会有所不同——但是canary部署是一种神奇的工具，它可以帮助软件团队自信地快速行动。不过，与任何其他策略一样，canary的有效性取决于良好的规划和设计，这些最佳实践应该使您走上有用的、可行的canary部署的正确道路。
