|
|
|
管理生产环境中的决策
到目前为止，我们的最佳实践系列主要聚焦在决策管理的规则编辑和生命周期管理方面。本文将介绍把决策应用发布到生产环境时应注意的事情。
在决策的生命周期中取得重要进展时，都应该将决策打包发布（Carole-Ann已经在《最佳实践系列：使用发布管理》进行了论述）。我将在此重复其中的重点，以强调其在生产阶段的重要性。
你希望能百分百确定生产环境中的决策逻辑正是你测试过的，而不会因一些意外导致变更。这种“意外”比想象的更频繁：用户可能认为是在沙盒中测试了决策逻辑变化后的表现，而实际上可能这次操作是在生产环境中进行的。
同时，你还希望决策具有完整的可追溯性，以及在任何时间点的完全可见性，即当你要审查一个决策时，你能够清楚知道产生决策那一刻的决策逻辑的所有相关信息。
组成决策逻辑的元素都应该是版本的一部分：流程、规则、预测模型和查询模型等。如果你的决策逻辑还包括决策管理系统未管理的资源，那么就有可能遇到项目执行问题和资源可追溯性问题。在此，我们建议在决策管理系统内管理所有决策逻辑相关资源。
只使用能帮助你进行版本管理的决策管理系统，并且始终只部署发布成版本的决策。
确保决策应用符合技术环境要求
现在你已经拥有将发布在生产环境的决策版本，但仍需要考虑其它一些因素。
通常，你将遇到以下一种或多种情况：
· 决策应用以SaaS形式提供，并以REST或类似协议形式被调用（松耦合）
· 整个环境是消息或事件驱动的（松耦合）
· 其主要依赖于微服务，使用IT编排工具和松耦合调用机制
· 决策应用需要在API级别的一个（或多个）应用组件之间紧耦合
你的决策应用需要能简单地适应上述架构需求，并且不对整体架构产生大影响。
另外还需要注意组织和应用的发展。我们已经发现许多客户在多个不同的环境中部署相同的决策应用，通常是交互式和批处理的方式。这就要求决策管理系统能够以低成本的方式实现多环境部署。
必须考虑可用性和可扩展性需求
在松耦合的环境中，决策应用服务或微服务需要满足高可用和可扩展等需求。通常，这意味需要以下列方式配置微服务：
· 避免出现单点故障
· 有复制的备用存储库
· 有多个实例可供调用
· 灵活地扩大或缩小应用规模
理想情况下，你使用的决策管理系统支持开箱即用。
必须考虑安全性需求
你的决策应用需要受到保护。这包括
· 防止对生产环境中的决策应用进行未授权访问（MIM攻击等）
· 防止对生产环境中的决策应用使用的组件（通常指存储库）进行未授权访问
在给定技术环境和相应要求的情况下，确保以最合适的方式部署决策应用。理想情况下，决策管理系统可以提供强有力的支持。
你需要弄清楚代码在生产环境中是如何调用决策应用的。通常，你会以如下方式调用决策：
· 为每个“交易”分别发起调用（交互式）
· 为一组“交易”发起调用（批处理）
· 为“交易”流发起调用（流处理或批处理）
基于场景选择合适的调用机制对决策应用的性能表现有重大影响。
根据业务需求管理生产环境中决策应用的更新
决策管理系统的一个关键价值在于业务分析师可以直接实施、测试和优化决策逻辑。
理想情况下，这会扩展到将决策更新部署至生产环境中。随着业务分析师对决策进行更新、测试和优化，他们也会要求其被“立即”部署。
传统决策管理系统需要经历IT各阶段、代码转换、代码生成和上传。这种方式下，你会遇到上线慢和潜在的其它问题。 SMARTS明策决策引擎等现代的决策管理系统为决策的快速部署提供了有力支持。
在处理决策逻辑的新旧版本时，需要考虑一些关键因素：
· 决策逻辑的更新应该是一键式操作，以及通过单个API调用完成更新
· 更新应该是安全的（如果新版本效果无法令人满意，就不应该部署至生产环境中或至少应该很容易进行版本回滚）
· 系统应允许同时运行新旧版本的决策
当然，仍然有些情况是需要在业务需求和IT约束之间取得适当平衡的。
例如，每天所有的决策逻辑变更可能合在一起，在一次部署中完成，因为它们需要与其它以IT为中心的系统变更相协调。
确保在合理平衡的情况下能够尽可能高效地更新生产环境中的决策，以满足业务需求。
在生产环境中跟踪决策的业务绩效表现
按照上述指导将你的决策以版本的形式部署至生产环境后，仍需要对其业务绩效表现进行监控。
SMARTS决策引擎等决策管理系统可让你在将决策部署至生产环境之前对其业绩表现进行刻画、分析和优化。将决策部署至生产后，继续进行相同的分析是非常重要的。条件可能会改变。虽然你的决策在首次部署时有效，但在条件发生变更后可能不再有效。通过在生产环境中跟踪决策的绩效表现，你可以更早地发现这种情况，分析原因并调整决策。
在本系列的后续文章中，我们将更多地讨论如何处理决策执行的性能问题。
