干货平安银行：自动化运维及中台建设之路

Posted 2021-05-01 金融时代网

 

作者简介

徐大蔚，平安银行科技运营中心，运维架构师、工具开发组经理

今天给大家分享的主题是自动化运维实践和中台建设，这涉及到两个，一个是自动化的运维，还有一个就是中台。说是中台有一点夸张，这不是一个很大的中台，我们在自动化建设过程中隐约发现这个东西慢慢的形成了中台的位置，可以给上游的场景提供一系列的服务能力。

首先介绍一下我自己，我来自平安银行，在平安银行担任工具开发组经理，负责我们所有工具的开发。平安银行现在组织架构，工具开发组只是众多开发链上小小的一块，为什么？因为整个平安银行每一个部门都有开发能力，一会我会讲到我们如何协同各个部门开发力量来打造平安的工具体系。

今天按照这个线路来讲，给大家看看平安银行从转型到现在所应对的挑战。平安银行的互联网转型启动以后，来自互联网各行各业的同事也纷纷加入平安银行，在一年半到两年的时间内，我们发现了一些问题和挑战，做出了哪些解决方案以及我们如何应对它的。

1. 银行转型

其实，做工具不难。但是要做成适合的工具是非常难，特别是在银行这种体系下。因为你面对的不是一个初创公司，把所有东西推倒重建；在银行里面没有办法，它的架构太大了，它像一艘巨轮，无法让它马上调头或是往另外一个方向行驶。我们需要一片一片小舟去探索不同的方向，方向不错就落地，然后引着让大船去走。

平安银行团队2018年也在 GOPS 上分享过，那个时候是晓强总。他带来的分享是SWAT的运维理念，那个时候我们定了一个运维理念和基调，就是SWAT。SWAT的定义就是要快速响应，快速反馈，强大装备支撑的团队应对银行运维的故障和突发情况，我们延续 SWAT这个理念看看我们这一条路上做了什么。

银行的背景，这里简单说一下，我们要知道面临的是什么问题，在银行转型的过程中，转型意味着改革，改革有各种各样的，拆微服务、上容器，服务器数量业务增长，并发请求数、流量增长，这个时候对基础架构、对运维来说是服务器的数量爆发式增长。到目前为止在平安云在生产环境里面跑了4.7万台的实例， 不是很大，但在这一年当中也是猛增上来。

随着业务的要求越来越高，业务说今天要200台机器，明天要，没有商量。我们做不到，怎么办？之前在一个吐槽大会说孙悟空和唐僧取经的故事，说今天你要200台机器，我做不到，怎么办？他就和领导说，他说他不做，不交给我200台，我们很尴尬，我是能力问题做不到，业务就是从上往下压。交付时效就面临挑战，我们时时刻刻被碾压。

大量的新项目的上线，意味着架构的变化，包括技术栈，技术组件，以前银行使用的中间件通常是weblogic，现在转换成Tomcat。银行用的一些东西都变成了一些轻量级的东西，但是我们银行以往的工程师没有这个概念，传统银行就是填人，没有人就找外包，外包的技术储备和技术能力的发展是无法留存到银行里面去，在这种情况下我们怎么办？做工具，把经验变成工具，用工具推动自适应的发展。

2. 识别问题

当时我们发现了几个问题，大致分成五大类。这也是初创公司或小规模公司基本上都有的情况。

第一是自动化覆盖率很低，我们知道自动化覆盖率不是一块一块的，我创建一台主机自动化，装一个软件包自动化，上一个版本自动化，这些不是自动化率的覆盖。自动化率覆盖是整个链路的覆盖，如果有一个环节没有覆盖到，这个链路就有可能产生一些风险和故障，特别是在服务器交付量特大，请求数越大这个问题会扩大，扩大了之后就无法控制了。

这个是我们银行当时出现问题，因为有的有，有的没有，有的要人工做，邮件飞来飞去，可能漏了，业务上线前一天说服务器为什么没有到，怎么办？加班。

第二个是配置信息不透明，不闭环。

什么是不透明？我们都是 EXCEL互相飞来飞去，我一个EXCEL，他一个EXCEL，如果三方需要部门总体数据，怎么办？两个 EXCEL合一下，谁知道这个有没有漏或有没有重复的？可能都是重复的，这个就没法做事了。

第三就是标准化的不到位，我第一个讲到了，这个标准化不是每一条链路带到。

第四是流程监控复杂，银行需要对银监会报备，所有的变更操作，包括一些切换，属于核心的东西均要报备银监会，导致流程管控非常复杂。银行的体系里面一定需要有变更的记录，所有的变更要有变更记录。针对这个变更记录我们下面可以申请权限，通过权限登录到服务器上面。

有人说为什么不用 Ansible，为什么不用 Saltstack？不是不可以，因为 Ansible 和 Saltstack 是在安全上面会有一点问题，这个没有办法让一个人拥有限制他的权限，一个人访问一台机器用 Ansible 不可能，Ansible 可以查到所有，我们就要做管控了。

最后一个就是自主工具的能力差，主要是体现在外购，各种外购产品。给我们带来最大的问题就是迭代，需求迭代落地时间不能控制。

3. 献计献策

在这种情况下，我们针对各个环节，比如说覆盖了这五个环节，我们打造了很多的工具体系，但是今天我们时间非常有限，我无法一个一个工具来讲，这里列出四大块，主要是讲一下我们是如何在这样环境下解决数据闭环、自动化、流程管控，这三个东西结合在一起打造出来一个工具。

我们讲到CMDB，刚刚赵班长讲到了，CMDB 是一个潮流，它可以被企业忽略吗？不可以，不管是 AIOps 还是 DevOps，这两个的基石就是 CMDB，如果 CMDB 没有准确而闭环的数据，没有关联输出，AIOps 和 DevOps 做不到场景级的运用。

举一个例子，今天张三和李四要出去买一样东西，他们说我买这个，你买那个，他们到超市发现一个问题，我买账篷的时候，我要考虑到餐垫子，这个是李四买的，就无法买。今天哪怕是AIOps，我用AI去学习帮我买东西，也要这两个东西，否则是无法下单的。

CMDB 在银行领域，我们分成这几个大类，我们 CMDB 是和传统的CMDB有一些不一样的地方，不一样在什么地方？传统的 CMDB 就是一个 CMDB 系统，自己一个系统，我们里面有很多模块，比如说网络、应用、容器、虚拟机、存储的等等。一个 CMDB 里面这么多的模块，第一开发成本很高，因为 CMDB 是谁做？一般是工具平台做，是一个数据级的工具。

但是它并不是一个领域系统，你可以了解一个开发的工具层了解一个交换机核心是什么吗？交换机有什么字段，你不知道，硬件存储，分布式存储你知道这个型号是代表什么？不知道。对存储来说，我们做 CMDB 的时候我们看到什么问题？存储。

商业化的存储有一些lun，这些lun通过FC卡挂到物理机，或者虚拟化底层的存储。在挂到那个机器上的时候，通过一个虚拟机我看到一个券，我要把这个券的关系找到某一个存储上的一个浪，这个做不到，这个是存储的人在规划、设计的时候才涉及到的，这样才可以保证这个东西瞬间的有一个点对点的目标的关系。

在这个CMDB里面，我们在每一块都分摊到每一个部门，我们开发组是做中间的CMDB数据的粘合，分为不同的领域，网络组开发自己的领域，他们把交换机采集、IP管理收在他们的领域系统里面，这个数据上报给CMDB，所有都是这样子上报的规则。我们的设计思想就是规划各个领域的系统要覆盖到什么，里面也有应用的关系，CMDB不止是基础组件，要和业务绑定，要和业务关联，没有和业务关联的CMDB就自己玩，无法对监控或者是排障、变更有作用。

这么多的领域，我们要什么？要建立一个统一的规则，这个规则也是很简单，就是一个模型，模型谁定？根据你的数据结构，一个领域一个模型。

要解决的问题是什么？优先解决数据的闭环，存量的问题，这个是历史债的问题，在平安银行，我们这么多的东西，我们要把存量的问题解决，我们做CMDB的时候很多东西不标准化，什么意思？举一个例子，我们说数据库，数据库的领域它和应用的关系有的有，有的没有，在交付过程中没有和应用关联起来，没有闭环数据，后期的消费中会发现这个找不到DB，这个是历史的问题。我们要把门关掉，建立一个正常的交付体系。交付体系之后会讲到，整个过程中是解决了资源交付，包括发布等等一串东西，最终回到CMDB。

第四点用订阅的方式来进行领域间的互动，这个怎么理解？事件驱动。我今天CMDB收到数据库的上报的消息，新增了数据库，这个就广播出去，谁要这个数据就去定，您订阅这个领域你关心什么，你关心的是物理机还是虚拟机，还是网络的变化，你去订阅，订阅了以后就做下面做的事情，你自己这部分事情做完以后再把更新的数据上报过来，这样就形成了所有的领域间有互动，而且所有的领域有闭环。

我们做CMDB开始的时候也是比较的担心，我说我们这个方式是不是一个合理的方式？通过订阅的方式是不是一个永远解决数据同步、数据一致性的问题？在我今天来这个大会之前，我们也只是和其他的同行互相做交流，比如说和携程、广发，招行做交流，说你们CMDB怎么做，就这样孵化出现在这样子的CMDB的模型。

我今天来GOPS大会，听了很多关于事件驱动，或者是中台建设，我发现我们这个CMDB路走的没有太大的偏差，心里稍微稳了。在那个时候我们有这么多的问题，我们来看一下各个领域的数据不规则性，很难产生通用的模型。

我们开始的时候是希望用主机，还是用主机、交换机、IP模型，更原子机的模型做CMDB 模型，这种情况下，你把数据上报回来以后数据治理的工作CMDB做，但是它很难做这个事情，因为他不知道当中的关联关系，我们把这个分给领域做，他们只报自己领域上报的数据，我们把这个级别上浮一层，他们自己的数据保持权威性，准确率。我们CMDB做什么？CMDB不止是把数据传进来，会做两个事情，第一个就是需要对这些数据做交叉比对，怎么说？比如说现在我有一台虚拟化的IP，可以新建出来，比如说新建一个虚拟机，这个上报过来了，这个时候我可以用网络的模型数据，看看这个IP是不是在网络那边已经被分配了。因为我们在创建的过程中，是要网络的IP分配，参数分配，才有虚拟机的产生。

这样的话，我们实时在跑数据的比对，这个和你上报没有关系，我们是不断的在跑，我们就是交叉不对，这样子去跑，跑下来保证每一个领域的数据相对准确率是高的，如果有一个环节漏了，像IP没有分配，这个IP哪来的？有这个问题。

我们现在查下来就是系统BUG，或者是系统规范，这个可能是人为我们就去改，或者是机制不规范，及时发现及时改。网络交换机里面什么信息都没有，你不知道这个IP在哪一个网络交换机的口，我们及时发现就及时改。

我们把这个模型上升一个领域，由领域自己去解决数据的准确性的问题。关联后的数据是错综复杂，通过交叉比对解决。

数据的检索需要快准易，为什么有这个挑战？CMDB的关联关系太多了，如果说今天要做一个场景级的数据，要向场景提供数据的粘合，这个数据的准确率，数据的响应速度，都是非常受到挑战。现在在CMDB里面数据量也不算太多，就10万，具体的数字不太清楚。现在的响应时间就是在1秒到2秒，就可以把整个关系讲清楚，我们收一个IP，这个领域关联这个IP的信息可以拉出来，这个就是数据结构图，这个是扁平化的，不是立体的。一会可以具体看一下实现的方法。

领域系统上报的数据校验问题。还有立新容易，废旧难，这个还是银行的这些东西。我要在原来的基础上建立我一套新的东西要兼容下面的。

CMDB设计，读写分离。我们分3层，第一层是数据上报，所有的领域把数据上报到我们的消息归类里面，我们CMDB清洗进来，一些必要的字段和实时交验，然后到其他的领域，该谁消费谁消费，形成一个闭环。下面这部分是解决我们搜索的问题。

这个是我们CMDB数据检索，CMDB 存在mongodb里面，不是用这个来提供检索服务，用mongodb查一条记录可以有很多，但是这个不是一个关系性的数据库，怎么办？mysql我也不想用，我们用的ES，把所有的数据扁平化，变成一条线，怎么理解？我们今天所有的领域约定一个东西就是GraphSQL，这个从服务器上面就有了，它有他的IP，有网络交换口，有存储的UID，每一个领域有自己的唯一建制，这个可以关联到GraphSQL。现在有47000个主机，意味着ES里面就是47000数据，这个检索的速率很快。

我们对这个GraphSQL等等一些关键的字段可以做索引，做完索引把这个从ES里面展示出来，展示用扁平和立体都是可以的，这个就是一个展示上的问题。

在这个里面，我们提到了一个数据闭环，这个数据闭环就是创建主机，当中每一个大块之间都是一个消息堆类，我们不是通过接口创建的方式，我们要做松耦合，我们当工具有问题的时候可以人为干预，不能因为工具垮了1万台机器不能交出来。

在整个闭环过程中，每一个大圆盘都是各个领域系统，每一个领域系统会结合这个事情，去实现自己交付的功能。我们发现什么？我今天可以解决上线，解决下线，我解决不了千万种变更，每一个领域按照刚刚说的方式的话，我们要在每一个领域上不断的开发新的功能，不断的封装一些原子的东西，这样我们的冗余上就有问题。我后来做了一些改变，怎么改？我们引入了流程引擎，我们用了AUTOMATED的概念，流程管理员在银行里面操纵，他可以决定现在哪些要走流程，上线、下线、变更、配置变更流程是什么样，流程里面可以变化很多种。我们无法把原型贴出来，我们内网把东西复制出来要走很多的程序，很麻烦。

我们在每一步里面用一个脚本来做，你去写这个脚本，我们用这个脚本就是为了直接呼叫你自己领域系统的原子的API，通过这些小的方法来把你下面的原子东西用起来。

整个流程过程中，CMDB全程是提供数据支撑，你要查什么在过程中可以拿到你想要的东西。

这个是解决我们标准化流程的灵活性的运用。

数据闭环当中，还有一个就是数据订阅，我们刚刚提到了，整个流程发起，CMDB把一个配置项变成一个变更的状态，如果不变的话，一个流程上报的东西对CMDB来说是不合法，你没有经过变更流程做这个东西就要告警，看看这个什么情况，是因为没有走流程还是什么样。

CMDB 做完以后就等待领域系统上报，每一个领域里面是自动化完成，那么领域系统会上报我这个消息，我看这两个有变更状态，那么我就把这个数据入库，然后把这个数据通知出去，其他的领域可以对应做一些事情。这个里面有一个典型的用例，就是服务器下线，当你发起一个流程对银行来说服务器上面的数据要清掉，防火墙策略要干掉，IP要回收掉，这么多的东西靠流程引擎一个一个算下来。当CMDB把这个数据变成下线时候，接下来的事情最重要，把这个消息推出去了，监控系统要知道这台机器下线，下线了的过程中不要告警了，如果发现一些业务的告警要静默。

中间件知道这个消息，如果现在上报信息失败了，我知道这个是一个下线的过程，我要静默，一个下线的事件告诉领域要做什么，不要做什么，你自己去决策做什么。

这个就是早期设计的一个告警收敛的面板，这个面板上就是聚合了所有的关联关系。

这个面板左下角有一个物理机，存储网络，这些信息都是从ODB拿过来，ODB是CMDB的扁平化数据以后的结构化的输出。输出了以后，就知道现在这个应用，左上角就是我们的应用，整个卡片是涉及的应用报警。这个报警里面有哪些是物理机异常，网络、存储、集群下其他有没有什么问题。我们这一层做基础的告警，更高有业务告警，业务链的告警等等，那个是上层告警，这个是基础告警。在这个地方，我们可以利用ODB，CMDB产生的数据关系来做该报警还是该静默，都可以用告警面板做出来。

CMDB刚刚讲过了，主要的目的是让所有的领域粘合起来，产生场景去消费的数据结构。

4. 运维中台需要哪些能力

运维中台，刚刚嘉宾介绍了Saltstack的事件驱动模型或者是框架。现在这个运维中台的能力是差不多执行这个事情，就是帮助脚本下发到服务器执行。运维中台解决的问题就是业务编排能力，业务灰度能力，高危的检测能力，关联关系识别。

任务编排的能力，我找到一个什么模板，我们业务中台可以设计脚本，封装成一个功能供给上面的用户在平台上使用，它可以编排我要到什么机器上执行什么，比如说上执行输出，作为下一个任务的输入。

任务灰度是运维中台的核心能力，如果要做这样一个运维中台的话，一定要具备灰度能力。看似是一个很简单的命令，跑在1万台服务器上有各种不同的反馈，有的是hang在那边了，有的失败了。灰度就是一批一批跑，主要是为了让你及早知道问题，一个命令下去马上可以反馈，过了一些时间问题出来了，这个时候要知道目前执行的结果是不是正常，才可以下发所有的，我相信没有一个人说执行一条命令可以4.7万命令都执行好。除非是LS，这个LS也有非预期的。如果有几十万个文件你怎么办？这个网络传输有问题。你不能说不会产生阻塞，灰度能力一定要有。

高危检测，就是针对一些RM，MV，主要是防灾，对下游做一些比较好的保护。

关联关系的识别，就是ODB的能力了，他告诉你现在要去解决一台应用的问题，你要回收物理机告诉你现在什么应用跑在这个物理机上面，在一些虚拟化里面，你可以通过不同的纬度下发编排不同的任务。

运维中台对上层就是解决场景的问题，对下游就是原子的问题，通过CMDB找到agent，通过agent告诉你下发什么东西。

合规能力，在银行里面就是因为一些固有的外部的东西，你要求厂商开发一个东西，迭代的周期不确定，我们把这个东西抽象出来。ITSM作为单据的存储的地方，我们也会和银监会报备，我们自己要做一个中台，要把这些东西抽象出来，抽象出来最典型的场景就是可以编排很多变更单据的组合，组合成一个紧急变更，或者是常规的，或者在单据方面做一些事，这个事涉及到什么，我们包一下，一键可以下发到多个地方，这样任何的操作都是合规合理，不要为了一个变更还有一个工程师一个一个去填单子，这个太累，这个是一个包装。

它提供什么？取决于上面的场景，场景需要什么我做一个这样子的能力。

当我们运营的工具，有变更的东西以后，我们就可以实现用户一键可以解决所有变更操作，单据也有，执行也有，反馈也有，最终是达到你想要的结果。刚刚我们说这三个系统，看起来就可以解决能力问题。这个按纽是一个想象，任何的想象都可以，比如说一键迁移，一键切换，都可以。

这个是目前的一些东西，这个是根据现在的现状做的一个工具框架，我们可以简单的看一下我们分为运营中台，数据中台，交付能力，下面是自动化来实现，数据通过CMDB数据闭环把所有的数据粘合在一起，向上运营中台提供东西。

运营中台做的事情就是一键，所有的东西是一键，有场景就要解决场景，通过解决场景来迭代运营中台。最上面就是运营能力系统，这个就是刚刚说的什么？这个系统是在于应用运维，应用运维要有能力识别他要解决的场景，我要发布，我要迁移，要灾备，要分流，这些都是运营能力，一键下去就告诉下面所有东西一起来改。

5. 总结

总结一下，我告诉大家是什么？建中台的时候，往往这个中台会给人带来很空洞的感觉，今天我说的是中台，不敢说是中台的服务，只能说是一个中台的出现，这个方向对了，今后做成什么样，我相信明年有机会来分享的话，应该可以看到更多的成形的东西。

在建中台的时候要分成上中下来分层治理，底层就是解决耦合，越原子越好上层就可以灵活使用。中层要解决场景，有了场景就去做，没有场景不要乱做，往往我们开发了一个系统，开发完以后交付出去发现什么东西没有用，你还说人家需求提的不好。上面就是解决场景问题，不要干底层的事实，你想你灾备怎么恢复，迁移怎么做，要分流、扩容怎么做，想这个事情就可以了。

运维中台在建设的时候，一定要从运营的实际场景出发，运营要有闭环的CMDB，CMDB是基石，这个提供的能力超过你的想象。我听到很多朋友说CMDB建起来是什么样？现在用到云，他说云上一个API拿回来，然后没有数据聚合，没有交际，没有给上层提供一些东西，就是一个资产管理，你算算月度报表人家和你账是不是一样，只可以算这些东西。

从现阶段实际问题出发，不要引入大框架，新技术，最好的东西就是适合你现在解决问题的东西，当你到一定规模你一定会用他，他是很好很好的框架。各种东西都有长处，但是要适应才行。

我们工具太多了，可能时间不够，我今天分享就这些。谢谢大家。

（来自：高效运维）