CMDB 定位：从应用本质启动CMDB项目

　　提到CMDB相信很多人都是有爱有恨，爱的是他给我们提供了一个美好的未来，有了CMDB我们可以解决诸多运维中的难题。狠的是一旦进入了实施阶段像是开启了一个潘多拉的魔盒。各种问题随之而来。原因有很多种，但笔者认为最重要的一点是：没有对CMDB的应用有清晰的定位，建设内容过于理论化而脱离实际应用场景，导致CMDB项目仅是为了理想中的CMDB，而不是面对事实，解决实际工作中遇到的问题。根据笔者以前实施过的CMDB项目归，纳出CMDB建设中常见的本质应用场景，每一种场景都有对应的成熟产品，但在市场上还没有遇见过有哪一家的产品能够搞定所有的应用场景。期望我们在CMDB项目启动前，先抛开众多的实施方法论，而是聚焦于“要什么”的本质问题上。期望在建或未来计划建设CMDB的组织，能首先明确CDMB建设的本质应用场景，必将能事半功倍。

统一资源管理中的CMDB

使用目的：

  CMDB源自于ITIL中的概念，ITIL最终给CMDB的定位是运维的基石，通过CMDB可以实现对IT资源的统一管理，实现各IT运维岗位的信息共享，以辅助日常故障处理、业务系统上线、业务系统变更等日常运维业务。由于ITIL 以流程为核心，因此，此时的CMDB需要能与流程进行强关联。通过流程来驱动CMDB中数据的生产与消费。最终确保CMDB中的数据实时、准确。

使用场景：

在统一资源管理目的下的CMDB主要用于运维规模较大，各IT岗位分工明确，有清晰的业务系统管理、应用软件管理、主机管理、网络管理、机房基础设施管理的中大型IT规模的运维机构。因为在此场景下每个岗位都有自己的管辖范围，且管理的深度深、管理颗粒度细，此时每个岗位都是运维数据的生产者，但面向客户的对外业务是统一的，因此一但有一个新业务上线或者一个业务出现故障，那么在没有信息共享的前提下，申请资源和故障排查就是一个大问题。因为分工的原因导致基本没有人能了解整个IT的架构或运维的全貌，这就需要有一个资源共享系统把各岗位的资源数据聚集在一起，岗位间协作的目标是：对外提供业务服务，并通过ITIL的各类流程协同在一起，流程运转的过程也是运维数据产生的过程，因此就出现“伴随是数据生产”。即在业务运维中实现CMDB数据的生产和消费。

解决的问题：

这种场景下CMDB能解决以下几类问题：

1. 解决IT资信息源分散在各运维岗位手中形成的信息孤岛问题，此类项目可以将各岗位手中的IT资源信息表格个人信息，转化为团队信息。
2. 解决IT资源信息的实时性问题，在没有流程与CDMB结合的场景下，运维人员在完成其他岗位的业务请求后，往往不会立刻记录下这个变更，通常先记在脑子里，有空再整理成文档。这就可能造成信息的更新不及时，甚至遗漏。
3. 解决CMDB数据收集难，更新不及时问题；传统在ITIL理念下的CMDB信息收集，需要专门的角色去负责数据的收集与整理即配置管理员，但这些信息又分散各岗位，无形中增加了各岗位的工作量，其在完成业务的同时还要分精力完成信息的整理上报，这也是很多CMDB失败的重要原因。而业务流程一旦和CMDB强关联后，可以在业务流程办理过程中完成CMDB信息的收集。

关键系统功能要求：

1. CI 模型的自定义功能； 此时CMDB应该有非常灵活的CI模型自定义功能，要能够支持CI分类创建、CI属性自定义、CI关系自定义等。需根据实际业务的管理深度不同对模型的要求也不同，比如数据库实例、中间件应用端口、IP地址都可能成为CI。因此如果使用传统的内置CI模型库的方式很满足CMDB数据模型构建的要求。
2. CI属性间复用； 统一资源管理下的CMDB的建设核心是信息的共享，目标是保证信息的实时性和准确性，如果信息的正确性不能保证，那么也就失去信息共享的价值。因此为了描述一个完整的CI对象，需要多方的信息支持。比如描述一台服务器，必须要有操作系统信息、安装软件信息、IP地址信息，机房安装信息等，这些信息会有多个岗位负责和维护，一次按照“谁生产，谁维护”的原则，就相当于需要将生产这些信息的岗位共同维护服务器CI的信息。当发生更新是能实时反馈到这台服务器模型上。这就需要CMDB系统支持引用各CI分类的属性信息。
3. 流程与CMDB的强联动； 为了能够达到在业务运行中完成CI实例信息的动态录入与收集，就需要业务流程能够与CMDB强联动。如：业务系统上线流程执行完成后，就涉及到新CI创建，IP地址、服务器、网络端口之类资源的占用等情况，这就需要流程中的录入信息能时刻牵动CMDB中的数据的更新。当然还有更加复杂的流程与CMDB的操作如下：

实施建议：

笔者认为，当前大部分的ITIL咨询机构、网络上CMDB建设经验分享，大多数都是在描述CMDB的统一资源管理应用场景，而这里场景又是CMDB建设中无论是应用单位的组织成熟度、项目管理控制力，还是CMDB软件供应商的产品灵活性、实施能力都有极高的要求。而起产生的业务价值往往很年再短期内呈现，因为涉及的岗位众多，一期的项目不可能满足所有岗位的需求、解决所有岗位的所有问题，但又要求所有岗位参与，因此遇到的阻力也是最大的，因此如果之前从没有实施过CMDB或没有迫切的统一资源诉求，切忌启动全员的统一资源管理定位的CMDB。

资产管理中的CMDB

资产管理的概念比较大，涉及的范围也比较多，有专门的管理办法和管理标准来对资产进行登记管理，如：GB/T 14885-2010（固定资产分类管理）、GB/T 31360-2015（固定资产核心元数据）、GB/T33172-2016 （资产管理 综述、原则和术语）、GB T 33173-2016（资产管理管理体系要求）等。一般意义上资产管理由设备管理部门和财务部门共同管理，财务部门负责管理资产的：编号、名称、原值、月折旧额、净值、月修理费等，为财务部门推行电算化管理固定资产奠定基础。设备管理部门从设备使用、保养、维修的角度管理固定资产。原则是要求设备管理部门与财务管理部门管理固定资产口径一致。但实际运行中会存在偏差，导致在系统建设阶段往往是两套系统。我们本文介绍的是用CMDB的相关功能从设备管理部门视角对固定资产中的IT资产进行资产的生命周期管理。

使用目的：

从IT设备管理部门的需求视角看，目的是：从采购、入库、领用、出库、归还、报废等视角对设备进行全寿命周期的台账管理。

（台账：英文是standing book，原指摆放在台上供人翻阅的账簿，它不是会计上的术语，是各个业务部门用于管理、统计本部门日常工作的各种文本、文件、资料的统称。）

使用场景：

从笔者接触的大量实际实施的项目来看，在大多数政府、部分央企等IT管理应用场景来看，很多项目都是以CDMB建设来立项、招标，但实际落地时用户需要的往往是IT资产的管理，这类用户的IT特点从运维工作的分工维度来看，用的IT运维是有自由IT运维团队和合作伙伴/供应商运维团队联合运维，自由运维团队负责基础资源的维护、供应商/合作伙伴负责上层应用系统的维护。因此其对应用与IT基础设施的资源管理耦合度相对角度，不需要复杂的业务应用拓扑（CI关系拓扑）、复杂的CI关联关系（用于业务关联影响分析）、CDMB基线、CMDB回退、联邦调和等CMDB业务功能，其典型应用场景如下：

1. IT资产的台账管理；

主要涉及对IT设备/IT资源的台账类型的信息登记，如购买信息、安装信息、使用信息等，其管理的设备颗粒度基本都是以物理设备为主，不涉及到对应用系统的实例，如应用系统的部署情况、中间件实例、数据库实例的管理，而仅是对其进行资产维度的信息登记，目的是对现有IT的规模、使用情况进行信息管理，目的是使用该信息对IT的投资的效果和未来投资决策提供决策信息。

1. IT资产生命周期流程化管理

基于IT资产管理的本质需求，为了确保IT资产台账数据的实时性和准确性，需要对IT资产的生命周期内业务相关流程进行管理，如与IT资产相关流程：入库、出库、资产申请、资产转移、资产归还、资产调配、资产报废、资产盘点、资产维修等；IT运维类相关流程：IT设备上/下架管理、IT设备上/下线管理、IT设备巡检等。这样就要求IT资产管理模块需要与运维系统的流程进行管理，但需要的功能与流程与CMDB建设有很大的不同，在资产管理环境下流程与IT资产管理的联动效果主要体现在不对资产的新增、删除，对资产实例化数据的属性修改，如使用人、安装位置等，而不关心资产和资产间的关联关系或者说不是建设的重点。

解决的问题：

1 ) 建立电子台账，解决IT资产数量庞大、人工管理难
　　IT资产的数量非常庞大，再加上IT资产是一项新兴的产业，所以目前在管理上并不是尽善尽美的，仍存在着不少问题。那么，对于IT资产其数量多，不能进行分门别类管理，而且管理人员不知道如何进行有效的IT资产管理，就会使得在管理上出现混乱，不能很好的利用IT资产。
　　2 ) 强化流程管理和执行效率，解决“重采购、轻管理”的问题
　　IT作为一项重要的新技术，有着非常重要的作用，很多组织为了在竞争中站稳脚跟，就对IT资产进行购买，而且购买的数量非常多，认为只要拥有很多的IT资产就能够在竞争占据优势地位。其实不然，对于IT资产管理不重视，在管理上疏于管理，使其IT资产在管理上不到位，这就使得各项IT资产没有发挥各自的功效。
　3）IT资产盘点耗时长、成本高

　　由于IT资产的数量非常庞大而相关管理人员数量偏少，对其IT资产不是非常了解，因此，在盘点的过程中浪费了大量的时间。找不到很好的规律，对于盘点不能按照一定的顺序进行盘点。因此，就使得盘点工作人员花费大量的时间，且效率低下。

　　再者盘点成本较高，在对IT资产进行盘点时，由于所耗费的时间多，因此也就无形之中增加了盘点的成本。在盘点过程中，工作人员找不到一定规律，加上数量多，这就使得盘点成本增加。

关键功能：

1. 资产台账功能

需要为每台设备建立一个资产档案，能清晰记录其资产配置详情和使用情况。

1. 资产管理相关流程

为了确保资产台账的准确性和提升资产使用的效率，有相关的业务流程对整个IT资产的过程进行管理，包括入库、出库、领用、归还、调拨、盘点等功能

1. 资产统计功能

强大的资产统计功能是进行有效管理决策的基础，因此要求支持灵活的资产统计功能，包括按照类型、位置、部门、人员、年限等维度；

可视化管理中的CMDB

使用目的：

收集各系统平台的业务信息，通过综合建模的方式把某个业务对象进行可视化的展示，比如3D机房可视化，应用系统可视化、生产制造系统的可视化等，本质目的是呈现IT的价值。

使用场景：

可视化的应用场景非常的多，基本可说“万物可视”也就是大家所说的大屏展示；场景的是：

1. 资源分布呈现； 资源的结构可能比较复杂，难以用语言表示清楚，此时需要通过图形化的方式来进行可视化的展示。如3D可视化机房展示、应用架构图。
2. 运行监控类；为了了解系统、设备、交易的实施运行状态，需要将各模块、各系统中的数据汇总起来，组合为可以了解监控对象运行的指标的汇总系统。如银行的交易系统可视化、淘宝双十一中的交易可视化、各工厂中的设备运行可视化等；

解决的问题：

   此场景下其数据的本身并不需要生产数据，仅需要把多个设备、系统的数据收集过来并能按照预定的展示模型进行展示即可，因此需要能解决数据层面几个关键问题：

1. 能够快速的建模；可视化需要支持的展示对象可能差异非常大，因此就要求系统能够快速的根据使用人的要求快速的把展示模型和展示指标展示出来。
2. 数据的收集与治理； 此类CMDB本身并不需要支持上层应用生产数据，仅需要将分布于不同设备、系统中的数据收集回来并通过过滤、清洗、转化等过程达到可以综合展示的要求；

关键功能

此类系统80%以上的都是通过定制化的方式来实现的。少部分会采用第三方可视化系统，因此此处的功能要求主要面向与采用可视化平台中的数据治理能力的要求功能：

1. 1. 业务的快速建模
   2. 丰富灵活的接口
   3. 数据的综合治理

运维自动化中的CMDB

运维自动化的范畴非常广泛，但场景分系统运维和应用运维的自动化，因此本次分析的也是这两类应用场景。要做自动化实施首先得有准确对称的数据，然后需要一个统一的管控平台，能并发的控制和操作远程大量主机，这解决了OS层面的操作问题，但需要管理应用层面的东西还需要与应用的研发人员规范相关接口，这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化，笔者认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上，可以针对运维各类场景和业务逻辑去做相应的垂直功能系统，再上一层，可以使用流程引擎之类的组件来实现业务运维流程的纵向整合，最终实现运维各类业务流程的纯线上自动化，这部分要参考DevOps的相关内容。

使用目的：

减少人工干预  降低人员成本  对于运维执行工作而言，绝大部分的实现均是对运营环境的各类操作，在业务体量上去后，需求导致的运维操作密集度不断增加，如公司内某款游戏业务部署在近上百台主机上，一次维护要对此上百台逐一进行相应的操作，如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是：

现状	问题
应用类型各异	如何跨平台，如何固化并复用运维操作任务
设备数量越来越多	如何集中地并发地批量操作机器
操作需求增多	如何在分布各IDC的机器上批量执行脚本任务
操作类型日益复杂	如何向大规模分布的机器上分发文件
业务场景各种各样	如何根据运维需求任意编排任务并行执行

使用场景：

1. 故障处理自动化

此应用场景是通过实时发现告警，预诊断分析，自动恢复故障一系列操作步骤进行集成联动，实现对于已经有明确故障处理方案的处置进行自动化的故障处理，实现故障的自愈。 常见的可以自动化的故障有：磁盘清理、调用预定义的作业脚本、自动化替换备用资源上线、设备重启等。 而这一场景的执行与落地，就需要清单的CMDB做支持，必须对需要自动化操作的对象进行合理的CI类别和CI属性的设计，并记录其关联关系，以便进行批量执行脚本、特定设备的重启命令、CI关系的重新更新等操作。

1. 应用部署自动化

此场景下主要是运用DevOps的理念，基于统一资源CDMB，运用自动化工具，实现软件安装自动化，应用部署自动化，如：运维人员可以在界面定义好一个版本发布作业：xx业务发布，分解整个发布流程中到每一步骤，并写脚本或调用外部接口来实现具体的操作，最终线上操作只需在页面点击开始执行就可。

如下图的操作自动化执行步骤：

序号	步骤名称	步骤类型	步骤执行人	状态
1	查看单据及更新说明	文本步骤	人工执行	执行完成
2	分发服务端更新包	分发文件	系统自动执行	执行中
3	关闭游戏进程	执行脚本	系统自动执行	未执行
4	关闭防火墙	执行脚本	系统自动执行	未执行
5	优先程序备份	执行脚本	系统自动执行	未执行
6	DB备份	执行脚本	系统自动执行	未执行
7	服务端程序更新	执行脚本	系统自动执行	未执行
8	DB更新	执行脚本	系统自动执行	未执行
9	开启游戏进程	执行脚本	系统自动执行	未执行
10	开启周边系统	执行脚本	系统自动执行	未执行
11	确认成功开启	文本步骤	人工执行	未执行
12	通知内测	文本步骤	系统自动执行	未执行
13	正式对外	文本步骤	人工执行	未执行

解决的问题：

1. 平台与业务逻辑解耦

理念来源于ESB，业务众多、操作逻辑各异,不可能做一款产品融合所有具体操作逻辑,平台不是去做工具箱,而是要做成统一通道,通过运维熟练和无比灵活的脚本去屏蔽业务和场景的差异性,平台只做好执行引擎的角色,如此避免重复无休止的开发工作。

1. 共性提取去重

在业务形态多样的今天,游戏、web应用等多业务环境是常见的,纵观运维的工作,最最基本的需求无非就是对某台或一批设备进行某些技术操作,这个需求对所有业务形态都是样的, 也正是平台要作为统一解决方案的理由,满足基本共性需求,差异化的东西给用户自由定义。

1. 最大用户自由度

只作为平台通道、执行引擎而存在,那么用户要做什么,对哪些对象实施,包括如何实施均可由用户自己定义,这一点正是要解决众多业务，场景各异的差异化运维需求，是将操作-批设备变得跟操作一台设备一样快捷简单;将维护数款业务跟维护一款业务一样轻松。

1. 持续集成

自动化体系的建设需要整体规划, case by case的方式终归会导至平台之间相互割裂的问题, 作业只是整个自动化体系框架中的一环，其需要整合其它平台的能力,同时也可被其它平台调用和集成。

关键功能

1. 1. 1. 可扩展、高灵活性的CMDB建模功能，可以应对个性化、复杂的业务模型
      2. 良好的scale-up/scale-out，灵活扩展，支持复杂网络结构
      3. 轻量级、高效的后端通信机制，成千上万的管理规模
      4. 跨平台，支持windows、unix-like多平台，无需重复开发
      5. 对运维操作进行建模，将其分解为几大原子操作类型，一切复杂的序列化操作逻辑可通过原子的自由组合来实现，给用户提供自由灵活的操作方式

总之，CMDB建设是首先明确定位、统一规划、持续迭代的项目，而明确定位和使用场景又是重重之中，切忌盲目模仿，导致大量无效工作和无效功能建设，没有解决好期望解决的问题，反而引入了更大的问题，这也是导致CMDB项目失败的重要原因之一。

笔者将自己项目中接触到的几类CMDB应用场景进行总结，期望抛砖引玉帮助大家找到真正想解决的问题，选择合适的平台和系统，避免走了弯路。