如果功能标志出错的话

标志出错的话"/>

如果功能标志出错的话

\

主要结论

\

• 功能标志是一个有价值的技术，可以帮助我们更快、更好地开发更可靠的软件。 \
• 功能标志可用于发布管理（摸黑启动，金丝雀发布，Beta测试）和长期控制（权利管理，用户个性化划分）。 \
• 功能标志需要妥善管理，需要对工程人员可见并受其控制。 \
• 如果未能妥善管理，功能标志可能导致非常严重的技术债。 \
• 功能标志真正的力量在于可以让业务用户访问由相互不可见的不同部署控制的代码。

如果功能标志出错的话

功能标志若能妥善利用，将是一项强大的开发技术，可以帮助开发、运维、质保、产品、营销，以及销售人员更快速地将更好的功能投放市场。功能标志可以帮助软件团队实现分批次的软件发布（代码已发布至生产环境，但可能暂时不可被用户可见），这种方式避免了新功能一经发布就立刻能够被所有用户使用。功能标志充当了通往新功能的大门。简单来说，功能可以独立于具体部署被“打开”或“关闭”。\

然而功能标志并不是简单的“开关”。功能标志可能包含百分比和不同片段，根据需求的不同可能极为复杂，不仅可用于发布管理（金丝雀发布，摸黑启动，渐进式推出），而且可用于长期控制（访问级别控制权利，不同的一次性客户操作，以及行为控制）。\

如果未能妥善管理，功能标志也可能造成非常大的麻烦，这种麻烦曾经在30分钟内造成了价值4.6亿美元的损失。如果错误地使用和管理，功能标志也可能产生大量糟糕的技术债。本文将介绍几个功能标志滥用的后果以及从中学到的经验和教训。\

模棱两可/重复使用的标志名

标志应当使用清晰明了，易于理解的名称。类似“user_control”这样名称的标志是最容易造成误解的。某个后端团队可能认为这样的标志只控制了自己目前正在使用的某个功能，然而他们不知道的是，另一个前端团队可能会重复使用这个标志控制自己的某些功能。两个团队开始根据自己的需求同时切换同一个标志，就如同两个人争相控制同一个电灯开关，这将导致该标志永远不会处于正确的状态。最终（通过唇枪舌战）他们终于发现问题所在，开始分别使用不同的标志。\

标志的删除

标志可用于实现短期或长期控制。对于短期发布管理工作，可以将代码部署至生产环境，随后由负责对该功能进行验证的团队开启标志。\

• 质保 – 可确保新功能可以按照预期工作。 \
• 性能 – 可通过百分率推出的方式验证功能可以在现实世界中良好运行。 \
• 产品 – 可以邀请喜欢尝鲜的用户提供反馈。 \
• 用户体验 – 可借此进行易用性测试。 \
• 营销 – 可邀请媒体或分析师预览新功能。

长期标志可用于永久性地控制代码的某些片段。长期标志可用于实现权利管理或用户基数的划分。例如一家SaaS公司可以通过功能标志让多个企业客户访问不同功能的片段，或让新手与高级用户获得不同的功能。判断短期和长期标志之间差异最简单的方法是：看该标志的意图是否是让所有用户最终获得同一个变体。如果是，那么这就是短期标志，需要为这样的标志制定相应的删除计划。然而短期标志通常是暂时性的，一旦完成预定用途需要将其删除。领英（LinkedIn）以不及时清理功能标志而出名，他们曾无意中发布了一个所有标志都处于“打开”状态的版本，进而导致网站不可用，充斥着各种相互冲突又过时的功能。\

这方面有一则最佳实践，可以为短期和长期标志使用不同的命名约定。例如为所有短期标志添加“Temp”作为前缀，或通过功能标志管理系统为不同用途添加恰当标志。随后理想情况下，如果看到某个标志被所有用户调用过后，即可放心地删除该标志。同时如果某个标志未被任何用户调用，则有必要仔细研究一下为什么会发布这样陈旧的代码路径。有时候对工程师来说，删除陈旧的代码可能是最有价值的工作。这样如果未来代码的使命已经完成需要退役，要测试和验证的代码数量会变得更少。\

技术（和非技术）用户的能见性

如果使用功能标志控制各种功能，这等于为系统创建了多个状态。请确保所有部门（工程、质保、性能、支持、营销、产品）都了解这些标志的存在。最起码要确保前端和后端团队保持同步。如果有多个微服务，也要让标志对他人可见，这样不同团队才知道自己该使用哪个接口。\

一旦技术团队完成与其他团队的所有集成测试，确认一切无误并成功发布后，后续的团队还可能在迁移过程中使用功能标志。一旦后续团队更改了标志状态，前序团队的代码可能会被破坏。因此请务必确保每个人都知道各种标志的使用！\

将标志从配置文件中剥离出来并集中放置在一个用户接口中，这种做法可以让所有人获益。这样做的最大好处在于，更改配置文件中的标志通常需要进行完整的系统发布，可能需要耗费数分钟（甚至数小时）的时间。如果可以将标志独立于发布进行更改，整个系统即可更快速应用改动。另外还有一个很重要的建议，需要将所有功能标志集中存储在同一个位置。如果有五个团队分别使用了五个配置文件，这样的悲剧只能造成棘手的混乱。\

如果客户需要通过某个标志才能访问某一功能，必须将这种情况告知客户支持人员。客户支持人员必须能够对这种标志进行排错或开关。而这也是功能标志的一个重大价值：如果某个功能有缺陷或导致性能缓慢，在工程部门对有问题的功能进行迭代的同时，客户支持可以轻松地将其关闭。\

标志本身也可以促进业务

除了可以让用户获益，销售和营销人员也可以借助功能标志，通过新功能吸引现有和潜在客户。功能标志的终极威力在于，非技术用户也可以轻松控制标志的开关。如果深藏于每个部署所绑定的配置文件中，标志的价值也会被埋没，因为无法实时更改，并且更改过程需要工程人员的介入。\

就算不了解JSON或配置文件的非技术人员，也可以不依赖工程人员使用这些标志。如果非技术用户必须开工单，等待工程师更新标志并进行发布，整个过程对所有人都是异常缓慢麻烦的。\

理想情况下，功能标志需要集中保存在一个所有人可见的位置，并独立于代码发布过程进行控制。当某个重要的潜在用户希望访问某一功能时，销售人员可以不求助工程师直接打开对应的标志。当版本发布时，营销人员则可以让记者等人提前访问相应的功能。\

最终，业务用户可以借助功能标志自行启用现有功能，而无须编写任何代码或求助于开发者。\

标志的访问控制

考虑一下功能标志的用途到底是什么，是否是为了...\

• 让性能工程师测试系统负载？ \
• 让营销团队在产品发布时打开相应功能？ \
• 让可用性部门组织早期采用者进行接受度测试？

更大的能力伴随而来的是更大的责任。这三种标志针对了截然不同的用例，应该由不同的人员负责。在组织中不同部门可以看到并管理所有标志后，还要根据需要分配不同的权限。需要严格避免业务用户无意中针对可能有隐患的新功能发起负载测试，或技术用户无意中为无权访问某一功能的用户启用了相关功能等情况。\

日志记录

如果某人可以“开启”或“关闭”某个标志，一定要明确这些人的身份！无论执行这种操作的是人类或自动化脚本，如果某个标志会导致异常行为，我们必须能明确这些行为是谁造成的，这样才能更好地解决问题并进行调试。在面对压力的情况下做出错误的决策，这是所有人的本性，我们的大脑会权衡到底要“战斗还是逃避”，大脑额叶皮层会被荷尔蒙所淹没。快速逃离危险的过程中这是好事，但如果需要冷静地针对复杂问题做出决策，这种情况就会造成糟糕的后果。通过功能标志，我们可以首先将有问题的功能关闭，并在有空的时候考虑解决问题的方法。只是不小心错误设置了三个标志，就在早晨起床前损失了五亿美元，这种悲剧到底是如何产生的？\

骑士资本（Knight Capital）在30分钟内损失4.65亿美元之前，曾是华尔街最大规模的高频交易商。美国证券交易委员会针对此次事件发布了完整报告。简而言之，他们为一个新项目重复使用了一个老的标志（错误1），本应淘汰的代码依然存在于代码库中（错误2）。随后在启用标志后，他们八台服务器中的一台通过本应淘汰的代码快速触发了接二连三的交易。由于在不重新部署的情况下该标志无法轻松关闭（错误3），随之而来的恐慌让问题进一步扩大。恐慌过后，他们通过新发布的版本将所有八台服务器上的这个标志顺利关闭。然而4.65亿美元就这样烟消云散，这一切都发生在早十点前。其实只要避免重复使用标志并及时清理代码，骑士资本就可以避免这样的悲剧，或者就算最糟糕的情况下，可以独立于重新部署单独关闭功能标志，也可以最大程度避免损失。\

结论

总的来说，用可预测、快速、可重复的方式生产高质量的软件，这是你的职责。功能标志可以帮助你和你的团队更快速提供新功能，同时有助于降低风险。但功能标志的使用应该谨慎，更不能有“马后炮”的想法。功能标志必须可管理，可见，可行，可追溯。功能标志已成为现代化软件开发过程的有机组成部分，管理方面更应该重视起来。\

关于本文作者

Edith Harbaugh在面向消费者和企业用户的公司中从事有关产品、工程，以及营销工作超过十年。她在软件开发方面已经申请了两个专利。Edith曾在Microsoft Build、NDC Sydney、GlueCon，以及DevOps West等会议中通过演讲介绍过功能标志的管理。同时她还与CircleCI的创始人Paul Biggar一起主办了名为“To Be Continuous”的播客节目。Edith曾在哈维穆德学院工程系就读并获得学士学位。她平时喜欢参加最远100英里的远距离越野跑活动。

作者：Edith Harbaugh，阅读英文原文：When Feature Flags Go Wrong