陈泽昊，微众银行存款核心系统运维负责人。2016年入职腾讯，主要负责腾讯地图相关业务运维工作；2018年加入微众银行，担任资深业务运维工程师，作为银行存款核心系统运维负责人，主要负责核心系统的运营规划，以及智能化运维在核心系统中的实践和推进工作。

微众银行的分布式架构融合了分布式的松耦合架构和一主两从节点的强同步架构，为什么我们会选择这两个架构？

我们先来看一下分布式的松耦合架构。在分布式架构兴起之前，中国银行业主流的技术架构是集中式的松耦合架构，它的优点是一定程度上分散了风险，提高了资源利用率。但是银行业务的复杂性使得银行业务的系统呈现出一种高度的相互依赖性，很多客户的服务请求是一个从端到端的完整的链路请求，它往往需要多个银行业务系统之间进行配合。

举一个例子，我从银行的APP发起转账转出去，可能会经过一个APP的子系统，到一个存款的系统，需要扣减余额，再到一个汇款的系统，然后可能要通过超网等银行之间的渠道出去，那么在这当中只要有一个子系统出现了故障，可能就会对其上下游的系统产生影响，从而对银行整体可用性和稳定性产生较大的影响。

因此我们在中间做了一个横向的切分，就形成了一个分布式松耦合的部署架构，使一个节点成为一个客户的服务节点，该客户的全生命周期数据都集中在一个节点上，涉及单一客户的交易处理也在同一个节点上完成。也就是说，一个客户只会存在于一个节点之中，从开户到做金融交易再到销户，所有请求都会在单节点中产生，所以节点与节点之间是相互隔离的，没有依赖性，如客群一故障并不会影响到客群二和客群三。分布式松耦合架构既保证了我们整体架构的稳定性，同时通过节点数量提升了我们架构的性能。

金融机构对于数据的质量是有要求的，我们主要是通过一主两从节点强同步架构来保证数据一致性。

最开始我们考虑到互联网的架构是分布式的多主节点架构，这套架构的好处是高弹性、高可用和低成本，但是分布式多主节点架构无法同时满足CAP，也就是说我们的服务在某些场景下可能会是有损的，但是金融行业其实有一定的要求，金融机构在金融服务场景下无法接受有损的服务，从而引出我们的一主两从节点强同步架构。我们通过数据副本保证可用性，同时数据和主节点是强同步的，那么就实现了整体数据的高可用。

融合分布式松耦合架构和一主两从节点强同步架构，最终就成为了微众银行的IT架构模式。在应用层面采用松耦合的部署模式，即不同应用域之间的系统不共享物理资源，则能保证其高可用性，同时通过强同步的模式保证数据的一致性，最终该IT架构降低了对于系统单实例的性能要求，也就是降低了研发的门槛，但是因为架构比较复杂，所以对于运维管理而言要求相对较高，需要有一套高度自动化的运维体系支撑整个IT系统的稳定运行。

这里补充一点就是我们的客群，在行内称作DCN，即数据中心节点，是我们用来管理架构的一个最小单元，后面可能会提及DCN的概念。

接下来介绍一下我们的自动化运维过程，以及我们遇到的一些问题和我们的解决思路。自动化运维即DevOps其实是我们做AIOps和智能化的必经之路，里面很多沉淀出来的东西对于智能化有很多借鉴意义。

先看一下我们在自动化运维里遇到的最大的挑战是什么。

1）银行业务增长量超过了人力的增长

意味着运维在保证日常工作正常开展的同时，还要去做自动化运维的一些建设，相当于一个人要当成两个人用。

2）多业务场景，业务架构差异

微众银行虽然只有7年多的历史，但是随着银行规模的扩大，它的业务发展非常快速，银行业务有对私和对公、也有存款业务和贷款业务，不同的业务场景会导致我们的业务架构产生不同的差异，需要自动化做不同的适配。

3）需求迭代非常频繁和快速

我们基本上是两个星期一个版本，所以需要运维快速地响应。

4）金融机构一般都会有来自审计的要求

所有的操作不管是自动化还是人工，都需要能够被审计溯源。

针对以上挑战，我们的策略如下：

1）流程化＋标准化的建立

通过运维流程和标准建立运维文档，打通运维工具，对运维工具进行标准化的管理，将运维流程和事件关联起来。

2）工具全链路打通

例如打通CMDB与监控平台等数据平台，保证数据的闭环和管理。

3）运维数据可视化

运维数据可视化之后可以做一些数据化的运营，例如一些服务、规划，成本的核算，以及支持业务场景的分析等。

我们在做到自动化之后也会有一些比较大的挑战，可能通过自动化是无法实现的。

1）及时性

金融系统对于稳定性是有要求的，关键交易必须达到无损，所以快速发现异常并解决异常非常重要。

2）准确率

银行的业务场景相对比较复杂，除了我们自身的一些自研业务之外，传统银行可能会有很多外购的机器，包括银行间对接、银行与民间各种服务器对接，可能是必须要外购的，这种多业务场景带来的不确定因素，会给自动化运维的覆盖带来一定的困难。

3）规模带来的挑战

规模发展非常快，积累了海量数据，自动化运维在这个过程中相对会比较吃力。

针对以上几点挑战，以及近几年AI技术发展得非常快，微众银行的智能化运维应运而生。

为什么要做智能化？其实智能化特别适合这种大规模且复杂的场景。我们总结出来智能化有两个前提，分别是数据和自动化，而数据和自动化也是我们在自动化建设过程中就已经有所准备的。

我们在智能化运维中划分了4个领域，不同的领域制定了不同的运营策略。

通过建立数据生命周期管理，自动化流程驱动数据更新，以及打通多个运维工具，促进数据的消费以提供数据的流动性，同时以应用为中心，建立智能化的运维体系，从应用的角度规划各种运维场景，例如可以收集CM DB的一些语言定义数据，相当于识别信息，与我们的监控平台IMS的一些动态数据整合起来，再叠加一些AI算法，生成我们的智能应用画像，智能应用画像可以提供给我们的容器调度平台等资源调度平台使用，从而达到动态的扩缩容或智能编排的效果。

另外，我们目前支持应用属性、监控数据、运维属性、依赖关系的一些数据的聚合，从而达到数据闭环的管理以实现智能化。

1）异常检测

监控领域的最初目标是通过异常事件，我们能够自动地发检测、预测和告警，以此摆脱根据人工经验定义故障阈值的场景，因为通过人工经验定义阈值往往容易漏告和误告，而且当阈值需要调优时，可能会有反复的操作，非常影响运维的效率，所以我们希望通过智能化实现异常检测，并且在有些情况下，我们可能没有配置故障阈值和告警阈值，那么就需要做到无阈值曲线的异常检测。

在这个过程中，我们有一个原则是少见即异常，将检测异常转化为另一个问题，就是衡量当前情况是否少见，如果这个情况少见则可能它已经发生了异常，或者至少它应该是我们运维需要关注的一个地方。

在方法上我们规划了智能监控系统识图模块，我们内部称为“慧识图”，慧识图算法是针对业务四大黄金指标而制定的检测策略，业务四大黄金指标指的是交易量、业务成功率、系统成功率和平均时延，这些数据都是分钟级的。往往我们的业务出现故障时，最终都会在这些业务指标上有所体现，因此我们只要能够准确捕捉到这些指标的异常，就能够快速发现影响业务的异常。这四个指标的统计维度、波动规律是有所差别的，所以我们需要用不同的算法进行检测，主要是采用三种算法：

我们做到前面这些异常检测之后，包括曲线也能预测出来，那么我们其实具备了主动预测异常的能力。还有一点就是低频交易，因为银行有一些交易其实是来自于人工发起，比如一些柜面的操作，或者司法机关有一些冻结的请求，这种交易往往是比较低频的。针对低频交易，我们用的是滑动窗口的方式，因为我们的监控数据本来是分钟级的，如果低频度的交易比较多，可能在监控曲线上会有掉点、断续的情况出现，给我们的检测带来比较大的偏差，可能会导致检测结果不准确。通过滑动窗口的方式聚合某段时间内的监控数据，将其形成一条连贯的曲线，最终就能提升检测的准确率。

2）根因分析

在监控异常之后，如何快速地恢复异常也非常重要。因为对于运维而言，保证系统百分百的可用是不太可能的，我们只有尽可能减少故障影响时间，让可用率无限接近百分百。

除了在我们日常运维过程中惯用的手段，比如快速隔离异常、做一些扩容操作、回退变更操作等，在异常发生的时候如果我们能够快速知道异常的根因，其实可以为我们异常恢复争取更多宝贵的时间。

最开始微众银行做根因分析采用的是专家系统的方式，专家系统的数据并不透明，意味着每一次做根因分析之后，我们还需要检视分析结果是否正确，每天大量异常事件如果都需要运维做检视会非常影响效率，而且专家系统规则维护非常困难和复杂。

后来我们引用了图数据库，将异常事件以知识图谱的方式存储到图数据库里，因为我们存储到数据库所以意味着我们要做数据多维度的采集，比如异常事件的相关信息，异常事件的开始时间、结束时间和影响时间，以及业务的一些关键指标，包括前面提及的业务四大黄金指标，交易量、业务成功率、系统成功率、平均时延等，还有一些流水信息和流水日志等。

那么我们将根因定位划分为两个维度，分别是横向维度和纵向维度。横向维度是指对从入口子系统开始到后端所有交易链路上各个子系统进行横向的调度分析，纵向维度是指对应用层支撑子系统的所有逻辑层、物理层，包括DB、网络、主机等做纵向的分析。微众银行大部分子系统是通过统一的消息总线进行交互的，通过消息日志能够自动地进行横向的分析，即使有些子系统可能无法做到像消息日志一样自动分析，其实它在CMDB里也是有数据的，通过CMDB里记录的一些CI的关系信息，我们也能够进行相关的调用分析。

前面的数据其实就是一棵交易树的叶子节点，纵向与横向分析出来的一些链路就是交易树的枝干，那么基于交易树，我们能够快速定位异常事件的根因。

另外，我们通过在事件指纹库里比对历史的异常事件，也能提高我们根因分析的准确率。事件指纹库是一个异常事件的博物馆，记录了我们历史中所有的异常事件。一个完整的比对过程包括异常事件的指纹选取，指纹选取其实就是多维度数据的采集，以及异常事件在知识图谱里的更新和存储，最后我们会根据指纹权重做一些匹配的算法。我们还有人工标记的方式，也就是说我们会定期进行复盘，解释根因分析是否正确，同时也会在上面加一些优化处理的事项的标记，那么整个监控从异常检测到根因分析再到异常优化，就形成了一个闭环处理。

1）质量

在变更领域，我们是通过建立SOP和准生产环境验证来保证变更质量。

建立SOP标准作业流程，其实是我们在前面自动化运维过程中已经沉淀出来的一些运维的标准作业流程整理归类为文档。

金融机构对于数据治理有一定的要求和规范，数据天然存在一种物理隔离，就是生产环境的数据是不能出到测试环境，所以通过测试环境做验证很难达到案例的百分百覆盖。而且在生产环境做一些主动拨测相对较为困难，因为金融系统有审计、监管上报等功能，作假比例操作也是会被审计的，所以无法做到主动的拨测和验证。那么我们通过准生产环境模拟生产环境的全量数据，以此达到上线前变更的验证检查。

2）效率

我们前面已经在资源管理领域和监控领域实现了一定的智能化，因此我们可以通过标准作业的编排实现自动化的发布操作，以及在自动化发布之后，可以实现自动化的验证，最终实现无人值守变更。我们的无人值守率目前达到了55%，对于整体运维的效率能够提升30%。

1）效率

在规模领域，我们实现了一键扩容DCN，也就是一键扩容我们的数据中心节点。银行系统如果停服，对用户企业的影响是比较大的，尤其是微众银行的服务基本都是在线上，所以在不停服的情况下，我们目前扩容一组DCN只需要一个工作日，整体架构能够支撑的单日金融交易峰值是7.98亿笔。

2）质量

在质量方面，我们更关注的也是一些数据的质量，因为随着规模的发展，我们会对接很多海量数据，而金融机构对数据是有审计要求的，所以我们通过上下游系统的对账以及AI算法的识别来保证应用数据的一致性。

最终微众银行的智能化运维体系就分为了资源管理、监控、变更和规模4个模块，资源管理领域和监控领域服务于上层的变更领域和规模领域。

1）通过智能化提升异常检测的准确性和有效性，包括在异常检测方面、根因定位方面，以及我们刚刚提到的数据一致性的数据质量的准确识别。

2）通过提升无人值守的覆盖度，保证无人作业的有效性情况下，进一步提升运维的效率，以此降低IT成本。

以上就是我们对未来的展望。