CMDB建设与运营的方法研究

龙源期刊网建设与运营的方法研究作者：赵樑来源：《科学与信息化》2018年第11期摘要无论是过去的ITIL体系，还是近两年盛行的DevOps体系，CMDB在其中的重要地位都众所周知。本文按CMDB的建设周期，从需求、设计、流程、平台、应用5个方面介绍了如何建设以及运营好一个数据中心的配置库。关键词CMDB；配置管理；配置模型；配置流程数据中心CMDB的建设，以及后续的良性运营，在业界一直是个难度不小的挑战。我从事CMDB相关工作将近十年，并有一个该领域的专利，目前维护的配置库有2.2万个节点，关系3.7万条，支撑七个流程的运转。基于这些内容，总结了五条经验如下：1广泛访谈，发掘同向诉求通常在CMDB建设之前，各类内容会以电子表格的形式存在在组织内部，是建设CMDB的数据基础。但这些表格分布在个人终端内，大部分人都不愿改变现状。得到最终用户的支持是建成CMDB的基础。因为他们不但消费这些数据，还承担数据维护的职责。CMDB是否能用好用，他们最有发言权，而这些信息是领导判断项目是否成功的重要依据。找到这些表格的使用者，详细了解每一列的含义，对下一步建立配置模型非常有帮助。同时，要从帮助他们解决的现实问题切入，找到建设CMDB的共同目标。比如最基本的EXCEL文件版本的同步问题；提供在不同的网段实时共享数据的平台；记录修改日志满足审计需要等。寻求领导的支持是建成CMDB的关键，这点毋庸置疑。访谈领导时切记说太多理论的东西，CMDB作为数据中心运营的关键支撑，这点领导应该比谁都更清楚。建议多提供一些数据，帮助领导下决心启动CMDB的建设。比如格式化的数据模型，能使事件处理时间缩短多少；基于配置项的分级管理，能给变更流程节省多少审批成本等。当然，CMDB最终还是要对部门的战略发展起到支撑作用，如果能助力领导期望推动的重点工作，那就能获得更多的资源投入。2设计模型，粒度适中可控配置模型包括三大部分内容：分类模型、属性模型以及关系模型。分类模型确定了整个CMDB的管理范围。收集需求时，可以奔着大而全的目标而去，但是最终定稿千万要注意取舍。一般来说可以分为四层，即基础环境层、设备层、软件层和业务层。环境层包括机房UPS、配电柜和空调设备等。设备层包括物理服务器、存储、交换机、路龙源期刊网由器、F5和加密机等。软件层是承上启下的核心，包括应用系统，数据库，逻辑服务器等。业务层包括对外服务和机构商户等。属性模型就是具体一个分类下需要展示的信息。需求梳理时，建议用“是否能自动采集？是否有统计价值？是否需要信息共享？”代替“这个属性是否重要？”举两个例子，一是对于版本信息，自开发的应用版本和操作系统版本，在属性模型中的处理方式就不同，我把操作系统的版本纳入的配置属性管理，因为在操作系统升级的时候，这是个重要的统计信息。而应用版本，与其他配置项基本无关，主要是单个应用在安装时使用，推荐直接写在相关脚本内读取。二是IP地址，它是最具代表性的、能自动获取的属性，这个属性在事件处理与变更实施中会发挥很大的作用，一定要纳入属性模型。关系模型主要是指分类与分类之间的关系，是CMDB发挥作用的核心。主要分影响性关系和拓扑类关系。将之细化，影响性关系可分为组成、直接影响或基于负载均衡架构上的影响。拓扑类关系可分为网络连接、应用调用和高可用。最后再次强调，构建模型时，牢记二八原则，把最重要的内容放进来。如果铺得太大，在收集数据的阶段，就会不全不准没人用，导致项目失败。3强化流程，保证全生命周期管理建立配置管理流程，明确在设备上电与应用上线的时候，同时新增对应的配置项。规定手工修改配置项，需要通过变更流程或问题流程来执行。对于系统间同步的数据，可以通过预授权来自动更新。设备下电或应用下线时，要同时废弃配置项。除了增删改三大步骤外，还要增加审计的控制点，规定每年对整个CMDB进行一次审计，每个季度可对某个分类或三个月内没有更新过的配置项进行审计。流程中可设置配置经理，配置项所有者，关注人，普通用户等角色。配置经理负责配置模型的修改以及审计的发起，配置项所有者负责配置项内容的日常维护，关注人与普通用户的不同之处在于他能够主动收到配置项变化后，系统所推送的消息。这些角色在平台设计时，是权限控制的基础。4平台建设，优先考虑易用性很多庞大的CMDB系统，最后烂尾就是因为功能复杂，用户使用时先要投入大量学习成本，阻挡了大部分潜在用户，导致最终默默消亡。因此，要特别强调平台的易用性。比如，查询功能要求点击2次输入1次，就能出现查询结果。可智能识别IP地址主机名应用名称和配置ID。对查询结果进行针对性的排序，提高首屏命中率。所有按钮都采用拟物化的图标，方便用户理解。在系统多次迭代后甚至取消了新建配置项的页面，只保留了批量上传的通道。龙源期刊网除了人机界面要简单易用，系统间的接口设计也是重中之重。除了后台管理功能之外，其他所有的操作都提供底层接口控制，才能有效解决数据更新困难的痛点，目标是脚本搞定一切。最后，在部署上要做到生产网，办公网，测试网共同访问一个数据源，当然做好权限控制是前提条件。5应用场景化，增加平台黏性平台建成后，一定会运动式的导入一批初始数据，如何保证系统内数据的“新鲜度”是CMDB运营过程中普遍遇到的难题。不断开拓消费场景，是保持CMDB良性运转的关键。代表性的场景就是与事件变更流程结合，发挥CMDB数据价值。比如在对服务器做变更时，通过关系模型自动算出受影响的应用和连接的交换机，并在变更实施过程中对目标服务器、交换机或应用的告警进行降级处理，不开事件单。日常监控开出事件单时，通过告警信息的切词处理，将其匹配到某一个配置项，这样就能将预设在配置项内的应急手册推送出来，同时显示48小时内相同事件和一周内做过的变更，以便一线人员排查问题，快速恢复。在跨领域的数据管理方面CMDB也能发挥作用，比如证书的有效期管理，网络设备、中间件和应用的证书对最终对外服务都有影响，分开管理隐患重重。建立以服务为主线的配置模型，可将各种证书管理要求有效整合。要像风投一样，A轮B轮C轮……不断投下去，CMDB才能枝叶常青。综上所述，前三点层层递进，确保建成后的CMDB框架能满足数据中心的实际需要；后两点相辅相成，是持续运营的源头活水，通过不断迭代充实，来保持CMDB的活力。