CMDB最早可以追溯到ITIL时代。早期CMDB应用场景是为了消灭EXCLE，旨在解决 EXCLE 传统方式统计公司资产的方式。该方式一直至 公有云 IAAS 盛行时，依然很流行，是每家公司标配。主要原因有如下：
自动化运维建设正在成为很多企业当前或者下一阶段的建设目标。这其中，很关键的一个组成部分就是配置管理数据库（CMDB）。CMDB能否建设好是自动化运维建设能否真正落地的一个非常关键的因素。
针对CMDB这个主题，之前一直想写一篇文章来表达我的看法，但是之前一直不敢写，为什么？因为CMDB这个主题属于一提大家都懂，但是深入讨论大家都晕菜的一个话题；在2018年实施了几十个自动化运维项目后，我对CMDB的理解又进一步加深，因此想谈谈我对CMDB的看法。
CMDB作为配置管理数据库，有太多的事例证明其最终被沦为鸡肋，部分小伙伴对其也不置可否:
基于 Nacos 的强大能力，本文就来说一说 Nacos 提供的 CMDB 功能。
随着自动化运维的火热，CMDB建设项目不断的涌现，正是因为CMDB就是自动化运维的基石。关于CMDB的概念、定位、价值、与周边的关系、企业面临的痛点等，这里不做阐述，总结来说就是CMDB很基础、很重要又很复杂。本文直入主题，主要讲述CMDB具体应该如何建设，内容包括建设目标、框架和指引。
CMDB存储与管理企业IT环境中各种对象的配置信息，为运维场景提供配置数据服务，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值。
小张是一名运维工程师，负责做公司配置表格的维护。目前公司的配置信息以Excel表格为主要维护手段，他每天都要打开不同的Excel表格，表里密密麻麻记录着资产和配置统计等信息，根据当日的维护状况按时更新和维护。
awk 是处理文本文件的一个应用程序，几乎所有的Linux以及MacOS都自带这个程序。
我们知道CMDB最早来自于ITIL，后来逐渐被各种IT管理工具吸纳，成为管理工具的一部分。例如ITSM中有CMDB，网管工具有中有CMDB，监控工具中有CMDB……
A configuration management database (CMDB) is a central repository that acts as a data warehouse, storing information about your IT environment and it is a purpose-built database for configuration management.
从运维体系看，CMDB是运维数字世界的数字地图。运维组织规模小时，运维流程与协同可以通过线下沟通解决，随着内外部环境复杂度越来越高，线下协同的方式无法适应当前面临的挑战。运维数字世界的构建就是为了应对人员数量、系统数量、主机数量、服务数量、数据量越来越大，架构链路与沟通关系越来越复杂的挑战。从运维平台架构看，CMDB承担了描述运维对象的职能，CMDB是IT资源（设备、组件、系统）及其关系的数学抽象，是IT资源的“高德地图”，是IT运维及IT运营的数字基石，是运维工作展开的底层支撑。分析CMDB，首先从行业CMDB发展看看CMDB，大体可以梳理4段过程：
在今天，配置管理数据库（CMDB，后面均用这个简称，并且暂时不去区分CMDB和CMS）这个名词对于IT从业人员来说一点都不陌生，甚至有点烂熟了。无论是ITIL在企业落地、自动化运维、标准化运维、DevOps、端到端统一监控，甚至最时髦的运维大数据、智能运维（AIops）等都很难绕开CMDB这个概念。说CMDB是企业IT运维标准化、自动化、数据化和智能化的基石，相信现在应该没有多少人反对了。
CMDB，几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。那么到底错在哪儿了？该如何去重构它？
CMDB的好坏取决于其数据的质量。不幸的是,大多数CMDB都充满了过时的、不一致的或不完整的数据。
每次读到配置管理相关的书籍时，我总在想：“这些定义很精准，流程也很残缺，但这不是真正的难题。”对于一个配置管理者来说，真正的难题不是绘制“庞大而精美”的数据模型，不是design“全天候、无死角”的管控流程，而是如何促进数据的消费，并在消费过程中持续的改善数据质量。 我在华为从事了七年配置管理工作，见证了CMDB从一个半死不活的边缘零碎逐渐成为运维的核心。 离开华为后，我无机会看到很多CMDB项目，才发现原来像华为这样将CMDB真合理成运维中重要一环的并不多。大部分CMDB项目，不是以失败告终，就是在失
CMDB是一个较为老生常谈的问题，这一概念在很早时期就已经引入了国内，纵观运维数字化转型的整个发展过程， CMDB的建设是每个企业都必经的重要阶段。早期的CMDB往往只是为了提供运维流程的支撑，数据准确性得不到保障，运维依赖程度低，常常会出现“建而无用”等情况。然而随着数字化转型的不断推进，运维需要更高质量的数据，运维平台需要更高效可靠的支撑，CMDB作为运维基石是重中之重，也需要进一步的“修炼”！
前几天在对一个项目进行总结，编写CMDB的配置管理规范，发现还是有很多套路，本文就是老王总结的CMDB套路！
腾讯cmdb开源项目https://github.com/Tencent/bk-cmdb
配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
小魏是某银行配置经理，这天，银行部门年度会议上，运维领导突然说：“CMDB是我们整个自动化运维平台的基础，必须发挥好他主数据的价值，让大家尽可能都感受到他的价值，注意一定不能因为数据质量的问题导致大家不愿意用！”
据McKinsey（麦肯锡）发布的调查报告显示，目前企业数字化转型的成功率普遍仅为20％。导致企业数字化转型失败的原因多种多样，大多数企业的失败可以归咎于缺乏业务上的指引，盲目部署数字化系统和引进新技术，对即将出现的各种风险毫无防备。
当前，数字经济进入了高速发展的阶段，数字经济已经成为了引领经济的新增长点，全球范围的数字经济时代已经来临。尤其是在疫情期间，各地陆续颁发了推动和促进数字经济发展的相关政策与举措，以物联网、5G、大数据、人工智能等数字技术为支撑的新产业新业态将加快发展。
CMDB作为企业运维的IT主数据，在建设初期企业常常“报以厚望”，希望通过CMDB的建设，为IT运维体系的建设打好基础，为后续更多的运维系统提供数据支撑，提高业务连续性。但往往建设完毕后出现弃用、推广难等问题，根本用不起来，而原因一般都较为复杂。本文将从CMDB在两种应用场景中的作用，简单讲述为什么CMDB建设后很难推广使用。
在《运维产品家族揭秘》这篇文章中，大家对 TCE 运维平台有了一个初步的了解，今天起，我们将会给大家介绍运维平台上不同的模块，首先从 CMDB 开始。
关于CMDB使用过程中的一次总结，通过CMDB的认识、进化、流程规范支撑、运维场景驱动等方面的介绍，让我们快速了解
本文主要介绍运维CMDB的设计思路，恰当的CMDB设计，对运维效率的提升，如收敛告警和故障自愈等，有着意向不到的效果。
在过去5年，嘉为蓝鲸研发运维运营一体化方案已经在近300家企业中落地。企业类型涵盖了传统的制造、能源，也有互联网性质的互联网金融、游戏。那么，CMDB作为研运一体化方案中非常重要和基础的一环，它的设计理念应该是怎样的？
对大部分中大型的企业来说，CMDB建设对于整个IT服务和IT运维管理的重要性不言而喻，但是目前仍然有非常多的企业无法建设好CMDB。
CMDB模型最终是要实例化数据和关系的，正确的模型构建可以为多变的场景提供数据基础。
在上一篇文章《你所不知道的CMDB | CMDB起源与发展》中，我们谈到，CMDB的概念起源于1999年，但是在近几年才声名鹊起。本篇文章，我们将继续聊下CMDB的两类应用场景。
CMDB的建设是一个逐步完善、逐步改变的过程。在建设过程中通过数据运营的方式可以很好的辅助配置经理“监控”CMDB的状态，更好的发现问题和辅助决策。那么如何才能让CMDB的数据运营井井有条？本文将从CMDB建设的四个关键阶段详细介绍数据运营方法。
企业随着业务的发展以及新IT技术的不断引入，应用系统的IT资源规模是越来越大，IT架构的复杂性也与日俱增。这种情况下，需要通过多种监控系统，不同的途径来感知业务系统活没活，活的好不好，用户体验怎样。常见的监控系统类型就包括：基础环境监控、网络监控、系统监控、数据库监控、应用监控、用户体验监控等等。
CMDB（Configuration Management DataBase配置管理数据库），基本定义为是一个ITIL数据库，存储信息化软件和硬件资产信息，广义上包括流程、服务、人员组织。CMDB在企业中主要的作用基本概括为：
CMDB 是什么，作为 IT 工程师的你想必已经听说过了，或者已经烂熟了，容我再介绍一下，以防有读者还不知道。CMDB 的全称是 Configuration Management Data Base，翻译下就是配置管理数据库，它存储与管理企业 IT 架构中设备的各种配置信息，它支撑服务流程的运转、发挥着配置信息的价值。在今天，无论是自动化运维、标准化运维、DevOps、甚至是时髦的智能运维，其实都离开不 CMDB，可以说 CMDB 是运维体系的基石，有了配置信息数据库，后面各种标准、流程都可以建立在 CMDB 基础之上，从而实现真正的标准化、自动化、智能化运维，节约运维成本的同时，也降低运维流程混乱带来的操作风险。
摘要 今天我为大家带来的分享主题是新一代CMDB模型的构建指南，主要分为四大部分。 困境：当前CMDB模型面临的普遍困境 很多CMDB建设前期做得风风火火，而后期维护渐渐被开发、运维等角色抛弃，成为废墟。究其原因，部分是系统本身的各种因素阻碍，但更多是方法论问题，总以为找到了很强的驱动力来建设资源维护的流程和场景，其实都是自己的一厢情愿。 从常规部门的角度看，数据中心的基础设施部门统揽 CMDB 所触及的配置建设和管理，但是资源部门根本不关心（也无法关心）资源所关联的上层应用。整个问题看似走进了无解的胡同
这几年，IT运维的变化很快，新技术、新工具、新的业务也越来越多，根本原因是企业都在进行数字化转型，需要技术与业务的快速融合。由于大多数企业往往忽视运维支撑体系也需要数字化演进，导致许多企业的运维体系根本无法支撑整个技术底座的正常高效运转。而在运维数字化的发展路径上，CMDB的建设是一切的起点。本文将介绍新一代CMDB构建方法，能给企业带来哪些收益，来看看吧。
历史遗留问题导致CMDB (配置管理数据库) 数据错误,内网机器200多台,逐一核对显然太不现实; (浪费人力);
梁定安（大梁），运维技术总监，复旦大学客座 DevOps讲师。多年运维、运营开发和 DevOps 的工作经验，曾负责 Qzone、相册等 SNG 社交平台类业务的运维规划与管理，经历了 SNG 运维标准化、自动化、智能化建设的全程。腾讯织云负责人。 1 标题党一回！本文主要介绍运维 CMDB 的设计思路，恰当的 CMDB 设计，对运维效率的提升，如收敛告警和故障自愈等，有着意想不到的效果。 在运维自动化平台的设计理念中，我们一直提倡“减少运维对象”，并将运维对象进行抽象化、模型化、配置化的录入 CMDB 中
知识赠与好学人，本期打包了蓝鲸CMDB使用视频汇总，每个视频都包含了该产品的基础使用功能，快来看看运维大牛们平时都是怎么使用蓝鲸CMDB的~
数据库运维中的元数据建设都是重中之重，如果元数据不具有参考的价值，那么后续的操作都会受到影响，但是元数据的建设也应该是分成几个步子来走，首先得能够收集到元数据或者元数据的录入，数据有了后续做规范和标准化才有依据，否则还没开始接入数据就设定一大堆的规范和标准，接入的时候难免开始就会有一种排斥感；其次，数据的收集不能一次性追求最完整，最系统，一定是能够抓住重点，逐步来落实，否则刚开始设定的规范，到了后期集成的时候反复调整反复改，谁都受不了；有了数据，逐步来落实质量，这个过程就是逐步规范化的过程，这个过程中要把握的就是通用和定制的粒度，统一的模板，但是数据的意义可能会有所差别，这个平衡度就是关键。
CMDB：configuration management database，配置管理数据库。CMDB本质上是一个数据库，提供数据的存储、查询、校验等操作，是一个集中式的数据托管中心，托管的内容包含所有的软硬件资产（configuration items）。各个部门各个团队各个系统下属的各种重要的软硬件资产都属于CMDB统一管理的内容。
究其原因，我在《不是CMDB筑高墙，运维需要一定的开发能力！》一文中已经介绍，在此我再简单重复下：
The Common Service Data Model (CSDM) is a standardized set of terms and their definitions that can be used with all ServiceNow products.
ITIL就是IT基础架构库（Information Technology Infrastructure Library, ITIL，信息技术基础架构库），由英国政府部门CCTA在20世纪80年代末制定，主要适用于ITSM（IT服务管理）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。
企业构建一站式运维平台的目的是为了提升运维效率。那么一个成熟的运维系统应该要解决哪些问题呢？笔者认为首先是运维对象要被管理起来，然后是监控这些对象，接着是这些对象的自动化运维，最后是所有的运维操作都要有所规范。概括起来对应的系统就是CMDB、统一监控、自动化平台、ITSM，如下图所示。
近一年来，嘉维蓝鲸自动化运维解决方案成功在数十个客户处成功落地，同时也和上百家客户沟通了自动化运维的需求，有大量的用户会问我三个相同的问题：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
