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

徐大蔚 2020-12-22 16:31:00

本文根据徐大蔚老师在〖2020 DAMS中国数据智能管理峰会〗现场演讲内容整理而成。

 

(点击文末“阅读原文”可获取完整PPT)

 

讲师介绍

徐大蔚,平安银行运营开发负责人,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、数据化运维系统
3、数据化运维系统

 

 

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

 

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

 

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

 

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

 

 

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

 

  • 服务部署视角

 

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

 

  • 变更影响视角

 

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

 

  • 应用调用视角

 

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

 

  • 事件序列视角

 

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

 

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

 

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

 

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

 

三、数据治理的原则

 

 

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

 

原则一
3、数据化运维系统

 

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

 

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

 

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

 

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

 

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

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

 

原则二
3、数据化运维系统

 

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

 

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


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

 

原则三
3、数据化运维系统

 

工具系统要有数据校验的能力,善用不同领域间的逻辑关系,来加强各领域上报数据的覆盖度和准确性,对于无法和外部交叉检验的领域,需要有第三个自动发现系统来做数据核实,将数据的质量和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:流程已停。

 

↓点这里可下载本文PPT,提取码:jq32
阅读原文

最新评论
访客 2021年01月19日

请问错过直播怎么看回放?

访客 2021年01月15日

有开源计划吗?

访客 2021年01月03日

这种对话的方式,太拖拉了。又不是让你说相声

访客 2021年01月03日

什么乱七八糟的

访客 2020年12月25日

未Commit过的消息对客户端不可见 “如果Follower的ma…

活动预告