今天很荣幸能聊一聊平安银行在CMDB和运营中台的实践，其实运营中台只是一个概念说法，主要看这个中台具体是做什么的。

主要讲两个方向：一个是CMDB，其实CMDB每个人都碰到过，但是真正能把CMDB管起来，保证你一年之后的数据依然是新鲜的、鲜活的，这个难度其实是很高的。我们常常碰到一个问题，某天问运维要一份数据，或者作为开发，你不知道数据有多少，这是第一种情况。

第二种情况，运维说法是不太确定，还需要再看一看，当运维再给到数据的时候，还能相信他的数据吗？大家都不会相信，还会去验证。所以这也说明了CMDB建设虽然很底层，但是很重要。

第二个是数据，我们的运维数据有很多，基础数据、监控数据、事件数据、变更数据等等，在银行里面各种各样的流程管控产生非常多的变更，当变更多了，发布和变化会导致生产方面一系列的影响，那怎样在这个过程中把这些数据关联起来？所以我们会在CMDB基础上去变一个魔法，让CMDB活起来。

先来讲混合CMDB。什么叫混合CMDB？其实是传统+互联网。传统怎么定义呢？我们都知道银行是一个传统金融行业，从古至今它延续下来是一个规范、流程。我们不能说流程没有用，因为延伸到今天依然被保留，而且被关注着，流程一定有值得利用的地方。

在重管重控之下，我们怎么让自己的工具开发能够非常灵活能够飞起来，所以就要用互联网思维，今天传统+互联网就是基于这种情况提出的。

上图是CMDB的截图，这是模型侧，涵盖CMDB里边所有的模块，CMDB有六个模块，包括模型、数据、变更等等，其中模型的建设就是我们今天要讲的。为什么要单独讲模型？是因为模型特别重要。如果模型没有设计好，那么对长期数据的进化就会产生阻碍。

这个模型上面注意哪些东西呢？这是所有模型关联的一部分，左侧是应用，右侧是DB；左下是负载平衡以及网络，中间是主机。我们看到有三个箭头，主机有五个方向，下面还有物理设备，物理设备有四个方向，其他都是单方向的，这就是和传统CMDB不一样的地方。

经过研究发现，传统的CMDB关联关系可能是一个模型嵌上一个模型，再嵌上一个模型，每一个模型里面有很多外件，这些外件都是关联到其他模型里面的，从而产生出一个很庞大的体系。

但是想一想，如果其中一个外件字段发生了变化，是不是可能会联动到多个模型发生变化？所以把这个模型的关联性叫做单一关联。

有小伙伴可能会问，说这样的单一关联以后查一个链路，如果要去获取所有的链路，从底层交换机的端口，通过物理机到虚拟化到应用，应用再关联到DB，要把这条线拉出来是不是很困难？

答案是不困难，但是这个模型不是干这个事的，这个模型就是为了让你灵活地存储收集数据，而数据链路是交由上层去做的，后面我会讲到怎么样施展魔法把这条链路拉出来。

先看一下模型的分类情况。这是OS模型，为什么把它分成两部分，一部分是元数据模型，比如说元数据实例名，这边是有统一的CICODE，它是由CMDB直接管理的，而其他所有的数据都是「领域」去管理的。

怎样理解「领域」？拿一个DB举例，这里有DB应用、DB集群实例关联到主机，这层模型关联关系从应用到集群到实例，三个模型是由DBA团队根据本地领域梳理出来的关系，哪个实例属于哪个集群？这个集群又是被谁应用去使用？

因为银行里面的组织架构会很细，有DB、网络、存储，设备、机房、应用运维……应用运维又五花八门。这么多情况下，如果我作为工具开发方，去推动铺垫这个链路的成本是很高的，并且所有的领域都必须严格按照我的要求去设计模型。

为了让领域能够更好的去做自己的关联关系，所以我们把这部分权利下放给了领域，领域把集群和实例关系接好之后，只要把实例CICODE指向到主机就可以了。

也就意味着DB整个关联关系就是一个建制，那就是CICODE，它有它的生命周期，而我就负责管理这个CICODE生命周期。同样的应用和网络交换机等等都是如此，所有关联关系一串下来都关联主机，这三个集群关联关系自己内部解决消化掉。

这些都是数据库模型字段，这些字段都是通过自动采集或者流程变更，你可以理解成在DBA团队里面有一个非常小型的CMDB，所有领域都是垂直的，只单向跟我沟通，领域和领域之间不会有任何沟通。

怎么理解？DBA绝对不会去找网络交换机，不需要知道放在哪个柜子里面，也不需要知道放在哪个物理机上，我只要知道集群是提供给谁服务的，有哪些机器，这就是DBA要做得事情。

这样就可以把每块领域拆的很干净，能带来的好处就是，当今天集群里面要加字段，或者关系，或者重新建它自己的关系，只需要把这部分全都推掉，DBA重新上报一次就结束了，所有外部的集群关联关系什么都不用动。

上图是「领域」，CMS是应用领域，它去负责每一个应用的属性。比如会给一个应用取一个ID号，这个ID号上面用了什么语言，跑了什么版本，用了什么中间件等等信息，还有它的管理属性，功能、开发、运维等等都会在这个领域里面完成它的关系。

从垂直领域进行切分可以保证所有领域是不相干的，拆分完了之后可以去做自己想做的任何事情，这是具有权威性的，当上报的数据到我这里，我会相信它每次的上报。我们也会有更多的检测机制，比如自动采集，会有一个组件自动采集所有网络设备，拿采集到的数据和领域报上来的数据去做比较，比较出来有问题的会退回到领域做相应的整改。

上报的数据是实时增量的。比如碰到厂商黑盒子的集群，有时候是通过API拿了所有数据回来，本身是不具备追溯性的。

今天前一分钟拿的一批地址里面有A，后一批拿的地址没有A了，那这个A去了哪里呢？我们不知道，但是对银行来说是不允许这种情况发生的，需要所有生产变更都需要有被记录，那要求领域做到实时上报。

怎么做到实时上报？很简单，就是内部CMDB先和拿上来的脚本做差异检查，把不需要的东西自己标记好再通过你上报。

这里又有一个问题了，我说这个状态改成A了，你就相信是A，我变成B你就相信是B，凭什么去相信结果？后面我们会跟变更事件串联起来，从后面的图里面会看到这个事情是怎么具有权威性的。

变更数据需要有变更操作记录，这就是每个变更项目都会有变更记录。说到变更记录，我们银行虽然有4万台物理机，10万台虚拟机、网络交换机等等不算设备的情况下，我们的数据量其实很轻，为什么会轻？

主要是在CMDB里面，就会想好做出来的数据到底有什么用处，不是所有数据都需要往CMDB里面扔，CMDB也不是一个“垃圾场”，CMDB其实是数据源头，它不是一个数据仓库。

凡是进CMDB配置项，都要求有生产变更的才会进来。比如说今天的磁盘使用率或者变更比较频繁的东西不需要进到CMDB。因为这些东西变化太频繁，频繁的向CMDB灌输这些东西，而这些数据产生不了任何价值的时候，我们就不会把它纳入进来。

我们建CMDB的时候是会依照四个基本的原则去做。

1）模型设计

建模的时候每一个模型都是单一的模型，领域里面内均匀集群单一地向中间方靠拢。

2）架构设计

CMDB本身是分层治理。最底层的数据仓库与所有接入领域的数据上报，但是数据清洗和数据治理又是在上层一个一个构建出来的，是松耦合高内聚的模式。

3）数据采集

领域的数据是需要独立采集上来的，即使工具开发平台有这个能力自动采集，但是采集上来的不会作为CMDB原始数据来使用，而是作为领域上报数据的校验数据来做对比使用，为什么？

你今天不是网络的同事，你不是CCIE或者你不是DBA，你没有办法知道里面比较细节的东西。在我们银行里边这个事情就被扩大了，虽然小公司可能一个人负责网络，同时兼DBA和运维是可能的事情，但是在银行里面是做不到，那这种冲突就会无限放大，所以我会选择相信权威，他的专业知识比我厉害，那么领域上报的数据我是优先认可的。

4）数据治理

数据治理，治理其实是后事，在前期我们需要遵从几件事：

每一个配置项，每台都需要有一个CICODE，这台机器从生命周期一开始CICODE就跟着，一路跟到消亡，比如虚拟机被销毁，物理机直到报废。

跨领域之间需要沟通，什么是“跨领域之间”？

举个例子，虚拟化云团队领域会上报虚拟机和物理机的关系，会先把关系关联好，然后把CICODE告诉我，知道虚拟机CICODE映射到哪个物理机上面，表示它的关联性。如果上报的一个CICODE没有在物理机里面，说明不是虚拟化有问题，就是物理机上报缺失了，这样就可以通过两个不同的领域知道数据里面的准确度有多少。

网络也是如此。每个网络交换的口子都会有对应的映射CICODE，表示那台设备是由哪根网线连接过来的。如果发现口子上的CICODE和实际在机架摆的CICODE不一样，说明这两边数据是存在问题的，所以可以通过交叉校验方式增加准确率。

实时自动采集能力进行反向验证。我会去做自动采集，比如检测IP，我去拼每一个IP，所有拼出来的IP通了，但是网络没有上报这个IP，通知IP没有在使用，那请问这个拼出来的IP是从哪来的？这就是我们需要做的自动化的采集。

如果按照比较轻便的CMDB方式，采集上来的数据可以被校验；如果没有这样的领域，没有像银行这样多细分领域，那么采集上来后直接自己使用也可以，然后再通过交叉检验方式去检查采集的数据是否准确。

刚刚说的是CMDB基础数据的存档。怎么把CMDB变得更“新鲜”？需要控制CMDB的变化，也就是对CMDB每一个配置项做到管控。通过流程与自动化工具可以实现管控的过程。

实际上方法有很多，这里只是银行的一种方法，比如我会放一个请求，变更管控都会先提一个请求单，然后把这些请求单拆成变更单去实施，会把这个请求单作为统一入口，入口就在我手上，其他地方既不能提请求单，也不会给权限。

提了请求单之后，请求单上面会有各种各样匪夷所思的需求，今天要这个字段，明天要那个字段。由于人数有限，不可能每天在做表单，所以我们就做了一种拖拽的方式。关于拖拽方式网上也有很多开源工具，这是基于我们自己的业务场景和数据链自己开发的，因为要做自动填充，所以没办法拿外部的东西直接来用。的左侧我们可以拖出很多控件，到了右边生成表单。

表单做好以后开始做变更，右边是变更的平台。一开始不想做成平台，本来任务的编排和脚本的写写就可以解决的事情，但是后来还是把它做成了一个平台。为什么？

我们往往会发现，今天有四个请求到了部门，但是这四个请求可能拆成两个今天做，两个明天做。在做这些事情的时候，我会要求对变更工艺去做Review，我们每天晚上都会去审变更的方案：这个方案成不成？是不是有风险？这样做有没有问题？在该平台上可以预先编排变更的工艺、分支、循环等等，这些在平台上都是以配置的方式去拖拽。

图的右侧有一个黑框，是脚本的黑框。这上面会分成四步：前置检查、脚本执行、后置检验、回轨。只要当天晚上Review之后，今天晚上就可以无人值守去跑这个变更工艺了，一旦发生问题我们就可以直接拦截，这个变更的系统会跟着CMDB去联动。

这里有一张简单的分割图，左侧是编排，我今天知道那个CICODE的IP要从1改成2，这个时候确定了变更范围。到了变更窗口时，创立一张变更单，变更单里面会把变更单号贴出来。

这些都会提前告诉CMDB，我们会预先告知CMDB今天晚上某个机器会有什么情况发生，然后在执行过程中告诉CMDB，现在有一张单号正在做这个事情，最后是领域的执行，执行完之后领域会把数据上报回来。今天IP从A改成B，首先知道这件事的不是CMDB，第一个知道的是网络系统。它会知道这台机器的A改成B，然后它上报给CMDB。

这时上报上来的数据我要做一些校验，每一个变化都需要有一个变更。这时候我会去看现在变化的和前面要求变化的东西是否一致。如果一致我就接受，如果不一致，那这次变更就是变坏了或者传错了，所以我们CMDB里面的数据一定是常新的。左侧开始的时候是1，右侧是2，显然这个案子是不准确的变更，所以CMDB全都能感知的到。

有了一套完整的CMDB数据之后，怎么利用数据？目前平安银行对CMDB做了两类使用，第一种是检索引擎，第二种是拓扑引擎。

1）检索引擎

可以联想平时工作出来一个IP故障报警，第一时间需要知道这个IP是什么。现在有十几万个IP在库里面，如何确定是哪个IP？要进入到CMDB系统里面一个一个去取吗？显然这不是高效的做法，所以用到一个搜索引擎，让所有CMDB的数据吐向ES，然后通过索引检索出来结果。

在检索出来之后，只要输入一个IP就会知道这个IP是哪个应用的，位于哪个CICODE上，这样OS模型就出来了。这时候知道机器管理员是谁，跑的是什么应用，就像百度输入一个关键词进去，所有信息就能拿到了，这是检索，这不是排障，也是使用次数最多的用途。

再比如有时候找一个人，例如我本人，想知道有多少应用是由我负责的，只要输入名字，就知道有多少应用是由我负责的。CMDB模型里面每一个CI项都可以作为检索的关键字。对于ES来说这些数据量其实非常轻量，好用。

2）拓扑引擎

我们把所有的数据放到neo4j。回到刚刚的问题，单一的关联怎么能把全链路的东西拿出来？这就要用neo4j实现，neo4j目前来说是比较新鲜的工具。在大数据，关联关系上neo4j有天然的优势。平安银行新组建了一个互联网的团队，区别于以前传统的团队，所以我们会尝试一些比较好的工具，现在用下来可以看到neo4j在环境中其实是起到比较好的作用。

现在搜索拓扑+API构成一个数据中台，CMDB之上构建了一个数据中台，把这个能力对外进行开放，可以开放给任何领域，给应用，发布，大数据等等，没有任何数据是不能开放的，因为相信我们自己有足够的准确性。

上图是我们的搜索页面，左侧可以看到现在输入是85131，这是应用ID，我们在平时跟开发团队沟通环节中或者告警都会以API ID维度抛出来，比如哪个应用API ID发生了问题，不单单是运维，还有开发的埋点监控，用API ID可以贯穿整条线。

85131首先是应用属性，它的中文名字、应用代码、子系统、负责人都会列出来，还会告知在24小时内应用发生过什么样的告警。我们把告警和变更的数据放进ES，这样都可以感受到运维里面发生所有的事情。

85131是在某一个主机上，为什么下面还有一个主机？因为85131是一个应用集群，下面这四个都是不同的CICODE，所以它是有多台主机的。

上图还有neo4j产生的拓扑，只有一条Circle关联所有的数据，从最原始的机房所在的机柜到机器到网络端口。这个机器又是宿主机关系，任何一个地方都可以再双机，再双机就是以这个维度延展它的相关性出来。我在任何一个地方都可以知道它是哪个业务，这就是neo4j强大之处了。

在工具架构设计之上，我们分了很多层去做数据，不仅有CMDB，还有变更业务，日志，告警以及零零散散的数据都放进去了。运维平时会产生很多数据，主要是四大数据，把四大数据集中往里面灌，然后走一堆流处理，该放哪放哪，各自去解决它自己要做的事情。图中间方框显示的就是中台，而上面可以做到数据查询、数据聚合、分析报表、排障分析、数据订阅等等。

我们来看一下数据化运维系统，这层是接近白色的方块层，展示的是平面的意思。这些平面数据全都映射到一张拓扑网上。首先把基础铺平了，上面链路就是这样，然后往上放变更、监控、告警，可以想一想，这是不是一个立体的投射图？发生任何一个故障都能知道这个故障点的影响范围。这个故障点发生了什么事情？有没有最近接进来变更？因为没有变更就没有伤害，没有变更那么运维24小时都是好的。

一旦产生变更，第二天早上故障概率就很大，因此要第一时间知道昨天晚上发生了什么。也有可能是其他关联的链路变动产生影响，这是另外一种情况，目的就是为了及早发现问题，定位问题，然后把它回滚掉。

这样一张透视的立体图是CMDB数据和监控数据利用最典型的场景，目前在平安银行运维系统里面有一个排障专用系统。排障系统可以通过告警的时序，每个告警的点是属于什么样的数量以及关联关系。这是垂直拓扑。

垂直拓扑是归于基础设施一类的，比如虚拟机、物理机、网络交换机等等。横向拓扑就是应用调用面，也会有人在做全链路时用到埋点。埋点可以从一个用户请求开始一直到DB获取，经过一串叠加与聚合，你就能知道过程中发生了什么，但那个只是业务层面，而垂直拓扑是基础设施。

如果只用应用拓扑，不能发现物理机坏了。当一台坏的物理机上跑十台虚机，十台虚机都可能受到影响，产生了10个告警，用埋点根本就没有办法关联它们。十台机器都传来告警，一个接着一个去处理，这要查很久才能结束。下面的基础拓扑就可以告诉瞬间发现它，知道问题来源于一台物理机，在物理机上也有告警，我们就知道这台物理机发生了故障。

如果是大面积交换机，我们要瞬间定位这个交换机下面的所有物理机有哪些，影响了哪些业务。不管是做一次变更影响范围是多大，还是发生故障的影响范围有多少，都能用到基础拓扑。

有一个变更做了散发出去，发生多少个影响，这个变更一旦回滚有多少需要通知到，都是通过这个数据串起来的。

要把排障做得更好，里里外外都要有，一部分来源于CAT(音)，一部分来源于爬主机。分析故障应用上下游的调用链路是否有服务异常和发布变更记录，评估链路调用间的影响关系。

现在所有的告警都会有消息处理，我们有一个告警的工作流，每个告警的产生到关闭都需要有一串状态，告警现在与我们的结束时间和变更时间，这个关联关系对复盘是非常有用的。为什么？

刚开始我也觉得处理完告警后，只需要关心现在生产上有没有告警产生，不关心它的处理过程，处理过程只不过是和KPI考核联系在一起。但是后来我们发现，往往在故障恢复完之后要做复盘，因为我们当中做了好多试探性变更，好多检测，都不知道哪些影响了这个故障，哪些让故障恢复了回来。

因为银行的应用调用太复杂，而且好多还是黑盒的，所以我们把所有的告警处理的时序和恢复时间点黏合起来，对复盘有帮助，下一次运维就会知道这个问题不会再发生，否则每一次都会重新来一次，这个很不值得。

我们银行做CMDB这个东西将近一年多，一年多时间里面我们CMDB做了五版，这是目前我们用的最顺畅的一版，实践可以证明这个体量运行的还行。我们的体量是4万物理机，10万虚拟机，DB大概几千套。

最后讲一下数据治理，数据治理我想解读一下这三条原则：

什么叫先描述？作为产品来讲，有一句话说做一个用户画像，一定是先微观描述这个人，这个人是42岁，女，什么工作，经济情况怎么样，都是很细节的东西。把这些细节的东西优先先描述出来，然后再去抽出它们的共性，有什么好处？

好处就是一个细节不一定是共性，两个细节也不一定是偶然，只有把所有微观的东西都描述出来的时候，你才知道优先要解决哪些东西？而优先解决哪些东西可以让你的价值获到最大。正如一天24小时没办法多出1小时，我们在有限时间里面把价值发挥最大，所以在处理这些治理数据问题的时候就需要通过这套方法去做。

我们的CMDB刚刚建好之后，让领域上传了一圈数据，通过交叉比对的方式就发现数据质量真的很糟糕，我们花了2个月就把所有的数据整干净了。我总结了一下这两个月数据治理为什么可以这么快。

今年平安银行的工具出了一个战略叫做“服务价值与数据”，我们希望通过数据来体现服务能力，用数据产生服务能力，从而以服务产生更多的价值，最终这些价值要转换成原数据再回到我们的数据层，我们是形成了这样一套闭环。

生产者、消费者、分解者，其实三个东西是生物界中的生态，比如说绿植在光合作用下产生了氧气，氧气被自己的呼吸系统吸收了，自己的呼吸系统吐出二氧化碳，二氧化碳又回到了自己的绿叶素，就产生这个环。这个环的好处就是让我们的数据实时滚着，因为一个数据不滚，户枢不蠹，就是一定要一直运作，一旦不运作了，哪天再去用它，根本就不知道这个数据还能不能用，要实时的不断地检测你的数据。

开始的时候团队有人跟我说，我们现在领域都自己上报了，也有变更了，所有的管控，所有的变化，我都知道了，那我为什么还要开发一些自动化的东西采集那些东西上来呢？最简单的一点，就是我对我的质量要有高度的要求，因为CMDB上游开放这么多应用场景在使用数据，我不能出现一丝一毫轻信数据，必须对它严苛的要求才能对上面所有的应用放心。

比如领导问我，今天有多少机器，我说一个45235的数字一定是准确的。为什么？因为我们对数据要求比较高。

对于领域我们只是一个监督者，没有办法去执法，执法是生产组的同事负责，生产组会给它打分，就是把数据质量和他们的KPI挂上钩，只有这样数据质量才会有更高的要求。

Q1：数据治理因为会涉及到比较多，我想你们是有什么样的管理架构来负责数据治理？有很多公司是公司领导层去负责，再往下一级一级去做数据治理，我想大概了解一下你们的结构。

A1：数据治理，首先是定规则，哪个数据是正确的，哪个数据是不正确的，这个规则是谁来定？这个规则是CMDB建设者和生产管理组，生产管理组囊括了生产上所有的事情，生产组有考核的权力，所以由他来跟我们合作一起做这个事情是比较好。先定好规则，比如说所有主机CICODE必须在物理机里面有体现的，这就是一条规则。我们把这条规则去实现，用工具用代码方式去实现产生报表。

然后我们有一个跟踪系统，我们把产生的错误数据推到跟踪系统里面，，推下去之后接下来就是由那个领域方去认领这个事情，对于认领、处理、验证都是有时效性的，这个时效性是由生产组来监督和管控的。比如我要求现在这个数据必须在2小时内认领，一天内治理掉，如果说每个月没解决多少，我们都会跟你的KPI挂钩，这样才能把数据从发现到纠正到执行到验证，全都在最短的时间里面解决掉。

Q2：前面老师有一个例子，一开始写的全部是1，确认全部是2，最后上报全部是3，那个过程中CMDB里面这个数据2生效过，还是没生效过？3是生产抓回来的数据，还是验证回来的数据？

A2：没生效，2都是在一张临时表中。

第一块是编排，是IP从1改成2，这个时候告诉CMDB我即将有一个事情要发生，那CMDB会拿着变更数据记到临时表里面，到了真正执行的时候，它会有一张变更单发给你，这个时候CMDB会把变更单和数据绑在一起。

当领域上报的时候，领域会把这张变更单和结果一起提交给CMDB，CMDB两边去做比对，变更单一致，变更内容一致，CMDB就会将你上报的数据收进来。如果两个数据比对不一致，CMDB是把你的数据丢到异常里面去了，那么第二天就要解决异常变更的情况。而我说的自动采集回来的东西不是在这个过程中发生的，自动采集的东西是实时去跑的，可以理解它采上来的数据就会比。

Q3：那这个变更是失败了，不交付使用的。

A3：如果它上报的CMDB不是我预期的那样，那我会把这次变更标记为失败了，但是不是真的失败？如果今天是自动化，我就可以不用标；如果今天不是自动化，是人工变更，这个消息就要Review单重新评估的，昨天是变更成功还是变更失败了？是你的变更工艺有问题？还是你的提交数据有问题？

Q4：如果这一步有后置的变更，它会停掉吗？还是说后置变更其实都已经做完了？

A4：如果说今天是自动化，全都会停下来。

Q5：是CMDB让它停下来的对吧？

A5：流程已停。

↓点这里可下载本文PPT，提取码：jq32