述职报告

述职人：李滔

岗位：后端工程师

项目：CMDB（配置管理数据库）

汇报日期：2026-6-25

---

CMDB 配置管理数据库项目述职报告

一、项目概述与定位

1.1 项目背景

CMDB是麦当劳中国IT配置管理系统。在 CMDB 建设之前，麦当劳的 IT 资源配置信息分散在多个独立系统中——老的CMDB平台、CMP 平台、NetBox 网络管理系统、Rancher 容器平台、各云厂商控制台等。

资源与资源之间（如 IP 与服务器、虚拟机与物理机之间）无法交叉关联。当线上发生故障时，无法快速厘清"这个域名背后有哪些服务"等关键信息，直接影响问题定位效率。

不同资源的查询需要登录不同系统——查虚拟机去CMP、查网络配置去 NetBox、查容器去 Rancher——资源归属问题可能需要打开五六个页面才能查到答案。

用户申请了资源之后，往往不清楚资源当前的使用状态、归属的项目标签、以及相关的计费模式，不利于资源管理。

1.2 项目目标

CMDB 项目统一 IT 资源配置的管理平台，覆盖 IDC、Cloud、Office 和门店设备等全范围 IT 资产，实现以下价值：

将分散在各个系统/数据源中的配置信息集中管理，提供统一的管理能力。

为变更管理和故障管理提供数据支撑，从上到下的全链路资源节点追踪。

二、项目规模与我的角色

2.1 项目规模

CMDB 项目具备以下规模特征：

指标	数值
管理资源类型	20+ 种
代码规模	350+ Python 文件，50,000+ 行代码
API 接口数	80+ 个
定时同步任务	43 个
虚拟机	4,000+ 台
Pod	50,000+ 个
物理机	1,000+ 台

技术栈涵盖 Python + FastAPI + SQLAlchemy + MySQL + NebulaGraph（图数据库） + Docker

2.2 我的角色与职责

在 CMDB 项目中，我担任开发者。具体职责包括：

我主导了多源数据同步的设计与实现，负责数据模型抽象、同步框架搭建。

开发了 IP 资源搜索的多次迭代演进，从精确查询到模糊匹配多种资源。

实现了域名全链路功能，通过递归深度从 DNS 解析到 WAF/CDN、负载均衡、K8S 集群、Nginx 直至业务服务器的调用链路

CMDB 涉及多个数据源的对接，与 CMP 、NetBox 网络等多个外部团队沟通数据模型、同步频率和接口鉴权等推动数据对接。

参与了 CronJob 错峰编排、监控告警配置，确保系统在生产环境中稳定运行。

三、技术难点

3.1 数据质量保障

CMDB 需要保证数据质量。我们面对的是来自不同团队、不同平台的数据源，数据格式、命名规范、更新频率各不相同，部分数据源甚至存在字段缺失、格式错误等问题。

采用的策略是"分层治理"：核心字段缺失的同步任务直接失败并告警；非核心字段缺失则用默认值填充并记录日志；每日巡检数据正确性；波动校验机制防止异常数据大面积覆盖。

3.2 查询性能优化

随着管理资源规模的增长，部分接口出现了响应慢、超时等问题。我通过分析SQL执行计划定位瓶颈，为高频查询字段补充组合索引、优化去重逻辑减少数据库往返，并将多跳关联查询下沉到图数据库执行，有效提升了接口响应速度。

3.3 跨团队协作推进

对接一个新数据源，需要和对方团队沟通数据模型、接口调用方式、测试环境联调等一系列环节，每个环节都可能因为对方优先级不同而延宕。

对接新数据源时，我会提前准备需要采集的数据以及明确需要哪些字段，明确后按规律主动跟进，协助联调，确保对接任务推进。

四、个人成长与收获

4.1 技术能力的系统性提升

加入 CMDB 项目之前，我对一些技术基本停留在"听说过"的层面。项目做下来，算是真正上手了——从零开始写 nGQL 查询、调优批量写入性能、踩坑一些工具使用机制、管理环境配置。这些技术不是各自独立的，它们要组合在一起跑通一个生产级系统，中间有很多需要学习的细节。

4.2 业务理解与产品思维的提升

CMDB 这个项目让我意识到一件事：技术解决的是"怎么做"的问题，但更难的往往是"做什么"和"为什么做"。

同样一份数据，不同的人想看的东西完全不一样。运维想快速查到 IP 归属，技术想看自己的资源存在的标签。同一个接口，如果我只按自己的理解来做，大概率只满足了一部分人的需求。后来我会在动手之前想一下用户想要什么。

4.3 工程思维与运维意识的形成

以前我有个毛病：代码写完、本地跑通就觉得完事了。CMDB 做下来，这个想法彻底被纠正了。

代码上线只是开始，真正考验人的是生产环境里各种意想不到的情况。数据源接口突然改了字段格式怎么办？上游数据库被误删了导致同步过来全是空数据怎么办？网络抖动导致增量同步只跑了一半怎么办？这些问题在我写代码的时候根本不会想到，但它们真的会发生。波动校验、版本回滚、自动告警、降级策略——这些机制不是一开始就设计好的，大都是被真实故障之后补上的。

4.4 对数据一致性认知

CMDB 的底线是数据要准。如果用户查出来的信息和实际情况对不上，信任就没了。

保证数据准这件事，不单单是靠代码。同步代码写得再小心，也挡不住上游数据源的各种问题——字段突然不报了、格式悄悄变了、某张表被整个删掉了。我学一点就是：永远假设上游会出问题，然后给自己留退路。版本化管理让数据可以随时回滚，波动校验在异常数据大规模覆盖之前拦住它，告警让人第一时间知道出事了。不能只是靠写更完美的代码来保证的，而是靠一套容错和兜底的机制，让系统在意外发生时还能守住底线。

五、总结与展望

5.1 项目总结

CMDB 项目到 MVP 上线，经历了需求调研、架构设计、开发实现、测试上线、持续迭代的全过程。

作为开发者，我在技术能力、业务理解、团队协作等多个维度得到了全方位的锻炼和成长。

5.2 后续规划与展望

CMDB 项目将在以下方向持续演进：

资源标签体系完善。 支持自定义标签和批量管理，让用户可以根据自己的业务场景灵活标记资源，提升资源分类和检索的灵活性。

图数据库关系补全。 目前的关系图谱还有进一步丰富和深化空间，包括数据库节点与服务的依赖关系等，让全链路拓扑更加完整。

MCP 集成深化。 进一步完善 MCP接口，让 CMDB 的能力可以被 AI 工具链灵活调用，为智能化运维场景打开更多可能。