我怀疑遇到了假的CMDB

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

我在华为从事了七年配置管理工作,见证了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的建设历程可以分为三个阶段:初创期、整合期和价值发挥期。

(华为CMDB的三个建设阶段)

1

初创期

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

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

2

整合期

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

1

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

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

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

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

2. CMDB的易用性差

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

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

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

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

在巨大热情的支撑下,我们很快就完成了零碎开发。在宣传推行时,新CMDB也广受好评,由于基于Javascript富客户端技术的用户体验的确比之前基于Notes技术的老CMDB好太多了。

但在实践搬时遇到了困难,没有人真的情愿搬进来,还是更情愿运用原来的零碎。理由有很多,比如,操作不太习气啦,**团队需求的一些特殊功能没有做啦。

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

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

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

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

2

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

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

2008年的春天,海外发生了一同安全事情,预先清查,发现这些服务器没有纳入零碎运转管理部的安全管控范围。于是,华为IT开始推进全球一致运维,一切国家、所无机房,均纳入零碎运转管理部的流程管理体系。

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

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

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

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

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

3

价值发挥期

1

冒险的尝试-流程自动化

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

首先尝试的是账号管理,由于全球有海量的账号需求回收,人工成本极高。我们先进行了自动开单,当账号管理零碎从CMDB中辨认到未回收口令的CI时,可自动触发批量口令回出工单。试点效果很好,大大提升了账号回收效率。

大家的决心加强了,于是我们进行了更大胆的尝试:账号管理零碎基于CI属性自动辨认口令回收脚本,并触发脚本执行。我们的理论再次取得成功,账号管理从此轻松完成了百万级口令自动回收,领导再也不用担心口令没回收啦!

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

经过与这两个业务的集成,使大家看到了CMDB在运维自动化方面的潜力。原来CMDB除了给人查阅,还可以这么玩!从此,配置数据的消费呈现迸发式增长。不到两年,已有十几个业务流程基于CMDB运作。

各业务流程经过数据总线辨认CI形状的变化,一旦CI进入对应业务的管理范围,就自动触发流程执行。回顾整个推行过程,我发现原动力最为关键。对于一些有广覆盖需求的业务(尤其与安全相关),其原动力最大,会自动找CMDB。比如,补丁管理、入侵检测、账号管理、合规检查等等。

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

(CMDB驱动多流程协同)

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

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

2

最大的难题-数据精确性

数据的精确性是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没有消费场景,另一方面又面对账号管理要广覆盖的强大压力,那就把这俩宝贝撮合一下试试吧… 这也是为什么账号管理敢第一个“吃螃蟹”。

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

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

经验教训

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

1. 拆迁不如搬迁

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

2. 配置模型要接地气

抑制design完美配置模型的冲动。CI的粒度和关系要与当前的运维管理粒度分歧。

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

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

4. 数据维护流程要简化

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

5. 保障数据的残缺性

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

6. 数据消费要有反馈

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

7. 可视化

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

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

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

通向将来的路

配置管理深深的“摧残”了我。几年上去,我逐渐构成了一种“非确定性悲观”的心态。我总觉得数据有成绩,但又不知道哪有成绩。随着运用配置的客户越来越多,我总担心哪天由于配置不准而摊上大事。

因此,我想尽办法搞一大堆的数据质量检查措施,有变更后的检查、定期的审计、逻辑合理性分析、CI责任人的定期自我审视。这些措施,除了逻辑合理性分析有用外,其他基本没啥用。但这不重要,真正重要的是:当我摊上事的时分,最少可以跟领导说,你看,我该做的都做了…

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

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

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏GopherCoder

『沉浸式Github 使用指南 』

1563
来自专栏移动安全

乐固用户免费APP推广细则

用户无需付任何费用,只需在自己的APP中接入乐固提供的广告位,以自己的流量换取推广福利;

2554
来自专栏CSDN技术头条

微软开始在“云”中使用Linux系统 这不是背叛

微软承认,使用Linux系统来运行自己的业务曾是不可想象的。 ? 微软Azure的首席架构师Kamala Subramaniam在上周四的一篇博文中提到: 微软...

1969
来自专栏SDNLAB

如何应对云网络中存在的问题与挑战(附DeepFlow白皮书下载链接)

在全球数字化转型的浪潮下,“上云”已成为企业数字化转型的主流选择,在赋能业务创新、弹性服务的同时,新场景给网络运维、网络运营、网络安全等方面也带来了全新的挑战。...

2053
来自专栏双十二技术哥

Android性能优化(十二)之我为什么写性能优化

从1月10号第一篇文章开始,到现在过去了4个月又20天,陆续写下了性能优化系列文章共计十二篇,大概一个月三篇的节奏。本篇文章是性能系列文章的最后一篇,没有新的大...

1062
来自专栏Java学习网

Google 的软件工程经验总结

软件开发 代码库 大部分的 Google 代码都存在统一的源代码库中,可供 Google 内部所有工程师访问。但是 Chrome 和 Android 则分别有单...

3884
来自专栏美团技术团队

从Google白皮书看企业安全最佳实践

前不久Google发布了一份安全方面的白皮书Google Infrastructure Security Design Overview,直译的版本可以参考“网...

4945
来自专栏云计算D1net

云计算服务提供商不能会告诉你的秘密

云计算具有成本、资源扩展、弹性大等优势,但任何事物犹如硬币具有两面性,云计算也有一些你必须知道的劣势,服务提供商是想要把你所在他们的产品上,但并没有强迫你维持忠...

3323
来自专栏腾讯NEXT学位

亿万级 Node 服务的秘密尽在 IMWebConf 2018!

? 对于有着极致技术追求的前端开发者来说,Node 无非是一扇新世界的大门。同时,它也是前端开发 “开阔疆土” 的重要利器, 其从最初的 “前端的玩具” ,到...

1501
来自专栏Java学习网

处境艰难的 App 开发者们如何自救

处境艰难的 App 开发者们如何自救 「因为这个行业太饱和了,障碍太多而且难以从中盈利。相比之下研发网页就容易的多。」 这是我朋友的公司不再研发原生 App 的...

2277

扫码关注云+社区