TGES前沿讲座2022年第三十七期

数字化转型框架与实践暨金融科技应用、IT风险管理

 

风险管理的云解决方案

王轶男  SS&C技术控股公司Algorithmics美洲区支持和云服务测试负责人

今天的分享主题包括三个方面：一是为什么选择云服务；二是风险管理的云服务方案；三是云服务的支持。

一、为什么选择云服务

云服务实际上属于公司战略，需要很多不同部门的配合。

（一）云服务的整体趋势

这里只是从一个业务人员的角度来看云服务的趋势，IT方面对为什么选择云服务已经有了很多论述，这里就不赘述了。

在我现在负责的美洲区支持，我发现云服务是一个整体趋势，因应金融行业的客户需求：尤其是美国客户，我们90%的美国客户已经都转移到了云服务上，或是正在转移中，即我们正在替他们做系统的升级和迁移；加拿大也已经开始有很多这样的客户咨询。

实际上，很多银行已经有不少业务使用云服务，风险管理的趋势也是逐步走向云服务。稍微滞后一点的地区，像墨西哥、巴西等南美客户也在咨询。据我了解，有一些其他厂商好像都已经只提供云服务了。

（二）为什么选择云服务

为什么选择云服务？

1.从业务角度看，实际上我们是为了提高系统部署的效率。

我在国内负责项目实施的时候，有的客户其实就已经问过我们：是否支持把这些系统安装到他们内部的云上？

实际上，我们这里真正谈的云服务并不是这种简单的lift和shift的做法。而是对整个系统产品有要求。如产品要支持容器化（包括每一个组件的容器化），一些自动化部署。

举一个很简单的例子：以前做项目实施的时候，部署软件可能只是安装软件这一环节，即安装联调，不包括接客户的数据，也许就需要一周的时间。如果做云服务，只是把软件装上去，有可能一天就够了，因为所有东西都容器化了，只要以自动化部署的形式部署上去就可以。

2.从整体管理的角度看，云服务可以提高支持的效率，解决一些支持的难点。

国内有很多现场支持要求，因为其中有一些问题并不是现场人员能够解决的。比如，需要一些远程的研发方向的介入，会涉及一些日志，包括很多其他文件，如数据文件的传送，等等。

如果客户不是云服务，每次涉及到这种传送，都会有一些磕磕绊绊。因为我们看不到系统，只能依靠文件，尤其是远程的人只能根据传送的文件分析问题。如果是云服务的话，就不存在这种情况，系统对服务人员的可视性高。

还有一点，我个人体会比较深。我们风险管理软件属于应用软件，它是建立在很多底层软件上的，包括数据库、操作系统，等等。系统在运行中需要多责任方的协调。比如，出了一个问题，这个问题是应用层面的，或是数据层面的，还是操作系统、数据库的？有80%的情况是比较清楚的，但剩下20%的情况则比较灰色地带。如果用了云服务，至少云服务就是一个责任方。不管什么问题，都是服务方去看就好。

我们美洲区客户做的云服务在解决速度上是有要求的，也就是说某一个问题要求在多长时间内有response，多长时间解决。比如，系统能够给客户用的时间，这都是有比例要求的，也是用来督促云服务的服务方提高服务的效率。

 

二、风险管理的云服务方案

（一）风险管理的云服务方案·类别

一是订阅类，可以想象成报纸杂志那种“订阅类”；二是平台类，可以想象成一个标准化平台，但客户有一些自己的需求；三是客制化系统。这三种类型的区别在于它能提供什么样的服务。

1、订阅类，负责提供自己的内容，客户看即可。

当然，也有以下特殊的类型：

（1）提供一种API做定价，也就是说你可以使用自己的数据。

比如，你有产品需要定价，可以把需要的关键字段上传，然后用服务来恢复价格。它的定价模式已经固化，是不能改变的。

（2）提供一些情景服务。

比如，疫情下需要使用什么样的情景，或者还有什么可以使用的压力情景。我们在系统的后台做了历史数据的模型，呈现给客户的是一些已经做好的情景。当然，情景所涉及的风险因子也都是固定好的常用的风险类型、常用的币种、常用的指数之类的情景。

（3）一些标准化的报告等等。

这个类型的服务是完全标准化的。从运维的角度来看也非常简单，因为后台生成了，客户只是订阅了看，或是输入数据得到结果等。

2、平台类，客户提供自己的数据和选择，平台负责配置和运行。

这个在市场风险管理系统使用得比较多，即已经有了一套从数据处理到建模到运算和结果的平台。在银行提供了数据以后，只需要对平台的配置按照客户要求做一些简单调整，就可以运行批处理，直到最后运行出报告。客户也可以在平台上直接做一些交互式的报表功能。

所以，平台类型涉及到一些简单的项目实施，也要了解一些客户的需求，比如初始需要看什么报告，在实施的时候就可以把这个报告给你定制出来；又比如各种可选模型，可以按照客户偏好做客制化调整。

平台类型可以理解为大体的批次或是整体结构是标准的、平台化的，但在一些具体的模型、数据等方面，客户可以提出自己的需求，做客制化调整。

3、纯客制化系统，其实可以理解为给客户定制一套他自己要的系统。

比如，信贷的授权流程要根据不同的客户需求定制，我们也支持此类型的云服务方案，在整体云平台架构上替客户定制他自己要的系统。当然，这就涉及到了全量实施。所以，这个类型的实施周期会比平台类型偏长一点，因为毕竟很多东西都需要客制化。

在这一方面，在风险管理领域比较常用的，除了信贷相关的系统，如我们在加拿大的客户就使用了信贷的限额管控系统，全球不同地区的用户都在使用云服务界面进行管理；还有交易对手的信用风险管理系统，资产负债管理系统，这些系统的客制化要求都比较高。

 

（二）风险管理的云服务方案·管理

客户采用云服务方案实际上相当于把所有的东西都交给服务方。所以，从管理的角度看，我们需要考虑的事情非常多，这里简单地讨论一下涉及到的主要的大类型。

首先是基础设施，涉及到所有数据中心的建设。这个就不再赘述了。

其次是合规和安全，尤其是对一个云服务方案供应商来讲。因为每个做云服务方案的客户都有合规和安全的需要，这更是监管的需要。一般来讲，需要有合规经理，因为不同的国家或地区都有不同的法律和标准的要求。另外北美的云服务都有很严格的第三方的审计，客户也会要求很多测试报告。所以，我们可能每季度都会有一些内部审计和外部审计的需求。

第三是测试，这实际上是我负责得比较多的一件事。测试可以分成不同时段、不同阶段。毕竟做风险管理的云服务方案会有不同的阶段，尤其是平台类型和客制化类型都涉及到一些系统搭建，只是时间长短不同而已，但基本测试的要素都是很必要的。而且，测试也是第三方审计要看的很重要的一环。

测试对云服务的支持也是一个很重要的因素。比如，系统搭建的时候涉及到不同阶段的测试，系统上线和转运维的时候也一样，我们在这里提出了一个新的测试，即运维的接收测试。我们要测试一下整体系统的监测，包括monitor系统运行的各方面。我们自己内部大概有几十条需要测试的内容，也会一直在云服务方案里做这样的测试。另外还有一些灾备切换的测试，基本上既是监管的要求，也是客户的要求。最后作为一种风险管理系统，一定会不停地有补丁升级，等等。每次做补丁或升级时，我们需要做一些 regression testing来保证结果的连续性和稳定性。这是一部分很重要的测试。

还有一些管理，包括环境管理、监控和预警，以及变更管理。

在环境管理体系中，最重要的是权限和职责，即什么样的人在生产上有什么样的权限，这些都是审计的时候很看重的。监控和预警对云服务来说很重要，即如何在系统实施以后的运行过程中提前识别风险而不影响客户。这就涉及到根据不同的方案设计不同的监控和预警方案。在不同的风险管理方案里，我们也可以用一些平台，以及现有的自动化工具来做信息的发送和预警的处理。变更管理的流程包括变更的递交、风险评估批准等，涉及到不同的人员和角色。审计非常注重管理流程，因为毕竟生产环境上的任何一点细小的改变都会涉及到整体的变更流程。在具体实施时，我们会需要定期开会，查核需要变更的事项。再沟通清楚到底有没有完整地测试过，能不能审批，能不能在安排的时间进行deploy。所有这一切都要记录下来，有据可查。

 

三、云服务的支持。

从实操的角度来看，云服务的支持说容易好像容易，但说难实际上也挺难。

（一）7×24服务和人员安排

1、各个时区的轮转机制

作为一个云服务方案，尤其像我们的客户分布在不同的时区，我们需要提供7×24的服务，也需要相应的人员安排，即时区的轮转机制。

2、标准化的文档和常见问题的解决方案

云服务对文档的要求，因为时区的轮转机制，需要被重视。因为一个问题可能会有不同的人在看。如何把文档制作得标准化，让人容易查阅，包括一些常见问题的解决的方案。实际上，这些文档不光是对支持人员重要，对项目实施的人其实也是非常重要的。它是一个重要的沟通工具，可能站在支持的角度，在同时面对很多客户和各种可能的问题时，会有更多体会。

3、复杂问题的逐级上报

我们做云服务的时候，所做的风险管理的方案可能有很多种，有的并不是一线人员一定可以解决。这时就涉及到如果他解决不了，应该怎么找其他人来解决。所以，从支持的角度来讲，整个云服务涉及到一个大的solution group。即如果一线解决不了，谁是二线、在哪些问题上他是二线，在哪些问题上二线又是另外的人。

所以，我们要把逐级的人员定义清楚，职责也要定义清楚——哪些问题分别由哪些人来做。为了提高响应的效率，这些人员和职责必须提前拟定。

（二）定期的维护和升级

这一部分包括两种：

一是基础软硬件的维护，如数据中心可能会有定期的maintenance outrage，需要调整自己的系统、通知客户。二是应用系统的补丁和升级管理，如前面提到的一些测试，后续如何自动地deploy，产品怎么系统自动化地去部署补丁和升级，等等。这都是我们正在研究或是正在推进的工作。

（三）定期的灾备演练

灾备演练涉及到不同的数据中心，所以它需要的协作就会更多一点。比如，作为云服务的服务方来讲，我们需要定期的灾备演练。灾备演练的流程需要考虑不同的事情，包括系统切换，团队协作、客户通知等。

总体来说，云服务涉及到很多不同的部门、流程和policy，所以，有很多的细节需要厘清，对公司组织和文化都可能带来不小的调整。

 

发言文稿整理：胡慧

责任编辑：傅泽天

来源：TGES前沿讲座2022年第三十七期：数字化转型框架与实践暨金融科技应用、IT风险管理