每次读到配置管理相关的书籍时,我总在想:“这些定义很精准,流程也很完整,但这不是真正的难题。”对于一个配置管理者来说,真正的难题不是绘制“庞大而精美”的数据模型,不是设计“全天候、无死角”的管控流程,而是如何促进数据的消费,并在消费过程中持续的改善数据质量。

 

我在华为从事了七年配置管理工作,见证了CMDB从一个半死不活的边缘系统逐渐成为运维的核心。

 

离开华为后,我有机会看到很多CMDB项目,才发现原来像华为这样将CMDB真正当成运维中重要一环的并不多。大部分CMDB项目,不是以失败告终,就是在失败的边缘苦苦挣扎。这引发了我的思考。为什么CMDB普遍失败?华为的做法有可复制性吗?有没有更好的实现模式?

 

CMDB成功的关键因素

对于CMDB项目的失败,普遍的解释是:没有数据的消费场景、工具和技术不行、流程管控不足。

 

从我自身的实践来看,我对此是有不同看法的。上述原因的确会影响人们使用CMDB,严重时甚至会造成项目失败,但这不能解释普遍性的失败。其实每一个IT组织内部,不管是专业技术团队还是流程和技术管理部门,都有自建的配置库(如,主机配置库、网络配置库、机房配置库……后面简称“自建库”)。如果没有数据消费场景,哪来这么多自建库?同时,这些自建库的技术并不先进,甚至很粗糙,也没有管控流程,但依旧野蛮生长,用得好好的。为何它们有如此强大的生命力,而投入众多先进科技(联邦、调和、可视化、流程引擎…)和严密管控流程打造而成的CMDB,却命如薄纸?

 

CMDB的失败不能简单的认为是消费场景、技术和管控流程的问题。而应该从成本和收益的角度考虑。

配置管理本质上是“数据管理外包”。抛开那些高大上的价值(趋势分析、影响分析、根源诊断…)不谈,它的“初始”价值是能够减少各管理业务重复维护数据的成本,从而使这些管理业务更专注于本身业务能力的改进。

这个理念没问题,但实际上,各运维管理业务更倾向于在数据管理方面能够自给自足。这里有两个原因:

 

1.由于管理规模不大,所以各管理业务分头维护数据的成本并不高

2.能够对数据拥有最强的掌控力,可以根据自身业务的变化灵活的调整数据模型,或是通过个性化的管理规则和功能设置,让用户更方便、更准确的输入信息。

 

这种自给自足的小农经济模式当然会有问题,比如,各领域的运维数据相互孤立、数据不一致以及总体数据维护成本偏高等等。但在特定的管理水平下,这种模式却是最有效的,因为对数据的全力掌控能够带来变化的灵活性,并提升数据的准确性,只要成本能够接受,这种平衡将无法打破。

 

可是,如果使用CMDB这个“外包服务”呢?首先,失去了对数据的掌控力。CMDB不是你一个人的,不可能说改就改,总得统一规划吧。何况ITIL中也明确写了“对配置模型的修改需提交配置委员会评审”。另外,你以为成本真的会降低吗?不一定的。初建的CMDB,数据质量不可能很好,如果贸然消费,很可能带来大量的数据纠错成本。

 

所以,CMDB不受欢迎的重要原因,是因为CMDB在建设初期往往使各运维业务对配置数据的掌控力反而下降了,而它所带来的成本降低,即便真实,在当前的管理规模下也没有足够的吸引力,从而导致CMDB项目的推广和应用往往有很大阻力和困难,很多CMDB项目就都死在这个初级阶段上,无法向下推进。

 

那CMDB就没戏了吗?也不完全是。随着运维规模的扩大,数据维护成本会相应增高。当自给自足的管理模式难以支撑时,旧平衡将被打破,而新平衡的支点,将是CMDB。

 

下面这张图,描述了使用CMDB后,对运维业务的成本改变情况。普遍情况是,运维业务的管理成本在短期内会提升(因为要进行数据纠错),但长期会下降。而运维的标准化程度越高,成本会下降得越快。因为标准化的流程具备更明确的输入和输出,通过CMDB,能够驱动单流程的自动化运作以及多流程协同。

 

图1使用CMDB后的管理成本曲线

 

但是,新平衡不是自然建立起来的。人们大都不愿意主动改变原有的工作模式,即使愿意改变,对使用CMDB也仍然有很多的顾虑。因此,CMDB建设需要有敢于不断试错的勇气和环境和长期坚持的耐心。只有这样,才能在旧平衡被打破时,尽快的建立起新的平衡。

所以,CMDB成功的两个关键因素是:管理对象的规模和组织的执行力。华为的运维环境基本具备上述两个因素,但过程依然漫长和艰辛。如果不是每年能涨点工资,我很难相信自己能坚持下来。

后面几篇文章,我会简要介绍我在华为参与的CMDB建设历程,跟大家分享一下我的经验教训。

 

 

华为CMDB是如何炼成的

 

华为CMDB的建设历程可以分为三个阶段:初创期、整合期和价值发挥期。

 

图2华为CMDB的三个建设阶段

 

初创期

2002年华为IT运维引入了ITIL流程,同时也一并引入了CMDB。那时我们并不知道CMDB该怎么用。但由于“先僵化、再优化、最后固化”的指导思想,我们完成了系统建设,并成立了专职的配置管理团队。

2002年到2007年,是配置管理最尴尬的几年。当时每个技术管理部门都有自己的“自建库”。比如,机房管理部和网络部有设备表,X86管理部、Unix管理部也开发了自己的配置库。大家各玩各的,就是没人玩CMDB。大家普遍的说法是CMDB不准。因此,配置管理团队付出了巨大努力,比如,强化管控流程、定期开展数据审计等,但始终无法打开局面。

 

整合期

故本文的事从2007年开始。那时,我已经在华为做了一年变更管理员,厌倦了天天盖戳的工作,我认为自己其实是一名程序猿,所以向陈总提出要调到开发部门的请求。陈总人很好,他告诉我CMDB大有可为,并果断给我涨工资。从此,我半推半就的走进CMDB的世界。

简单粗暴的方法-强制拆迁

我的想法很简单,只要那些自建库不存在了,大家就不得不玩CMDB了…所以,抱着大有可为、一统江湖的心态,我开始策划如何拆迁掉那些自建库。

在得到高层领导的同意后,我们开始了拆迁调研。经分析,技术管理部不愿意使用CMDB的原因有两个:

 

  1. CDM不接地气,与各管理业务的数据模型不兼容

  2. CMDB的易用性差

 

因此,我给出的拆迁补偿是:

 

  1. 基于各业务的管理粒度重新设计配置模型

  2. CMDB工具推倒重建,重点提升易用性。

 

当时国外CMDB产品很贵,买不起。所以在达成拆迁协议后,我和强叔联手自行开发。我们使用了当时最时髦的技术,目的是最大程度的提升用户体验。

在巨大热情的支撑下,我们很快就完成了系统开发。在宣传推广时,新CMDB也广受好评,因为基于Javascript富客户端技术的用户体验的确比之前基于Notes技术的老CMDB好太多了。但在实际搬时遇到了困难,没有人真的愿意搬进来,还是更愿意使用原来的系统。理由有很多,比如,操作不太习惯啦,**团队需要的一些特殊功能没有做啦。

好吧,记得Peter Thiel也说过,如果要在同质化的产品中赢得竞争,必须对已有的产品功能有10倍以上的提升。也许我们的自己的水平不行,达不到这个条件,那就买吧!于是,我们采购了国外一流厂商的CMDB。

但结果仍然不尽如人意。除了机房配置库、网络配置库由于是Excel表,在版本控制上存在问题,不得已搬入CMDB外,其他技术团队仍然在使用自己的配置库。

从此,我认为提升工具的易用性并不能帮助CMDB走出困境。原有分散的数据管理模式有其存在的理由,并已经形成了一种平衡。这种平衡不可能通过CMDB的强行介入来打破。为了建CMDB而建CMDB是注定失败的。

不过,虽然拆迁的效果不好,但在此过程中我们优化了配置模型,新的配置模型更接地气,能够与现有管理业务的管理粒度和数据结构兼容,为日后的系统对接打下了基础。

 

全球化的机遇-全球数据整合

先说一个小背景:华为IT运维管理主要分成两个部分,系统运行管理部和区域IT管理部。系统运行管理部负责数据中心运维,特点是:人员专业性较强,并建立了完善的运维流程体系和管理工具。区域IT管理部负责海外机房的运维,特点是:机房量非常大,流程不健全,也缺乏管理工具。

2008年的春天,海外发生了一起安全事件,事后追查,发现这些服务器没有纳入系统运行管理部的安全管控范围。于是,华为IT开始推进全球统一运维,所有国家、所有机房,均纳入系统运行管理部的流程管理体系。

全球化带来的直接后果,是各个运维管理部门的数据维护成本陡然上升。以前只需要搞清楚数据中心内部这点家底就行了,现在要搞清楚全球几十个国家、一百多个机房中的软硬件配置信息,这几乎是不可能完成的任务!

于是,大家把目光转向了配置团队:你们不是专业做数据的嘛,这事你们就担了吧。没问题!(我耳边响起刘德华的歌“盼了好久终于盼到今天”)

于是我们手持安全内控的尚方宝剑,花了半年时间,顺利的完成了全球IT资产的梳理并整合进CMDB。

这对CMDB有里程碑的意义。虽然CMDB在“准确性”和“灵活性”方面无法超越自建库,但这一次,CMDB终于在数据的“完整性”方面完胜群雄。

有了全球家底数据,各管理业务开始体现出对CMDB的兴趣,开始定期和CMDB进行数据核对,并发现了大量遗漏管理的设备。从此,CMDB逐步从运维的边缘逐步走向核心。

 

价值发挥期

冒险的尝试-流程自动化

起初,CMDB与外围管理业务进行半自动的数据核对,输出遗漏管理的对象清单后,提给各外围业务处理。但老这么干太费劲。于是,我们开展了流程自动化的工作。

首先尝试的是账号管理,因为全球有海量的账号需要回收,人工成本极高。我们先进行了自动开单,当账号管理系统从CMDB中识别到未回收口令的CI时,可自动触发批量口令回收工单。试点效果很好,大大提升了账号回收效率。大家的信心增强了,于是我们进行了更大胆的尝试:账号管理系统基于CI属性自动识别口令回收脚本,并触发脚本执行。我们的实践再次取得成功,账号管理从此轻松实现了百万级口令自动回收,领导再也不用担心口令没回收啦!

 

账号管理实验成功后,我们乘热打铁,迅速与监控对接。监控业务同样面临全球广覆盖的要求,有强烈的原动力。最终实现的效果是,当一个CI在CMDB中被置为生产状态后,监控系统会立即识别,并根据CI的属性和关联关系自动确定监控指标和告警级别,在完成人工确认后,可触发自动化监控部署。

 

通过与这两个业务的集成,使大家看到了CMDB在运维自动化方面的潜力。原来CMDB除了给人查阅,还可以这么玩!从此,配置数据的消费呈现爆发式增长。不到两年,已有十几个业务流程基于CMDB运作。各业务流程通过数据总线识别CI状态的变化,一旦CI进入对应业务的管理范围,就自动触发流程执行。回顾整个推广过程,我发现原动力最为关键。对于一些有广覆盖需求的业务(尤其与安全相关),其原动力最大,会主动找CMDB。比如,补丁管理、入侵检测、账号管理、合规检查等等。

 

驱动单个流程自动化只是CMDB的起点,当运维的标准化程度足够高时,CMDB还能够驱动多流程协同。比如,实现服务请求的端到端交付。示意如下:

 

图3CMDB驱动多流程协同

依据经验,通过CMDB驱动各流程协同,可以将服务器的交付时间从原来的1个月缩短到3天。更重要的是,外部客户再也不用介入在资源交付过程中的各种跨部门、跨流程的沟通工作。

经过多年的努力,CMDB已经逐步变成了各个业务流程的起点,为各个流程提供高质量的配置数据。有一次,我跟刘青(我的领导)开玩笑说,你看我们多重要。一旦CMDB挂掉,华为整个IT运维流程就摊了。刘青批评我说,别乌鸦嘴!

 

最大的难题-数据准确性

数据的准确性是CMDB的生命。因为账号管理和CMDB都归刘青管,所以账号业务相当于CMDB的内部客户,即使CMDB不准,账号那边也得忍着。但监控、备份等外部客户就没那么好说话,如果CMDB长期不准,客户很容易就会流失。所以,持续提升准确率是巩固成果的关键。

 

但如何提升准确率呢?很多人说,只要数据被用起来了,自然会准的。真的吗?其实未必。这里面缺了一个前提:要有反馈!

举个例子,其实监控和备份在很多年以前就开始消费CMDB的数据。但一切是那么的安静,没有任何对数据质量的抱怨。这跟后来账号管理消费CMDB时的氛围完全不一样,我每次碰到朱娟凤(账号管理业务的负责人),就感觉到强烈的杀气。

 

仔细调查后发现,这些流程有后门!正常情况下,用户在工单中选择CI后,系统会将CI的相关属性自动填入工单。但如果CI的信息是错误的,或者CI根本没登记,用户可以自行在工单中录入信息,这整个过程,CMDB根本不知道。这就是为什么监控、备份“号称”基于CMDB运作那么多年,却从来没有怨言。燕过都要留毛,你们消费CMDB不给钱就算了,总得对数据准确率做点贡献吧!于是,我们想到了一些办法:

 

1、关门和放权

“关门”的意思,是CMDB的下游业务发现配置数据不准时,不允许私自修正,必须回到CMDB修正。

可以想到,这个策略实施后肯定立马炸锅。因为用户在使用外部系统时,一旦发现配置数据错误,就不得不停止手头的工作,回头更新CMDB。新数据要获得审批才能生效,生效的数据要同步回外部系统,用户才能继续工作。这大大降低了业务效率。所以,我们又想到一个办法。

为了避免被人打,我们不得不做了一个大胆的尝试:部门内“放权”。用户更新自己部门的CI可即时生效,无需流程审批。因为我们从经验判断,CMDB准确性最大的问题是CI得不到及时更新,而不是更新错误。后来证明,这个决定完全正确。

其实,还有一种更理想的方式是“就地修正”。用户在任何管理系统中发现配置数据不准,应能在当前页面中直接修正。系统会自动将修正后的信息更新回CMDB或更上游的数据生产系统。可惜当时开发资源不足,没有实现。

虽然“关门”很讨厌,但“放权”将影响降到了最低。通过这个方法,我们捕捉到了消费者的反馈,实现了数据在使用中越来越准。

但似乎还差了什么?…

如果CI没登记呢?那么CI就不会被消费,也就不会发现问题。更严重的是,对CI的安全管控也会遗漏。所以,CMDB还有最后一件重要的事情要处理--发现黑户!

 

2、发现黑户

一开始,我和李渤尝试使用嗅探的办法,试图发现遗漏登记的设备,但效果不好,因为嗅探出来的数据太多、太乱,无法识别。

后来,在牟旭涛的支持下,我们想到一种奇葩的方法:将CI登记与IP地址管理流程结合:所有接入网络的服务器或网络设备都要有IP,IP必须走流程申请,走流程申请就必须登记CI,有CI后就能通过自动发现获得CI的详细信息,有了CI的详细信息后,就能顺藤摸瓜(自动发现或人工追查),把与之关联的CI找出来。

这是应该一个完美的闭环,CI不会漏了吧。

可是,如果私设IP呢?

这就要用最后的绝招了-- “黑IP检测”:所有网段挨个ping,抓出所有活动的IP,然后与IP申请流程做比对,发现黑IP。发现黑IP后,提交给网段管理员分析IP对应的设备,如果实在分析不出来,就提给机房管理员,顺着网线找!

通过这个极端方法,我们真的发现了大量遗漏登记的设备。

不过,随着实践的深入,我们发现问题更加复杂,比如,云环境下,操作系统是自动安装的,IP也是自动分配的,没法走流程申请,怎么办?非云环境下,远程装机需要使用DHCP地址,如何将DHCP网段排除掉?但办法总比困难多,最终问题都解决了。

另外,还有些无法自动发现的问题,可以通过数据合理性分析的方法自动发现出来,这里不再详述。

 

想点新东西

CMDB终于被使用起来了,我们也找到了办法使数据也在使用过程中越来越准。下一步做什么呢?

1、数据分析

CMDB向外围业务供数的模式,很像原材料出口。量大,但附加值低。能否再做一些加工,提升数据的附加值?

我首先想到的是数据分析。因为CMDB中记录了设备的开关机状态,我们通过计算设备的关机时间,发现出全球有几百台长期关机,却一直放在机房中的设备。调查后才知道,海外很多地方的机房被当成库房用,大量无用的设备堆积在机房内,浪费了机房的空间容量。另外,我们通过关联关系分析,发现出很多开机的服务器没有关联任何应用系统。经调查发现,原来的应用已经下线或迁移了,这些服务器一直在“空转”。

之后,我们还做了很多其他的分析,也都有新的发现。看来,通过数据挖掘推动管理改进,是CMDB的新价值。需要注意的是,配置管理团队的职责不是天天挽起袖子去发现别人的问题,而是应该提供一个灵活的数据分析平台,让别人更好的发现自己的问题。

 

2、可视化

可视化是在我华为最后一年的尝试,当时想法很简单,CMDB跟其他数据库比,最有特色的地方是记录了完整的CI关系。而运维最重要的业务之一--故障处理,就非常迫切的需要看到IT组件间复杂的关系。可是,关联关系用传统的表格形式展现,很难让人理解,如果能以图的形式把CI关系展示出来,把分散的对象以人们习惯的架构图的形式组织起来,同时,在图中还能看CI的配置、性能、告警、变更、事件,那是多么有价值的事情!

 

于是,我和强叔再次操刀。我们用TWAVER开发了一个可视化系统,名字很响亮,叫CMS,它能够基于CI的关系自动生成架构图。

然而,实际的使用效果并不理想,原因是:

 

  1. 自动视图对关联关系的数据质量要求太高,虽然当时CMDB的数据质量总体上已经很不错,但关联关系的数据质量依旧是短板(很多关系无法发现,人工维护起来又很麻烦),导致很多架构图缺胳膊少腿;

  2. 自动视图中的CI粒度比传统架构图更细,有没有引入“容器”聚合细粒度的CI,技术人员看不懂(比如,传统架构图上,一台应用服务器对应一个图标。但CMDB生成的视图有三个图标,分别是中间件、操作系统、物理主机);

  3. 架构图中的关系连线没有收敛,导致线条错综复杂,难看至极;

  4. 图的自动布局不太符合人们的视觉习惯。

 

由于后来离开了华为,所以没有把这件事继续下去。现在回想起来,还是积累了不少经验:

 

  1. 架构图自动生成这件事,在现有的技术条件下非常难。架构图是需要一点点创造力和美感的,而程序很难有创造力,更别说美感了。而且架构图本身很复杂,比如两地三中心的架构布局,工具就很难按照人类的预期绘制出来。

  2. 对用户更有用的,其实只是一张空白的画布,用户能够把CI拖入画布中,并自由的绘制和布局,就像画Visio一样。如果CI的关联关系缺失,没关系,直接画一条线出来就行了。

 

这些经验后来也得到了证实。去年,优锘给华为提供了一套配置可视化产品,效果非常好,能够以自服务的方式快速实现大量交易流的可视化。项目结束后我们还收到了华为写的感谢信。

 

 

总结

已挖掘出的价值

华为CMDB是相对成功的,因为我们从它身上挖掘出一些实实在在的价值,比如:

 

  1. 避免配置数据被重复维护,降低数据管理的总成本;

  2. 共享同一套配置数据,使各运维业务对IT资产的基本配置情况达成共识,并驱动各流程的自动化协同;

  3. 能够以CI为核心,拉通各个管理工具中孤立的数据,并通过面向管理场景的数据分析和可视化,使IT管理者能更加全面的掌握CI的运行状态和管理现状,提升管理的透明度。

 

 

华为的特殊性

即使全部掌握了上面的经验,也许仍然无法按照华为的模式建成一个CMDB。

为什么呢?

因为华为CMDB的主要客户是系统,而不是人。这种模式是侵入式的,会对原有的业务运作模式在短期内带来巨大冲击(业务效率会降低、成本会增多、风险会增加),必然受到抵制。

华为能按这种方式做成的根本原因是什么呢?其他组织又是否具备呢?

 

 

华为CMDB成长的土壤、条件、机遇和运气

 

强大的执行力

很多人都知道华为有一句口号:“先僵化、再优化、最后固化”。这不仅仅是句口号,华为的确是这么做的。2001年,IBM的外国顾问引入了配置管理流程,并设置了专门的管理部门,但并没有讲清楚CMDB到底怎么用。结果,在长达6年时间,配置管理事实上并未给运维带来多大的好处。虽然如此,华为仍然持续投入。那些年,配置管理部门始终保持3-7人的规模。正是这些人不断的尝试,不断的努力,才迎来了成功的机会。

另外,在2009年完成全球配置梳理后,为了保持数据的准确,几乎全部IT人员都动员起来了。只要有人出差,不管去全球哪个角落,都会帮我们检查当地的配置信息。甚至CIO周总也亲自下机房检查。我还记得那几年周总每次出差前,都会问我们要一份当地机房的配置清单。当然,为了保持良好的合作关系,我会立即通知当地的机房管理员,赶紧自查!

 

管理规模大、标准化程度高,有强烈的自动化需求和现实条件

华为IT资产的体量庞大,分布极广(在全球有几十万台设备,分布在几十个国家的一百多个机房),而运维人员只有几百人,大部分都在总部数据中心,这必然带来流程自动化的需求。

另外,2002年引入配置管理的同时,也引入了其他一系列ITIL管理流程。经过7-8年的完善,这些流程的标准化程度已经很高,具备了自动化的基础。

由于上述条件,使华为CMDB的潜力得以充分发挥。

 

全球化带来的机遇

全球化带来了管理要广覆盖的要求,使得各个管理业务自建配置库的数据维护成本陡然上升,不得不认真考虑“数据管理外包”。

 

偶然的运气

第一个运气:在“和平”时期,配置管理团队独立完成全球配置数据梳理是不可能完成的任务。然而,在海外发生的意外使安全内控被空前重视。配置管理“手持”安全内控的“尚方宝剑”,人挡杀人、佛挡杀佛,奇迹般的在短时间内就完成了全球数据梳理。

第二个运气:基于以往的教训,即使CMDB完成了数据梳理,其他业务也不敢贸然使用,因为CMDB的第一个用户必然要消化掉存量的数据质量问题。幸运的是,当时账号安全管理部和配置管理部正好都归刘青管。刘青一方面苦于CMDB没有消费场景,另一方面又面对账号管理要广覆盖的强大压力,那就把这俩宝贝撮合一下试试吧…这也是为什么账号管理敢第一个“吃螃蟹”。

那么,为什么国内大部分公司做不成呢? 因为他们很可能不具备这些条件。下面是一个对比:

比较要素

华为

其他组织

执行力

超强

(先僵化,在优化,最后固化)

一般

管理规模

超大

一般

管理标准化程度

明确的流程触发条件
明确的数据输入标准
面向应用和业务的管理

对象管理范围不明确
数据输入标准不明确

针对单台设备的管理

机遇

全球化导致原有管理模式成本激增

运气

具备内部试点的条件

表1华为和其他组织的比较

 

所以,鉴于这些因素,我认为华为实施CMDB的方式很难复制,但并不是说华为之外的其它组织就做不成CMDB,在下一篇文章中我将尝试总结一些相对通用的CMDB建设经验,分享给还在与CMDB搏斗的各位同好。

 

经验教训

通过成功的道路往往曲折艰难。建设CMDB也是如此。那些年,我们做了大量的尝试,有些成功了,有些失败了。抛开华为的特殊性,在这里总结一些通用的经验教训:

 

  1. 拆迁不如搬迁

    运维环境中已经存在的自建库,虽然粗糙,但有其存在的意义。贸然拆迁会有巨大的风险。比较保险的办法是保留原有的数据维护模式不变,只进行数据的复制搬迁。历史的经验也告诉我们,包产到户比人民公社更有效。

  2. 配置模型要接地气

    抑制设计完美配置模型的冲动。CI的粒度和关系要与当前的运维管理粒度一致。

  3. 开放心态和数据分级管理

    配置管理范围和CMDB管理范围是两回事。CMDB是一个大的数据管理舞台,有需要但没有合适管理工具的数据都可以放入CMDB中。但只有最重要的数据(如果错误会导致下游业务异常)才纳入配置管理。

  4. 数据维护流程要简化

    与其担心别人把你的数据改错,你更应该担心别人不愿更新数据。而复杂的审批流程,只会降低大家维护信息的意愿。

  5. 保障数据的完整性

    数据错了,可以在使用中被发现。但数据少了,是很难被发现的。同时,CMDB数据的完整性(就是家底)对于有广覆盖要求的业务有巨大的吸引力,因此要重点保障。

  6. 数据消费要有反馈

    如果无法捕捉反馈,就无法做到“在使用中促进数据准确”。

  7. 可视化

    可视化能够降低信息的理解门槛,也能够更好的暴露数据质量问题。是引爆消费、提升数据质量的重要手段。

  8. 在初创阶段,要克制数据分析的冲动

    CMDB高级阶段的能力,对数据量和数据质量的要求极高。在CMDB建设初期还是要务实一些,以与系统对接、供应原材料数据为主。

 

通向未来的道路

配置管理深深的“摧残”了我。几年下来,我逐渐形成了一种“非确定性悲观”的心态。我总觉得数据有问题,但又不知道哪有问题。随着使用配置的客户越来越多,我总担心哪天因为配置不准而摊上大事。因此,我想尽办法搞一大堆的数据质量检查措施,有变更后的检查、定期的审计、逻辑合理性分析、CI责任人的定期自我审视。这些措施,除了逻辑合理性分析有用外,其他基本没啥用。但这不重要,真正重要的是:当我摊上事的时候,起码可以跟领导说,你看,我该做的都做了…

可是,难道我们不应该更愉快的工作吗?

未来,肯定有更好的实施CMDB的方法。

这种方法,能够更大限度的提升人们生产信息的原动力和创造力,能够以非侵入的方式与各业务流程无缝集成,最重要的是,能够降低实施CMDB的门槛和风险,使大量中小型的IT组织能够从中受益。当然,也使配置管理员不那么的辛苦……

经过两年的探索以及与国内大量顶尖IT管理者面对面的交流,我们忽然发现,“自服务+可视化”的CMDB也许是一条通向未来的道路。CMDB与架构图的亲密接触会发生什么呢?这是我近两年一直研究的课题,相信在不远的将来,大家能会看到一个全新的方案。

 

图4虐心,但蕴含着无限可能

 

谨以此文,向那些曾经在配置岗位上一起奋斗过和至今仍在奋斗的战友们致敬。