老王说：
今天我回到最底层的平台上，思考过去CMDB那么多失败的，这个失败原因到底是什么？是技术原因还是过去的运维体系设计问题等等从本质上来看，到底今天的CMDB应该怎么构建？
1、新IT管理需要强CMDB
在我最近的实践体系里，CMDB已经不叫CMDB了，我把它改成IT资源管理。今天的主题有四个维度，第一个是DevOps互换新的CMDB，CMDB模型怎么做，平台怎么做，最终这个东西怎么确保它成功地落地。
CMDB在ITIL时代是元数据平台，最重要的是大家常说的观点是过去的CMDB所服务的IT服务过程是一种离线服务过程，不是实时地访问线上变化。所以CMDB起到的作用是非常弱，很多ITIL的厂商流程是不需要的，流程和流转根本不需要CMDB来做。过去元数据平台的定位运营不起来主要是对于它的依赖度太低，我的ID服务过程是个离线服务过程不是和线上服务实时映照的，所以我不需要这样的CMDB。
今天不是这样的，今天是实时反应线上服务状态变化，就要跟CMDB所记录的状态实时同步起来，今天我们把服务和过去服务进行了划分：
1、分成服务支撑，把基础设施变成服务，从服务构建到服务运行再到服务运营平台，针对的是不同的领域。比如智能研发的服务构建针对每个角色能力管理的问题。
2、服务交互CMDB平台流水线交互出来，包含两种形态，一种是传统的应用架构模式，今天可能清醒的架构平台，最后就是讲运维这块，自动化体系、监控体系、流程体系。
所以，实时的过程需要真正强的CMDB做支撑。
这个方案今天在金融行业里总结了一种标准的实践模式，我同样从服务的角度理解，最上层的其实是服务门户。因为今天IT管理平台涉及到的服务非常多，我们需要统一的平台进行收敛，这个门户暴露出来的服务内容到底是怎么提供的？这里面就需要新时代的理念，具体的服务能力承载，这个服务怎么开通？需要底下各类的IT管理平台去支撑。比如说运维制度化，服务资源交互平台，应用交互DevOps平台，甚至我们在监控体系里有服务反馈的平台，这里面包含了自动化和数据化两部分。
这里面要依赖的基础就是今天的CMDB，CMDB最大的区别在这个图里，我提了一点，大家注意一下，叫应用CMDB。过去的资源视角面向基础设施，我们这么多人维护基础设施价值是什么？是为了线上的应用运行，再往前支撑我们的业务运行，这里面CMDB的价值点就找到了，就是怎么样支撑业务，这是整体的体系。
这里面强调的是我今天需要强的CMDB。
什么是强CMDB？今天还有很多传统制造企业，运维做CMDB，更多关注的是我手里的一盘账——台账资产管理系统，这个早就被翻过去了，今天新兴企业、金融、运营商等等的已经不讲叫资产了。第二个是CMDB的配置管理，其实它的管理边界太广了，纳入了很多东西都能叫配置，比如说一个文档都可以纳入到CMDB的范畴里，我觉得管理边界耐用过于扩散，并且有些东西纳入进来没有服务能力。
2、CMDB模型如何构建
今天的运维或者IT部门，我们注重所创建的对外提供服务的能力，资源比如像网络交换机，我为什么能对外提供服务，是有相应的端口资源。我就把这些东西管理起来就足够了，把边界缩小一点，把能力聚焦一点，这是整体思路上的重构。
整个模型设计的原则就是我还是要强调导向，面向用户的角色和面向生产的角色，需要做分解，面向用户叫功能业务，用业务视角分解。面向生产者是技术视角，比如拿着招商银行手机银行使用的里面的转账功能，手机银行里面的模块提供的。这个功能对应着后端一连串的关系，我们都能看到一个真真切切的应用实体存在，可以独立部署、独立运行，能提供一个或一组服务的集合运行体。
所以，应用是核心的承载体，这个应用系统是组成了上层的研发传递给运维的东西，所以这里面就是我把之间的连接点抓到，以服务为中心设计CMDB的体系。
我们今天讲，这里面有这么多的对象，我们今天DevOps能构成对外服务能力，我拿了基础设施的主机来看，对象属性，对象关系，对象生命周期管理，我的管理场景是什么，我就把一个对象，以及整个生命周期管理的动作构建起来，我同样拿了上层的应用，其实我们今天就可以看任何一个对象本质的东西构成它的属性，其实你们看我们的程序编写一样，今天看到程序有属性也有方法，有状态，状态里面包含了最重要的事件。我们今天看CMDB也是，必须这三要素构建起来（对象属性、对象关系、对象场景），否则你构建的CMDB只是数据管理的，是一个静态的CMDB，是没法有效运转的。
今天我们说这个模型怎么细化分解？我们要从上层应用，从产品到业务到应用的视角再看回来，我必须要知道资源被哪些应用用了，这是前面讲的模型构建原则的时候，我必须要把能力传导到靠近业务，一旦靠近业务之后你会发现CMDB创建的价值就体现了。
应用实体怎么来结构化地描述它呢？我们今天看到的就是几个核心，一个是部署资源，是一个安装的，我到底要包含哪些要素，这里面的要素必须要有相应的主机，我必须要有容器的集群，我的程序包，我的中间件等等我必须要有，否则我的环境是营造不起来的。
另外，我营造起来之后，我运行起来，我又依赖相关的资源是什么？可能是我对外提供的服务资源，我所依赖的后端，我可以把整个的资源拓扑全部构建起来，在外围辅助一些动作等等把它进行实例化。今天这个模型到底怎么带着业务化去理解它？
这一层视角，其实中间是架构视图从产品到业务到系统到应用，整个应用环境里面涉及到这个是数据中心的视角，里面有基础架构和PASS架构的一部分，从主机到依赖库，到应用程序包。服务资源包含两类服务资源，一类是我的应用对外提供什么服务，一类是这个应用运行起来依赖什么服务，我才能启动起来。
这样这个实体就变得鲜活了。传统的应用名称是什么，负责人是谁，非常简单的描述，就发现过去的建设思路是错的。
3、CMDB平台如何建设
CMDB平台怎么建？这里面建立一个管理核心的原则，你必须要让CMDB产生价值，必须要让以CMDB为中心。
1、应用CMDB必须提供统一的应用元数据管理能力。
2、应用CMDB建设的核心诉求是应用生命周期的管理，带来了整个管理的驱动力是最强的，这时候无论变更的频率还有以及对于一致性的要求都是最高的。
3、必须以应用为中心，不是基础资源为中心，这个视角大家要记住。
4、必须要从应用的角度构建IT资源的弹性关系，有两个层次，一个层次是我应用的模型和后端模型表达关系，我可以依赖DB，我可以依赖DNS，我A可能用了DB，我B没有用DB，这是弹性关系。
CMDB的两层逻辑架构设计，特别是随着组织规模的变大，CMDB介绍的方法和平台的思路都是不一样的，甚至这两个平台是分离的，比如腾讯技术架构的CMDB是机房IDC做的，这是在应用中间做一个交互就可以了。
今天我把CMDB不断地简化，不要让他承载太多的东西，因为今天外围的场景丰富其实不需要让CMDB过多地去管理。这里我就设立了几个核心管理要求，第一个是模型管理怎么样去适配不同的企业，不同发展阶段的管理需要，另外一个就是针对LaaS对象，这些对象之间的管理关系是什么，把这个管理起来就够了，这时候就构成了最底层、最基础的元数据平台，未来在这个平台上场景消费就好。
过去的IDS模式，关系数据库描述对象，刚才讲的结构化表达，以及关联关系表达，今天我们引用了数据库的方式来做，大家知道数据库用它来表达再合适不过了。今天南北向开放的能力，CMDB数据怎么进来，靠这种方向的手段是很多种，另外数据怎么对外围消费，你不能让未来一个系统来了定制开发，其实这个开发就是我讲的，任何的CMDB对象包含了属性、动作、状态，就把这个能力开放出去就够了，这个场景就不讲了，老生常谈，大家都在讲。
我要讲的核心就在这里，类似于地图型的应用，未来迭代的产品就是场景消费，只是应用的场景不同而已。
这个图在今天的图数据库已经不是太合适了，因为以前的关系数据库的时候其实你的表级别就是父子表、关联表达，我们做数据库设计的时候就是这样。但是从业务上的理解，应该有四种拓扑关系，第一种业务流的拓扑，快速级别的拓扑，这种级别CMDB可以承载的，但是数据来源要采用新的数据手段，不是靠人工维护的。这种细致的拓扑流带来的价值是最大的，维护的难度也最大。
今天也有其他的技术手段，在前面我也讲了，它的应用架构研发者一个新系统上线的时候，我的系统架构是什么样的，你帮我准备一些资源，描述的是访问关系。
部署视图就是我今天的应用被认为拿到了研发者之后怎么样部署到研究中心，这里面要被描述出来，最后就是架构到物理视图上，我放在一个虚拟机里面，这个母机放在机柜里面，这个母机关联了交换机，其实每层叠加的数据以及未来的用途是不一样的，大概的拓扑关系是这四种类型。
4、CMDB如何确保成功落地
最后是CMDB如何确保成功的落地，最重要的一点是确定CI维护的功能，过去CMDB一直跟大家讲你们要有配置管理员，我认为集中式的管理模式在我们今天写程序的时候都知道，集中式的管控模式不适合分布式管理的需要，所以我们如何把这个事情去中心化，我确定的每个CI必须要有一个功能，交换机有交换机的功能，应用机有应用机的功能，因为我们没办法掌握整个CMDB配置的正确性，那是靠外部联动的配置来做的。
在配置管理的要求里面，要引进一些对规范的要求，比如今天讲的应用CMDB，什么是系统，什么是子系统，什么是应用，什么是集群，什么是资源，最底层的描述有没有规范可言，到A企业是三级系统描述还是二级系统描述，还是一级系统描述，要有相应的规范。
流程对象整个生命周期管理的要求，比如说主机上架，服务器搬迁、服务器维修、服务器回收这是流程，因为有的东西状态转换要提前预知进行，比如这个机器挂了，你不知道它是挂了还是下线了，还是退役了，这里面有流程管理的要求。
组织你会发现这里面不同的组织对于CMDB实施的难度不一样，甚至你构建出来的模型也不一样。
这是生命周期管理的闭环，在前面对象识别生命周期特征的时候能识别出来，你建立的每个IT对象，那个状态的字段仔细去看，到底是什么样的动作或者流程促成状态的转换，我以前主机是空闲，怎么变成预留了，怎么变成使用中了，是流程完成的还是什么完成的，这样你就知道哪些是用流程来做你就很清楚了。
CMDB库我们认为是共享的数据平台，到底我们在多种场景下如何去用它，这里面是跟CMDB的关系。在去创造资源的时候，把资源开通流程放给云平台，云平台把资源创建完成之后，再有流程去CMDB，CMDB起到的数据总线架构作用，你任何底层的数据源发生的变化，不要通知外围各个系统，这里面有两种模式，一种模式是APR的模式是全量同步的模式，代价太高了。一天一次。
还有就是今天在某个大型银行里真正做到落地实施的，直接从统一的CMDB去拿数据就好了。数据员由我们统一各个来源的数据我们来去收集。从应用的视角，我管理了各类的资源、开发、测试到生产的资源，面向整个交付流水线，其实你们穿越的能力都是这些，什么集成构建、测试部署，无非就是这些东西，环境管理、配置管理、数据库管理，其实就是数据源的基础来自于CMDB，让它帮我们做整个平台的集成。
还有变更服务流程，过去我们知道有个问题太重了，我变更完了我自己还要修改配置，这是大家都不愿意干的，因为觉得流程都很重，又带不来效果，运维的事情特别多，这个事情没忙完，下个事情又来了，不可能把这个事情做完。
我们今天挑战模式的时候，直接在CMDB上叠加一个流程平台，再也不用以前老的OA流程模式，我直接去封装流程，直接跟CMDB之间的APR进行对接，在整个服务器变更的过程中修改我CMDB底层的数据，这里面就达到了我今天配置变更和配置之间的实时同步反应的变化，刚才也讲了，ITSM是在券商里面做的。
我们自己也总结了一些部门导向、数据导向、场景导向、服务导向、价值导向，今天挑战业界目标，怎么建立服务导向的CMDB，今天在一些银行里面，我们是做了这样的罗列。
最好的CMDB到底是什么状态？其实最好的CMDB是看不到CMDB，大家过多的关注CMDB数据怎么维护，怎么生成，我们今天在数据库管理平台里我们做一个尝试，大家是看不到CMDB的，这里通常举了一个例子，跟的研发部门都在讲，今天你们去进公有云的时候，你看公有云的服务方底下有CMDB，但是你们看不到，为什么能保证数据的准确性，为什么能做到下沉？是因为我叠加了对于资源的管理、对于动作的管理，对于状态的管理，已经变成了IT管理的一部分，这时候就是一个下沉的CMDB。
最后就没有了，我今天讲这么多，谢谢大家。
本次GOPS大会王津银的演讲PPT可看下方。
百度网盘：
链接：https://pan.baidu.com/s/1VfOqzIlLdN-zMbTxySouEQ
密码：cz1p