新技术发展背景下的业务连续性保障新模式

业务连续性保障，可以分为可用性保障和资金风险防控两个大方面。可用性主要手段就是灾备、灰度等，资金风险目前主要的防控手段就是核对。从二十年前淘宝双十一开始到现在，似乎没有啥特别的变化。但是，随着容器技术、大数据技术、AI 人工智能的发展，业务连续性保障这项「古老」的工作，也应该焕发出自己的新模式新常态。

一般的业务连续性保障工作，除了上述的可用性和资金安全两方面外，还有日常的攻防演练。我们从这三个方面看一下新技术可以给我们带来什么样的新模式。

首先是稳定性。一个应用系统集群的稳定，我们主要从计算、网络和存储资源三个方向上去保障。

计算资源，包括应用服务器、数据库服务器和大数据的计算集群。由于这些资源大概率是无状态的，所谓 serverless，要保证这些资源的稳定，相对来说比较简单，就是需要对有问题的节点进行及时的发现和修复就可以了。传统的单机或者虚拟机模式下，资源相对来说还是比较金贵的，要重新申请资源的周期也比较长。我们需要区分不同故障，到底是应用层问题还是操作系统层问题还是硬件问题，采用包括重启、重新部署（安装）、替换等不同的方式进行解决。但是，在容器化的背景下，这些前提就有了一定的变化：资源相对来说比较容易获取，重新申请资源也变得非常迅速。所以，在当前的容器化时代，对于计算资源的可用性保障，可以采用比较粗暴的方式，如果整体集群的容量尚有富余，我们可以采用快速隔离有问题节点（切流），同时对有问题节点进行替换处理的方式，实现秒级的恢复。如果整体集群处于比较大的压力，就不能断然的切流，需要采用（限流）-扩容-切流-缩容的方式，完成对问题节点的替换，实现分钟级的恢复。上面说的都是实时的计算资源，对于离线的计算资源，处理起来就更简单了，只需要从集群中剔除然后做替换处理就可以了。总之，在容器时代，我们对待虚拟机，不应该再像对待宠物一样，要关心爱护和修复，而是应该像对待牲口一样，能用用不能用就换。同时，为了提升替换的效率，一个微服务的规模不应该做的非常巨大，应该到足够小，可以支持快速的拉起。

网络资源，包括带宽和网络地址等。对于外部带宽和对外的域名，这部分受到外部资源的限制，我们可以采用备份的方式进行处理，不在本文的讨论范围内。对于内部的带宽和域名，在网络虚拟化和网格 sidecar 的背景下，也可以采用快速隔离替换和扩容的方式，实现秒级的恢复。

对于存储资源，相对来说会复杂一些。由于存储资源是一个有状态的资源，不可能采用快速替换的方式来解决。对于在线和离线的业务数据存储，例如关系型数据库、非关系数据库、数据仓库等，可以考虑多副本的方式，不要将数据放在一个篮子里。通过将数据存储在多个副本里面，在故障的情况下，可以考虑副本整体替换的方式，进行恢复。这里就需要考虑到副本异地存储的问题。需要在同机房、跨机房、跨城市分别进行数据的多副本备份。对于不同的故障等级，支持不同的 RTO。比如同机房 RTO=0，跨机房秒级，跨城市分钟等。其实大家去考虑各种故障发生的概率，以及我们自身业务对于不可用时常的容忍度，分钟级别对于大部分的场景基本大家也都是无感对吧。同时考虑到机房级别故障时小概率事件，我们大部分要应对的还是存储介质级别甚至时应用级别的故障，所以同样需要采用微服务的方式，将不同服务的数据分别存储，从而进一步提升切换效率。

上面说了稳定性保障，下面说一下资金安全的保障。

资金安全，对于金融类的应用会比较关键，对于一些信息类的应用大概率不涉及。

对于资金安全，现有的防控手段无非就是业务的对账、模型的核对、基于规则的指标分析等。无论怎么做，所谓百密一疏，用线织成的网，再怎么密密缝，也总归有孔洞。所以各大金融机构，时不时还会有各种瓜瓜爆出来，不是重复退了款，就是金额注了水。有了大数据的支撑，以及实时计算能力和 AI 能力的不断发展，我们可以考虑交叉演算和智能探测两个新的资金风险防控的手段。

交叉演算的思路，其实和我们上学的时候验算的逻辑是一样的。我们基于如下的理念：人写的东西总是会有 bug；同一票人用同一个思路写的核对，大概率和被核对逻辑也会有同质化的问题。所以，对于关键的资金处理逻辑，基于避免同质化的前提，可以搭建另一套业务处理逻辑进行验算，或者构建异构的数据核对逻辑进行检查，从而为保障资金处理的一致性，加上多层的防护膜。

所谓的另一套业务处理逻辑，举个例子，我们对于外汇金额的计算，如果线上的业务逻辑是采用买卖币种加汇率的逻辑，那可以构建一套旁路的交易币种对手币种加买卖方向的逻辑进行双重核算。

所谓的异构的数据核对逻辑，就是在关键的业务节点，例如网关的入口，和机构交互的出口，和其他系统的 RPC 调用点等，对关键数据进行镜像，然后通过溯源或者演绎的方式，找到上下游相应的模型，进行端到端模型一致性的匹配。

智能探测的思路，是人工智能的一种应用。我们基于正常的业务逻辑对于系统的影响总是有正常的规律可循这个前提，通过对于系统指标的异常探测，间接发现业务处理的异常。例如我们可以采集交易量、资金流出量、内部资金留存量、内部损益等指标，通过对于不同交易场景的学习，总计和积累相应的场景指标数据库。对于异常的交易，就可以快速通过这些业务指标的异常反映出来。

最后说一下演练。所谓养兵千日用兵一时，没有日常实战化的演练，所有的应急操作和风险管理都是画在纸上的老虎，没有任何的用处。要练，就要天天练。要练，就要动真格就要真见血。要模拟真实的场景，我们需要解决场景定义和场景复原两个问题。

最真实的演练场景，就是线上的真实交易数据。线下模拟的交易，从来就不会覆盖所有的异常场景。所以我们可以采用线上交易镜像回放的方式，积累演练的场景数据。

对于场景复原，线下搭建的测试环境，不管怎么样都会和线上的环境有这样那样的差异。容器技术给我们带来了快速灵活的网络计算和存储资源虚拟化的路径，那么我们为什么不可以考虑直接在线上演练呢。线上演练有两种模式：一种是「子战场」模式，在线上环境隔离出一块单独的资源，进行场景的回放和演练。另外一种是「身临其境」模式，通过测试用户白名单，将问题交易真实的注入到线上环境。这两种模式只是针对蓝军的不同，对于被演练的对象红军，看到的就是线上出故障需要应对，从而达到了实战演练的结果。