如何建设CMDB

最近大半年以研发的角色专职做基于 iTop 的 CMDB,现在基本可以宣告失败。复盘一下,如果能重新来过,如何建设一个不那么失败的 CMDB 呢?

选型

首先是选型,自研还是开源?

因为我们要讨论的是 “建设” CMDB,而不是研发 CMDB,所以我倾向于开源。CMDB 工具看似简单,好像就是个数据库增删查改系统,但是如果真这样去投入自研,建设 CMDB 的人可能会比较痛苦。因为大部分自研的运维系统缺乏设计和持续的投入,很难打磨出一个好用的产品。

那么,iTop , i-doit, CMDBuild, bk-cmdb, oneCMDB 等一众开源 CMDB 产品,选哪个好呢?首先 排除掉不活跃的 oneCMDB,开源版本不支持插件的 i-doit,剩下 3 个,进行以下对比。

产品模型继承建模方式/模型存储开发语言难度插件API
iTop插件/代码PHP简单支持支持
CMDBuild界面/数据库Java不支持支持
bk-cmdb界面/数据库Go不支持支持
三款开源 CMDB 的对比

模型继承是指面向对象的方式来建立模型,比如 定义 物理设备有属性 名称,序列号,资产编号 三个属性,定义 服务器,交换机 继承自 物理设备,这样 服务器,交换机就自动有了 以上三个属性。定义 人员 和 物理设备 有 N:N 关系,则 服务器,交换机 自动和 人员 建立了 N:N 关系。支持 继承 的建模方法,能够更容易的维护模型,否则 CMDB 建设人员在面对大量模型和属性时可能会比较苦恼。

建模方式/模型存储 一列,iTop 通过写 插件 代码来建模,插件编译成 PHP 代码,模型自身的属性不会存储到数据库,参见 CMDBuild试用总结 一文。另外两个 都是在界面上建模,模型属性会存储在数据库内。我倾向于 iTop 的代码方式,代码方式有以下好处:

  1. 代码更容易协作,容易记录模型设计思路,容易记录模型变更历史
  2. 代码方式定制性更强,能实现很多界面无法实现的需求
  3. 界面方式似乎在测试环境和生产环境之间迁移很不方便,如果没有良好的工具支持,就得手工重敲一遍?插件代码就完全没有这方面的问题
  4. 插件方式能够享受到社区成果。iTop 有很多优秀的插件,比如 TeemIp,基于插件能够极大的提高 CMDB 建设效率

难度一列比较主观。iTop Github主页这样介绍自己:A simple, web based IT Service Management tool,我认为基本成立,对比另外两个产品,iTop 有易于理解的概念,直观的模型设计方法,简单的关联关系管理。

因此,如果重新来过,我仍然会选择 iTop。

但是如果因为某些原因比如国产化政策不得不自研,那么可以考虑参考开源的来实现。当然,最好是参考 iTop,其次是 CMDBuild,最好别参考 bk-cmdb。

性能

性能没有那么重要,或者说,性能不是 CMDB 最首要的问题。

CMDB 主要管 IT 资产,绝大多数数据变动都不会很频繁,对并发写入并没有很大的需求。高并发读取倒是很常见,但是也不难解决,前面加一层缓解代理,就能很好的解决了。

用户管理

不要用 iTop 默认的 LDAP。

iTop 的 LDAP 需要事先添加 LDAP 类型的 User,不能自动创建。LDAP 同步方式又不够灵活,因此最好选择 CAS 或者 参考 CAS 插件实现 OIDC 登录。

组织要用起来,iTop 主要通过 组织来管理权限。由于 运维人员需要管理所有 IT 资产,需要能看到所有组织的 CI,应使用层级的组织,比如

运维人员可以在根(即Com)下授权,对应的业务部门则只授权其部门组织。

业务管理

CMDB 如果不是单纯管资产,想要用在更多的运维场景上(比如 成本核算,报警接收人查询),那么就一定要以业务为中心,即建立 资源 -> 业务 -> 人员 这样的关系,避免 人员 和 资源直接关联,这样能够减少关系的维护成本(比如容易交接业务,只需变更业务负责人,通过关联就能找到对应资源)。

业务管理的优先级高于资源 CI,应首先实现。

基于 iTop 现有模型,或许可以用 Organization, BusinessProcess, ApplicationSolution 来实现一个三级的业务树:

需要对 ApplicationSolution 做一点改造,将 BusinessProcess 和 ApplicationSolution 的 N:N 关系改为 1:N 关系,即 App 归属于固定的 BusinessProcess。

工单系统

如果使用了 iTop,我倾向于至少使用 iTop 自己的 UserRequest 来做 iTop 数据相关的工单,比如 新上线业务,业务负责人变更这样的需求,都应通过工单来自动更新 CMDB。

用工单,就一定要用 request-template 这个插件来支持自定义的表单,然后通过触发器做自动化更新 CMDB。遗憾的是此插件已经开始收费了,只能基于老版本自研了,难度未知。

场景优先

这大半年我的很大一部分工作内容都在导数据,从 其他系统导,从 Excel 导,从 CSV 导...

CMDB 作为记录 IT 资产配置项的工具,当然是越丰富越好,但这不意味着无脑往里面灌数据。如果不能很好的维护或者不能被自动化程序消费,那么费劲导入的大部分数据都将毫无价值。

因此,应以具体的运维场景为基础,按需开发自动化工具导入数据,尽量避免人工。例如 服务器,人工只需导入 SN,资产编号即可,剩下的都应通过程序自动采集。

避免干扰

比如 央行要求的金融业数据上报,对 CMDB 建设有参考价值,但是不太可能完全照搬,只需在设计模型时兼顾央行要求即可。上报这个事情应该是一个 ETL 任务,将 iTop 数据转换为 央行格式,而非为央行报送专门建设一个所谓 CMDB。

其他

复盘了这么多,并没有什么卵用。在一个 CMDB 能做上好几套的公司,只熟悉 iTop 是远远不够的。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注