金融企业CMDB建设实践｜证券行业专刊2·安全村

摘 要： CMDB是一个既熟悉又陌生的概念，作为技术管理者一定听说过CMDB，但对CMDB的实际应用不一定有深刻了解。笔者在CMDB建设和使用方面具有多年的实践经验，本文采用通俗易懂的方式进行讲解，场景化的应用实践介绍，希望能给大家在建设和优化CMDB时提供参考。

**关键词：**团队协同 运维合规 开源CMDB 技术部门数字化转型

一、CMDB是什么 
-------------- 

图1：某百科对CMDB的定义

上图是某百科对CMDB的定义，笔者认为存在明显的错误，经过反复思考和结合实践，笔者总结出以下三点内容，是否比某百科更好理解和更准确，由读者进行评价。

第一、CMDB是一个逻辑数据库，存储和管理需要管理的对象（专业术语叫配置项Configuration Item）和对象（CI）之间的关系。

第二、CMDB的内容要被使用，能发挥信息的价值。使用者可能是某个业务系统、可能是本人、可能是团队其他成员。

第三、CMDB必须有流程或机制来更新信息，保证信息的准确性。可以是自动的，也可以是人工的。

图2：关系树示意图

如果文字不好理解，笔者画了一张关系树，这张关系树包含系统台账、硬件台账、软件台账、数字证书台账、人员台账、供应商台账、应急联系人台账、合同台账、机房台账、机柜台账、IP地址台账等等管理对象。这些对象之间是存在关系的，例如应用系统分配多少台服务器、部署多少软件、使用多少张数字证书、等级保护是几级、软件供应商是哪家、是否有维保服务商、维护负责人是谁等等。这些全部要存储在CMDB中进行管理，对外提供服务接口用于数据查询和数据更新。

图3：数据表结构和关联关系示意图

如果关系树有点抽象，笔者给大家展示数据库中落地实施的数据表和关联。数据表就是台账，例如资产台账包括资产编号、品牌型号、序列号、硬件配置、操作系统、IP、到货日期、启用日期、运行状态等自有属性，机房、机柜、应用系统、部署软件、数字证书、主岗、备岗、供应商等外部属性通过关联进行建立。

===

===

**

二、为什么要建设CMDB

**

建设CMDB是外部监管机构的要求，也是内部团队协同工作的基础。

证监会2013年发布的《证券期货业信息系统运维管理规范》(现行有效)明确要求证券期货机构应建立配置库，对交易业务系统的服务器、存储、网络、安全设备、操作系统、应用软件、数据库等进行管理。

图4：证券期货业信息系统运维管理规范的配置管理要求

金融企业随着规模的不断增长，信息系统数量和技术人员数量也不断增加，原有的电子表格台账存在无法关联、更新不及时、无变更记录、不支持高并发访问等短板，已无法满足团队高效协同工作的要求。很多工作需要应用系统管理员、存储系统管理员、基础架构管理员、网络安全管理员共同完成，CMDB就是团队高效协同工作的专家系统。

===

**

三、如何选择CMDB

**

目前除了自研CMDB外，采购商业软件和使用开源软件都是较好的选择。对于经济实力雄厚和对CMDB有着较高要求的金融企业，可以优先考虑商业软件；对于系统建设比较谨慎和技术人员爱好研究新技术的金融企业，可以优先考虑开源软件；对于无法投入数十万以上采购商业软件，又无技术人员研究开源软件，可以优先考虑外包方式（开源软件＋技术服务）。

===

**

四、如何建设CMDB

**

使用开源软件是建设CMDB的一种方式，笔者使用一台较低配置（4核8G内存60G硬盘）的虚拟机就完成CMDB的部署，部署时间小于2小时，内存增加至12G可作为办公系统支持30位人员的并发访问，增加服务器可实现高可用架构。

图5：开源CMDB版本信息

CMDBuild软件是由意大利团队维护的开源项目，初始版本发布于2006年，每年保持一次以上版本迭代。目前最新版本是3.4.1，发布于2022年9月30日，支持私有化部署，已支持全球32种操作语言，是被认可度较高的开源CMDB软件。在官方网站有应用软件、技术手册和说明手册等提供下载。

===

**

五、如何使用CMDB

**

CMDB的使用一定要场景化，实实在在地将CMDB用起来，发挥CMDB的价值。本次介绍3个场景，笔者实际已使用包括应用管理、运维管理、项目管理、基础架构管理、安全管理、资产管理、综合管理、供应商管理等的20多个场景。

（一）资产台账管理

图6：资产台账管理界面

CMDB的发展源于资产管理，目前已涵盖技术管理的方方面面，具体管理内容取决于管理者的管理需求，本次介绍的第一场景从资产管理开始。

资产管理的基础功能是实现资产台账的线上化，将原来保存于电子表格的台账导入到系统中进行管理，这是高级资产管理的基础。在电子表格的时代，资产台账由资产管理员进行独立管理，记录在一张资产台账里，例如服务器功能这项是他无法管理好的，因为决定服务器功能的不是硬件，也不是操作系统，是应用软件，应用软件由应用系统管理员进行部署和管理的。使用CMDB能很好解决上述问题，将服务器信息的管理职责进行拆分，各自负责职责范围内的内容，真正实现团队的高效协同。

图7：资产台账卡片界面

资产管理员对服务器的资产编号、品牌型号、序列号、硬件配置、到货日期、启用日期、所在机房机柜位置、运行状态在“卡片”内进行维护，不涉及使用功能，详见以上截图。

主岗备岗可同时操作，数据修改立刻生效，可以避免主岗和备岗在信息方面存在差异。也能有效规避将不合适的责任分配给不具备权限的人员进行承担，更好地实现权责对等。

图8：资产台账与其他管理对象的关联展示界面

应用系统管理员专注于服务器的使用功能信息，动态形成“关系”，详见以上截图。

例如某系统被分配了服务器，应用系统管理员建立一下“系统名称”与“所分配的服务器”的关系。应用系统管理员部署了应用软件，填写软件部署信息，建立一下“应用软件”与“运行的服务器”的关系。应用系统管理员部署了数字证书，填写数字证书信息，建立一下“数字证书”与“运行的服务器”的关系。网络安全管理员发现了一个安全漏洞，填写漏洞管理信息，建立一下“漏洞信息”与“运行的服务器”的关系。

通过截图能清楚了解到此服务器分配给2个应用系统使用，使用一张数字证书，有效期到2023年3月28日，曾经出现2个系统漏洞，曾经出现1个技术问题，部署2套应用软件。这些都是通过关联的方式自动形成的，建立关系时自动添加，关系解除时自动消失。

特别说明：金融企业不会在一台服务器上同时运行交易类和非交易类的应用软件，也不会将交易类和非交易类的服务器放置在同一个DMZ中，分层分区是基本的安全管理原则，上述举例是希望向读者展示CMDB的功能。

图9：资产台账全部历史记录界面

CMDB系统的审计功能是非常重要的，在一定程度上保障了数据的准确性和更新的及时性，在“历史”中展示，详见以上截图。

审计记录可以详细记载数据的全生命周期的变化，什么时候、由谁进行登记或修改、修改的最新内容都全部进行记录，这些记录是永久保存的，而且查看特别方便。

如果与部门的管理制度进行结合，要求系统管理员在更新CMDB后到OA流程中进行反馈，系统管理员就没有了偷懒的空间，因为审计信息将如实记录他的相关操作(操作内容和操作时点)。

“误改”是人工更新数据所绕不过的话题，如果有上述强大的审计功能，发现信息被误改是可以很容易纠正的，因为历史数据都在，可以实现秒级找回。如果是原来的电子表格台账，历史数据已被覆盖，修改时间也不知道，能否找回都是一个问题。

场景小结：基于CMDB，资产管理的职责被正确地进行拆分，资产管理员负责硬件管理，应用系统管理员负责功能管理，各自负责维护好职责范围内的内容，确保数据正确和更新及时。在管理实践中，需要规章制度明确更新CMDB的职责要求，在处理OA变更流程时如遇到资产信息变化需反馈更新CMDB的大致内容，确保CMDB资产数据得到更新，准确的CMDB资产数据才有价值，才能支撑技术管理工作。

（二）应用系统管理

图10：应用系统管理界面

“应用系统”是技术管理的工作重点，技术部门的多数岗位都是围绕 “应用系统”开展工作的，现在介绍“应用系统管理”场景的使用，看看基于CMDB如何支撑团队进行高效协同工作。

图11：应用系统与其他管理对象的关联展示界面

如以上截图所示，通过“卡片+关系”的方式实现对应用系统的360度画像，真正全面了解应用系统才能管理好应用系统。

作为应用系统管理员，是否真的了解所管理的应用系统？如果说主岗了解，备岗是否同样了解？我们希望在应用系统信息方面，主岗和备岗能达到一致的水平。

“卡片”内的信息由应用系统管理员负责维护，应用系统管理员主岗也未必熟悉相关信息，例如无法给出系统“上线日期”的正确日期，原因是前任维护人员的交接资料里没有系统上线日期，借助维护“卡片”信息的机会可以对系统信息进行补正，是一劳永逸的工作。

“关系”内的信息由相关管理员负责维护，系统定级信息由安全管理员关联过来，存储信息由存储管理员关联过来，维保信息由合同管理员关联过来，漏洞信息由安全管理员关联过来，数字证书信息由应用管理员关联过来，问题信息由问题登记者关联过来，主岗备岗由负责主管指定并关联过来等等，关系解除时自动消失。

图12：附件展示界面

“附件”是每条信息都具备的属性，可以根据需要进行管理，例如在应用系统里可以上传“系统验收报告”、“系统功能测试报告”、“系统用户手册”等附件，需要时可以快速进行阅读和下载。

基于网络带宽和用户体验的考虑，笔者一般设置单个附件大小上限为30M，数量不限，基本能满足使用要求。

场景小结：通过使用CMDB，技术部门人员能比以前更加了解业务系统，知道业务系统的基础架构信息、系统管理员信息、安全信息、维保信息、供应商信息、联系人信息等等，当然这些信息是所有人员一起贡献、知晓和维护的，真实而且及时的，所有各岗位的技术人员能形成合力，消除潜在的风险隐患，共同保障应用系统的安全高效运行。

（三）供应商管理

图13：供应商管理界面

“供应商管理”是技术管理的工作之一，在《证券期货业信息系统运维管理规范》明确要求证券期货机构应定期收集、更新供应商信息，组织对供应商的服务质量、合同履行情况、人员工作情况等内容进行评价，形成评价报告，并跟踪和记录供应商改进情况。

金融企业一般不会建设独立的供应商管理系统，或采购OA系统中的供应商管理模块，使用CMDB进行供应商管理是比较合适的解决方案。

图14：供应商与其他管理对象的关联展示界面

“卡片”内的信息由初次引入供应商时进行登记，主要包括供应商的基本信息。在登记之前可以将供应商信息表格提交到部门领导进行审核，完成供应商入库审批，供应商信息表作为附件进行上传。

“关系”内的信息全部通过关联自动生成，可以动态展示与该供应商签订的合同信息、该供应商为本企业提供的应用系统清单、目前提供哪些系统维保、业务联系人、技术联系人、历年的考核评价信息等等。

场景小结：供应商是技术部门的合作伙伴，特别在应用系统出现异常时，技术人员必须立刻联系到供应商的技术联系人，如果技术人员把供应商公司和联系人信息集中维护，可以避免因联系不到人员而耽误异常情况的快速处理。

===

**

六、CMDB建设基础

**

建设CMDB是将原来分散在各个人员手中的电子表格和附件进行集中化、在线化管理，建设基础是信息的标准化和规范化，以下是一些举例和处理方法。

（一）名词不统一

图15：对机房名称进行统一的举例

金融企业一般有多个物理或虚拟机房，在使用电子表格台账时，机房名称是任意录入的，例如深圳腾达机房有深圳腾达机房、深圳腾达3楼机房、深圳机房、深圳自建机房、深圳IDC、深圳市腾达机房、深圳生产机房、深圳主机房等等名称。建设CMDB时，统一确定为 “深圳腾达机房”，在资产上架使用时，通过选择的方式确定所在机房名称，不允许输入机房名称。

类似的不统一还有应用系统名称不统一、机柜号不统一、各类状态不统一、各种等级不统一、操作系统名称不统一、供应商名称不统一、应用系统管理员不统一等等。

（二）日期格式不统一

日期是重要的管理信息，在使用电子表格台账时，日期是任意录入的，在梳理历史信息发现很多类似2015/11/31、2013-06-a1、2016年5月等错误或无法确定日期的信息。建设CMDB时，使用“日期型”字段，导入导出时使用“yyyy-mm-dd”格式，对日期数据进行规范化，类似2015-02-29的信息将因校验不通过而无法使用。

类似的问题还有必填的信息出现缺失，在使用CMDB时，缺少必填的信息将无法进行提交。

（三）未从使用角度管理数据

图16：对U位信息进行规范的差别展示

将数据在CMDB中进行管理的目的是为了使用，例如上图 “机柜中位置”的数据，可以使用2-3U、5-6U、8-9U等数据，也可以使用02-03U、05-06U、08-09U等数据，但当我们对“机柜中位置”的数据进行排序时，差别就立即体现出来，使用02-03U的左图可以一目了然展示设备的上下位置关系和机柜剩余位置，右图就是乱七八糟。

由此可见，将原来电子台账的数据导入CMDB后，需要对数据进行管理，使数据更加符合使用需要，后续登记时按照新的要求进行填写。

**

七、CMDB建设难点

**

图17：《CMDB分步构建指南》内容截图

以上截图来自《CMDB分步构建指南》书籍，“世人追求短期效应者众、看重长期发展者寡。打基础的事情，往往最难，在中国尤其如此。”在一定程度上体现CMDB建设的难度特别大。

如果是采购商业软件来建设CMDB，建议把项目按照“一把手”工程进行处理，最好以管理咨询项目进行切入，没有公司领导或部门负责人的支持注定会失败。如果是使用开源软件来建设CMDB，以满足资产管理、应用系统管理等场景化使用需求，可以立刻开始建设，基本没有难度，成功的概率很高。

**

八、补充说明

**

（一）友好的用户界面

图18：CMDBuild用户界面和标注

相对其他开源CMDB软件，友好的用户界面是此款CMDB软件的亮点之一，功能部局非常合理，普通用户可以经过简单培训，甚至无需培训即可开始使用。

每个用户可以自定义用户界面，选择要显示的字段，拖拽字段的左右位置，自定义多个过滤条件，可以选择一个过滤作为默认过滤，保存或清除个人设置。

支持全文搜索指定关键字，将包括关键字的条目全部列出，搜索速度非常快，基本都在1秒内完成搜索和条目列出。

（二）全面的权限管理

图19：不同权限用户的用户界面

此款CMDB软件具备完善的权限管理功能，基于用户组进行设置权限，可以定义不同的导航菜单(如上图所示)，可以对不同的数据表定义添加、克隆、修改、删除、打印、导入、导出、附件、关系查看、历史记录查看的权限，可以在用户组之间进行切换。

由于审计信息是与条目进行高度绑定，在条目的“历史”中展示，条目的删除将导致审计信息的消失，管理实践中会把普通用户的删除权限不予分配，必要时由具有删除权限的用户进行删除操作。

（三）强大的关联能力

图20：实时关联信息展示界面和跳转功能

在介绍CMDB的定义时给大家展示过“关系树”，只要知道关系树中的一个节点信息，我们可以顺着关系找到需要的全部信息。

例如知道一个IP地址，可以关联出部署的软件、应用系统名称、系统管理员姓名、系统管理员手机号码、实体服务器、供应商公司、供应商技术人员姓名、技术人员手机号码等等，只需要在“关系”里不断打开卡片即可。

（四）准确的数据底座

图21：电子邮箱收到通知邮件展示界面

经过一段时间的运行，CMDB中存储着准确的各种数据，这些数据可以给技术管理的很多系统使用，包括CMDB系统自身和其他各类业务系统，成为了技术管理的数据底座。

例如系统管理员前期已经维护了数字证书信息，笔者通过定制开发，读取数据库中的证书到期日期、证书名称、应用系统名称(关联获得)、系统管理员主岗和备岗的姓名(关联获得)、主岗和备岗的手机号码、电子邮箱(关联获得)，结合当天日期，计算出剩余有效期天数，在剩余有效期的90天、30天、15天、7天和3天向主岗和备岗发送通知电子邮件，同时抄送运维主管和笔者，向主岗和备岗发送手机提醒短信。

可以使用CMDB数据的包括监控系统、安全管理系统、流程管理系统、数据报送系统等等，详见各软件厂家的解决方案文档。

（五）个人安全实验室

图22：个人安全实验室虚拟化主机界面

本文章展示的所有图片均来自笔者的个人安全实验室，由笔者根据分享的需要进行构建，并非金融企业信息，不涉及企业秘密。

（六）CMDB是个筐

图23：一句非常经典的话

“CMDB是个筐，什么都可以往里装！”笔者认为包含两个意思：第一、CMDB是个筐，筐里装什么由管理者决定，需要充分发挥管理者的管理智慧，去定义场景并管理起来。第二、如果您在技术管理时，有技术事项一直管理不好，CMDB会是最佳方案。

**

九、总结

**

CMDB是一个概念，不是一个固定的产品，企业可以根据自身需要建设多个CMDB，例如资产A-CMDB、安全S-CMDB、资源R-CMDB等等，只要达到笔者总结的三点内容就是好的CMDB。

CMDB系统是技术管理部门实现数字化转型的最佳实践之一，能够实现技术团队成员的高效协同、维护管理对象的动态关系、数据服务其他的业务系统、提升整体的技术管理水平，值得每一位技术管理者拥有。

作者介绍

陈建茂，就职于央企所属证券公司，具有10余年金融企业技术管理经验，热爱研究和分享技术管理实践。

关于 安全村文集·证券行业专刊

证券行业自身低时延的业务要求以及业务中断的敏感性给安全防护带来了很大的挑战。专刊汇集了证券基金期货行业网络安全防护的最新经验、成果和解决方案，为大家分享一线安全规划、运营、建设的心得和实践经验。

关于 安全村

安全村始终致力于为安全人服务，通过博客、文集、专刊、沙龙等形态，交流最新的技术和资讯，增强互动与合作，与行业人员共同建设协同生态。

投稿邮箱：info@sec-un.org