以下文章来源于“富国金融科技之路”公众号，经原作者姚琦同意并授权刊出，文章原标题《富国基金统一资产管理平台（CMDB）落地经验》（作者：姚琦）
CMDB的概念
CMDB(Configuration ManagementDataBase，配置管理数据库)是与IT系统所有组件相关的信息库，它包含 IT 基础架构配置项的详细信息。与每个企业具体的IT软硬件环境、组织架构和流程强相关，这就决定了 CMDB 一定是高度定制化的体系。虽然我们都知道它不仅仅是一个存储信息的数据库那么简单，但是，它的具体形态是什么样子，并没有统一的标准。
富国基金第一代CMDB的实施经验
富国基金于2016年搬迁万国数据新机房时，构建了整套的ITSM-CMDB体系。ITIL流程在当时更多地被当做流程规范使用，CMDB是本着应入尽入的原则搭建。基本替代了大家手头的EXCEL表格。但是理想是美好的，现实是骨感的。和广大行业同仁遇到了同样的问题，由于没有自动化采集能力，没有对CI（配置项）更新的强约束，这个“线上EXCEL”中的庞大数据很快就遭遇了更新不及时，数据没人消费的问题。而这些问题又反过来导致使用者逐渐抛弃这个“线上EXCEL”，恶性循环就此产生。
经历了一段不美好的回忆后，我司也开展了复盘行动，总结项目收益不如预期的原因：
1. 信息固化不是目的，也没有价值，只有信息动态流转起来才有价值（跟货币一样），那么进入CMDB的数据并不应是大而全，而是应该先设计消费场景，再反过来去寻找数据来源并进行入库。
需要配套设计的工作有：
1） 基于这些信息进行流程规范的建设，比如服务器的上线、下线、维修、装机等流程。同时，流程过程中状态的变更要同步管理起来。
2） 拓扑关系的可视化和动态展示，比如应用与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。
2.需要将更多的精力放在应用及更上层的数据上，发挥数据的价值，而非聚焦于底层的硬件，基础设施。
如果仅仅基于 CMDB 的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络 - 硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远。
富国基金新一代CMDB扬帆起航
2020年，在完成充分的总结和规划后，我司启动了新一代富国基金统一资产管理平台的重建并取得了阶段性成果。
目前项目实现了以下既定目标：
1. 面向场景重构CMDB模型，提高数据的可消费性和可采集性。
2. 完成第一阶段CMDB自动同步、自动发现、自动关联体系（CI自动化采集比率 80.67%）
3. 完成第一阶段CMDB数据治理（关键数据缺失率降至0，通过IP扫活确保不会存在设备遗漏，信息补足依靠后置稽核措施补全）
4.完成第一阶段多个消费场景：运维相关工具平台完成了以CMDB作为核心数据源，实现了告警负责人，变更归属，运维人员堡垒机权限控制等消费场景。
下一步的CMDB建设
由于我司基础设施架构开始倾向于混合云，应用架构也逐步微服务化，容器化，新一代资产管理平台还需要进一步适配云原生时代的信息资产管理需求。以下问题和消费场景需求亟需解决：
1. 在传统架构下通过CMDB做资产管理，云原生架构下最小管理单元不再是物理机和CVM，变成pod和容器。安全扫描、安全修复和安全应急都依赖资产信息(节点IP、容器名、容器id、负责人等)，资产信息不全可能会导致安全事件无法排查原因和修复。故CMDB需完成多k8s集群对接，application-namespace-service-pod模型构建等工作。
2. 根据NPM流量镜像绘制应用间访问关系拓扑图（设定规则过滤非关注网段，暨噪音），用于进行变更影响关系分析。
3. 建立应用等级，高可用要求及现状模型，用于年度切换演练及总结场景消费。
4. 物理理机等目前无数据源硬件资产的信息丰富工作,计划采取带外、SNMP、IPMI、Redfish、SSH等手段。
云原生时代的基础设施与传统运维已发生了剧烈变化，对应的运维工具（监控，CMDB）等均需匹配需求的变化，顺应云原生时代的架构，提升可观测性，保证资产的可管理性，为实现企业数智化转型，信息科技能力发展奠定扎实的基础。
