巧妙关联运维数据，银行建设混合 CMDB 也能飞起来

讲师介绍：徐大蔚，平安银行运营开发负责人，10 年运维经验、全栈经历，擅长运维架构设计及应用排障。曾供职过巨人网络、一号店、大型数字广告公司，现就职于平安银行，先后担任过运维架构、运营开发经理职位，专注于建立平安运维体系，构建平台化运维，助力银行互联网转型。

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

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

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

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

一、混合 CMDB 的建设

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

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

1、模型设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、数据采集

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

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

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

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

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

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

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

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

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

3、互联网+的配置管理模式总览

我们建 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 方式，采集上来的数据可以被校验；如果没有这样的领域，没有像银行这样多细分领域，那么采集上来后直接自己使用也可以，然后再通过交叉检验方式去检查采集的数据是否准确。

4、服务目录

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

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

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

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

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

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

5、流程引擎

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

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

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

二、CMDB 数据的使用

1、数据价值初探

有了一套完整的 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 强大之处了。

2、工具架构设计

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

3、数据化运维系统

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

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

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

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

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

• 服务部署视角

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

• 变更影响视角

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

• 应用调用视角

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

• 事件序列视角

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

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

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

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

三、数据治理的原则

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

原则一

微观描述数据问题，宏观归纳问题现象，找到问题的源头，优先解决数据闭环，从流程上或工具上优化数据路径，收口后再逐一解决存量问题，先解决同类问题，再看独立个体问题，一定要分层处理，切忌盲目下钻，事倍功半。

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

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

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

• 分开治理，互相之间没有关系，大家是并发状态，没有串联；

• 我们找到几个共通的点，都是因为流程不合理造成的，一边治理数据，一边脏数据往里面进去，那永远治理不好，所以我们就找到了几个点，把这个流程梳理了。流程一旦梳理好了，我就可以把口子一收，口子一收这个数据就不会再脏了。有脏数据进来说明你的流程还不够完善，肯定是有哪一个地方漏了。

原则二

对于多系统间的工具使用生态体系的眼光来看待数据，有生产者，消费者，分解者。这三个角色都是围绕同一份数据进行工作，所以对象必须是一致的，数据库上报的是主机的生产 IP，你告警使用的对象绝对不可以是存储网或者其他虚拟 IP 的对象。

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

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

原则三

工具系统要有数据校验的能力，善用不同领域间的逻辑关系，来加强各领域上报数据的覆盖度和准确性，对于无法和外部交叉检验的领域，需要有第三个自动发现系统来做数据核实，将数据的质量和 KPI 挂钩，是一种保持数据长期鲜活的办法之一。

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

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

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

Q & A

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：流程已停。

文章转载自：DBAplus 社群（ID：dbaplus）

原文链接：巧妙关联运维数据，银行建设混合CMDB也能飞起来