特性标志的成本是什么？

以下是您需要在渐进式暴露环境中管理特性标志所需了解的内容。

图片来源：

Opensource.com

在之前的文章《部署新版本：特性标志还是环？》中，我介绍了特性标志和基于环的部署，它们都是 DevOps 实践中渐进式暴露的促成因素。

渐进式暴露使我们能够减轻变更发生时的影响，执行迭代实验，评估特性，并获得关于每次变更的快速反馈——所有这些都在生产环境中进行。例如，特性标志使您能够执行短期实验，隔离未完成的工作，微调持续发布，并动态管理长期运行的操作配置和权限。

这是一种实践，不仅能让客户满意，还能让我们创建高效且积极的特性团队。

您可能在问，“有什么陷阱呢？”

对于 基于环的部署，您的主要成本是以“生产优先”的心态管理环覆盖的生产环境。您需要最大限度地减少每次发布的“爆炸半径”，监控每次发布，并快速缓解根本问题。对于 特性标志，您需要管理您的特性标志产品，管理技术债务，并深入了解简单地“翻转标志”的含义。

让我们探讨一下特性标志的一些成本。

产品投资和运营成本

您需要调查并为您的环境找到合适的特性标志解决方案。一些重要的考虑因素包括与您的 DevOps 流程和产品的无缝集成、简单且经济高效的标志管理、执行紧急回滚的能力以及对审计、精细权限和安全性的支持。例如，如果您要将特性标志管理到特定用户，您很可能正在捕获个人信息并进入新的通用数据保护条例 (GDPR) 的领域。

不要构建您自己的自定义特性标志解决方案。 有足够多的可用选项，例如 FeatureToggle、NFeature、FeatureSwitcher、togglz 和 ff4j 框架，以及软件即服务 (SaaS)，例如 LaunchDarkly。使用后者，您可以将维护、更新和基础设施委托给您的 SaaS 提供商，以便您可以专注于产品特性并为您的客户交付价值。

技术债务

通过特性标志，我们将产品分解为可以单独发布的独立部分，使我们的特性团队和业务部门可以控制谁在何时获得哪些特性。通过分解您的产品，您增加了一定程度的复杂性，这需要维护以避免过时的标志和相关代码。

例如，当我们添加一个简单的 ON|OFF 特性标志来隔离一个特性时，我们添加了一个 if-else 代码结构，并将我们的代码和测试路径加倍，如下所示。如果它是实验性特性标志，则其生命周期通常为数周，之后需要将其删除以避免技术债务。对于其他特性标志，生命周期可能会更长；但是，同样的原则适用：一旦您不需要它们，就删除特性标志和相关代码。

当我们添加一个多值 OFF|1|2 特性标志时，我们会倍增特性代码和测试路径。添加两个特性标志后，我们正在维护两个特性，具有五个代码和测试路径。每个路径都需要在每次更改时进行验证和测试，因为我们无法保证何时会切换特性标志。

但还有更多：让我们为一个新特性添加另一个简单的 ON|OFF 特性标志，我们希望为此收集遥测数据以检验一个假设。它再次加倍了特性代码和测试路径，将需要验证的路径增加到七个。更重要的是，它引入了对第二个特性的特定版本的依赖。我们是否等待启用依赖项？我们是否依赖于隔离且可能不完整的特性？谁能确保特性标志不会被意外切换以满足依赖项？很棒的问题，这些问题需要作为您的流程转型的一部分来回答，以鼓励灵活的调度、迭代实验和紧密的团队协作，并促进对这些挑战的实时所有权和管理。

想象一下一个拥有数百个特性标志的产品。您如何识别过时的特性标志以及添加到我们的技术债务（成本）的相关代码和测试路径？您如何说服您的特性团队从功能齐全的产品中更改和删除代码？特性团队需要拥有从萌芽（想法）到衰落（弃用）的特性，使用通用的工程流程，并应用一致的代码和命名约定。识别和删除过时的特性标志和代码必须很简单。

让我们快速看一下 Roll-up Board 扩展的摘录，其中显示了用于检查 activateFF 值的特性标志的 ON 和 OFF 代码路径。

在特性标志管理系统中，该特性具有友好的显示名称 Display Logs 和 display-logs 标志。

乍一看，activateFF 和 display-logs 之间的关系并不明显。作为一名工程师，我不太愿意在没有进一步调查的情况下对代码进行更改（成本）。

理解翻转标志的含义

您还需要考虑一个更重要的成本。翻转特性标志很简单——更改会迅速在生产环境中传播，您的用户开始兴奋地使用您的新特性。您对刚刚启用的特性感到满意，但是您是否确信您了解翻转标志的所有副作用？

我们经常分享以下两个经验，这表明即使使用最好的流程，我们也可能遇到糟糕的日子，从而导致糟糕的客户体验。

一段艰难时期——团队在一次大型营销活动中翻转了一个特性标志，当时公司副总裁 Brian Harry 正在台上。正如博客文章中所述，情况并不顺利。产品经历了意外的身份验证失败，最终在负载下崩溃。
我们如何了解 503 崩溃——团队在他们最受欢迎的扩展程序之一中启用了特性标志。用户遇到了 503 错误，随后是严重的性能问题，最终处理特性标志的 Azure Functions 在负载下失败。

在这两种情况下，都出现了“负载下失败”。在为所有用户翻转特性标志之前，在金丝雀或早期采用者环境中翻转特性标志并模拟预期的负载几天非常重要。对于大型营销活动尤其如此，第一印象至关重要。

扎实的工程流程和实时遥测技术使我们能够检测到问题发生时，识别根本原因并减轻影响。