业务规则将公司从传统的软件开发生命周期（SDLC）中解放了出来，但这并不意味着业务规则的开发和部署不需要任何的监督管理。反而以我的经验来看，业务规则通常是以更为精细的方式进行跟踪管理的。其中，决策逻辑变化的可追溯性在长期看将发挥巨大的作用。下面我将举例说明决策逻辑的生命周期管理在现实场景中的应用。


基本的版本控制

       首先，我们简单阐明一下什么是最基本的“可追溯性”。对于业务规则来说，版本控制的必要性是显而易见的：万一有人不慎删掉了你所有的业务规则，你会有何感想？这就是为什么我们会在源代码管理系统中进行版本控制，甚至在文档管理系统中也进行同样的应用。我们想确保如业务规则一般的资产是被妥善保护的，一旦发生任何修改，我们都能够发现是谁做出了这些修改，并且当遇到不当修改时，我们能够恢复至初始版本。

       我会在下一篇文章中对版本控制进行更为详尽的分析。但本篇文章中，我将关注生命周期管理中更有趣的一面：即如何安全地把决策逻辑从开发环境发布到生产环境中。


将业务规则推送到预发布环境

       虽然我偶尔见到业务规则在生产环境中被修改的情况，但让我们现实一点，我们仍然需要至少有几个不同的环境来将承载开发与生产部署等功能。在将业务规则推进到生产环境进行发布之前，所做出的修改必须进行测试。无论如何，IT人员是不会允许你直接在生产环境中进行修改的。


       一般而言，公司有着两种发布业务规则的方法：

  • 增量法
  • 封装法

       当使用增量法时，我们可以将需要添加或修改的规则独立出来，单独的对这些规则进行开发测试以及部署上线。例如，你可以用相关标签标记这些业务规则，然后通过规则过滤器进行筛选 ，并只将带有标记的规则发布到目标环境中。使用这种方法的好处显而易见，我们可以先行对已修改好的那部分规则进行发布——比如说当有20条规则需要增添或修改时——只选择已通过测试和批准后的6，7条规则进行发布。规则制定者并不需要按顺序依次来完成对应修改。

       而封装法中，整个项目则作为一个整体进行测试，并作为一个新的“部署包”来进行移植。我此处用部署包（Deployment Package）并不特指什么内容，因为不同架构之间会有细微的差异。但总的来说，封装法就是在生产环境中最终部署了一个崭新的项目，其中同时包含了新、旧规则。这样做的好处是它允许你，或IT人员，对将要部署的规则进行全面的QA测试。

       无论你更倾向于哪种部署方案，规则发布都可以进行自动化的测试与模拟。甚至在必要的情况下，与人工审批相结合。因此，你能够随时查看是谁做出了相关修改，并浏览相应的修改日志。


回退到最新的可用版本

       尽管规则的修改在发布前已经进行了测试和评估。但有时候，哪怕已经进入到生产环境中了，我们仍然想返回进行修改。为什么呢？比方说，在此之前，你只是在现有的数据上测试了规则并得到了期望中的反馈，但并没有机会结合相关业务指标来进行模拟测试。这样很可能带来一种结果，那就是规则的业务表现和业务目标并不匹配。比方说，导致过多的申请需要人工复审。当然也有一种情况是外部条件发生了变化，让你不得不回退到之前的版本。例如新的数据格式就可能会导致与现有的业务规则不兼容。总之，这样的原因有很多。

       现有的回退方式有两种，其中一种方式是回到开发环境，利用版本控制的机制，重新启用出现问题的规则的上一个版本，然后重新发布它们。尽管我们使用这种方式进行回退很久了，但每次回退时，你仍需要确保你只更新了所有出现问题的业务规则。

       另外一种方式是利用现有的发布机制。当然如果之前使用增量法进行规则发布的话，利用这种方式进行回退会有点困难。但如果使用的是封装法，你就可以直接选取最新的一个“好”包，并且重新部署它。这种方法在过去被更为频繁的使用，因为它能更快的提供给你一个经过完整测试的业务规则包。

       当然还有一种能更好的处理这种回退需求的办法，那就是使用发布版本（Release）的概念。针对每一个项目，都创建一个项目视图，并及时冻结，然后只在执行的时候进行调用。这样做的好处是它允许你在生产环境中中同时部署多个发布版本。这样处理有什么优势呢？请允许我列举两个基本的场景应用进行说明。

       比方说，你可能想对新规则进行灰度发布，只针对生产环境中的部分业务试验新规则。通过使用发布版本，你可以用版本8去执行大部分业务，同时用版本9执行选定的小部分样本。不管你是出于安全考虑，还是想要进行冠军/挑战者实验，通过使用发布版本的方法，都可以让业务操作变得更加灵活高效。

       然而第二种场景就涉及到了级联的概念。假设你的业务规则覆盖到了内外部两个不同群体的客户，并且当内部用户已经完成版本更新时，外部用户仍然需要一定时间去升级到新的发布版本。在这一段时间内，你不仅需要为滞后的外部客户提供版本8的支持，同时也需要为领先的内部客户提供版本9的支持。总的来说，发布版本管理让你能同时运行同一项目的不同发布版本。但是需要提醒的是，不要试图通过复制业务规则来达到此目的。这又涉及到另外一个话题了。


       生命周期管理方法和我以上所叙述的很多技术，优势都在于它们强大的兼容性。你并不必依赖于单一的机制，就可以根据你的需要进行分层（类）处理并进行优势整合。





原文作者：Carole-Ann Berlioz

原文地址：http://www.xinshu.ai/blog.html/25

-----------------------------------------------------

上海信数金融信息服务有限公司成立于2015年5月，是中国领先的金融科技公司。公司的产品包括新一代智能决策管理平台、企业级数据管理平台以及大数据征信服务等。
明策智能决策平台，是信数公司和美国硅谷公司Sparkling Logic合作研发的一款引领未来的智能决策管理平台，已经被包括PayPal、摩根大通、LTCG保险、京东金融、掌众金服、中望金服等超过100家国内外知名企业所采用。
Sparkling Logic是一家专业的智能决策引擎研发公司，由FICO Blaze Advisor创始团队建立于2009年，通过对规则引擎、智能决策的不断研究，致力于帮助商业、教育、非盈利和政府组织利用他们的数据和专业知识来更好地自动化决策，推动发展。