sghastat82gdbri6dgss1721b1.jpg 之前，我们谈到冠军/挑战者试验是如何在同一个决策点上比较多个实现策略。这次，我想谈谈该技术的另一种应用。使用同一种架构，同一种思路，在生产环境中测试和更新决策逻辑。这不是为了评估策略的业务表现，而是为了在生产环境中逐步发布、逐步测试，也叫灰度发布。
为什么要灰度发布?
      作为软件开发周期(SDLC)方法论的一部分，测试是非常关键的，没有人会在不做测试的情况下发布他的产品。一般情况下，很多人会在QA环境中进行测试，但是这往往是不够的，这时候在生产环境里边发布，边测试（灰度发布）也是非常常见的。当涉及的软件是支持核心业务操作的，那么确保它能如预期的运行是很关键的，但是你要知道，你能在QA环境中做的事情是有限的。
      之前，我看到过覆盖全国的应用，在发布的第一阶段会对某一个省或者某一个地区进行试验性发布，如果一切顺利，再进行全面发布。还有的应用会在保证原先的决策运行的同时发布新的决策，但只记录结果，用于做后续的分析。还有另外一些项目，在生产上发布新的业务逻辑的同时，只是让一部分的交易被新业务逻辑处理（很大一部分还是让原来的业务逻辑处理），这时候往往还需要随机分配待处理的业务到原有业务逻辑和新业务逻辑。
如何进行灰度发布?
      当我们进一步关注如何进行灰度发布时，我们将不可避免地关注冠军/挑战者试验。你有一个冠军策略：即现有的业务逻辑的实现。也有一个挑战者策略：新的和改进的业务逻辑的实现。需要指出的是，在这里我们不是讨论如何“实现”，我们重点讨论的是旧有的决策逻辑和新的决策逻辑本身。在我们的场景中，业务规则或者逻辑发生了变化，但是软件本身的实现是不变的。也就是说，我们并不讨论如何部署实际的软件代码。
      此时，我们会想要先针对未来的一小部分交易发布新的业务逻辑，比如一开始仅在5%的交易中发布新逻辑，这非常类似于之前我们说过的95%的交易采用冠军策略处理，5%的交易采用挑战者策略处理的试验。然后，通过观察一段时间，我们再判断采用新的业务逻辑是否能达到预期效果。然后逐步推广新业务逻辑的发布，增加到20%，50%，直至100%。
为什么使用冠军/挑战者试验来实现灰度发布?
      这是一个很好的问题。不过我们从另一个角度来问：为什么不呢？实现灰度发布的另一种选择是手工编写代码，这意味着你需要编写代码来支持同一个决策的两个版本能够同时运行。我们的决策管理平台运用冠军/挑战者试验能简单和完美地解决这个问题。其他决策管理软件也许能解决这个问题，但是可能会要求你复制存储库或做其他类似的工作。
      其次，你还需要用代码实现对冠军/挑战者试验参数的管理，比如设定执行当前决策逻辑的交易量，和执行新的决策逻辑的交易量。这用代码并不难实现，但改变这些参数意味着要经历一个完整的软件开发周期。比如把百分比从5%提高到20%，你需要软件工程师做出修改，需要QA测试，需要一个正式的生产版本，工作负担相当沉重。而使用支持冠军/挑战者试验的决策引擎改变参数，就和改写一条简单的规则一样简单。我们将业务规则独立出来的初衷不正是如此么？
      最后，需要建立一个机制来跟踪业务逻辑处理的结果，并且衡量能否达到标准。诚然，编写代码也能简单地实现对交易处理结果的检查，但一般我们都会有更高的要求。决策引擎平台的冠军/挑战者试验功能已经实现了自动化追踪每笔交易的执行路径。
思考与回顾
      灰度发布是提高决策质量的重要手段。一旦使用了冠军/挑战者试验功能，发布和监测新的业务逻辑将不再需要花费大量精力。何乐而不为呢？
-----------------------------------------------------
上海信数金融信息服务有限公司成立于2015年5月，是中国领先的金融科技公司。公司的产品包括新一代智能决策管理平台、企业级数据管理平台以及大数据征信服务等。

明策智能决策平台，是信数公司和美国硅谷公司Sparkling Logic合作研发的一款引领未来的智能决策管理平台，已经被包括PayPal、摩根大通、LTCG保险、京东金融、掌众金服、中望金服等超过100家国内外知名企业所采用。

Sparkling Logic是一家专业的智能决策引擎研发公司，由FICO Blaze Advisor创始团队建立于2009年，通过对规则引擎、智能决策的不断研究，致力于帮助商业、教育、非盈利和政府组织利用他们的数据和专业知识来更好地自动化决策，推动发展。