实习日志04

我现在参与的是企业运维平台的落地项目，整体是以蓝鲸平台为底座，主要围绕 CMDB、可观测、告警中心和 ITSM 这几个模块推进。

在这条链路里，我自己主要负责两块工作。第一块是 CMDB 侧的数据模型和关系补齐，包括模型创建、字段补齐、实例关系维护；第二块是 告警源和观测数据的接入与标准化处理，包括对接听云、华为云、Zabbix、APM 等数据源，对源数据做字段映射、清洗和标准化，再通过接口同步到平台侧，支撑后续的告警丰富和工单流转。

（更往下游的像 ITSM 流程配置、移动端展示、工单页面问题，这些我有了解上下游关系，但不是我直接主导的部分，而是我配合联调理解到的）

这类工作的核心难点，其实不在写代码本身，而在于不同系统之间字段和标识体系不统一。比如不同监控源里的业务 ID、实例 ID、主机标识、告警字段命名方式都不一样，而平台最终又要把这些数据落到 CMDB 的业务、主机、中间件、数据库模型里。如果这个过程里字段对不上、实例匹配不到、关系没有建起来，那么告警虽然能接进平台，但没法补齐业务、部门、运维负责人这些上下文信息，后面的告警丰富、通知分发、ITSM 转工单都会受到影响。

我自己做的工作，简单来说，就是把这些原始数据从“能采到”推进到“能落地、能关联、能闭环”。比如我会写一些接口对接和同步脚本，把上游系统里的业务字段、实例标识和 CMDB 模型字段做映射，把 APM 应用和数据库、中间件实例建立关联，补齐后续告警处理所需要的上下文。

我对这段工作的理解也有一个变化。刚开始我更关注单个脚本和单个任务，后来随着接触的数据源和联调场景越来越多，我逐渐从“写脚本”转向“理解整条链路”。到后面我会比较清楚地知道，每个脚本不是孤立存在的，而是在为告警丰富、告警分发、工单流转和运维闭环提供数据支撑。
所以我觉得这段经历对我最大的价值，不只是写了多少代码，而是让我开始从系统视角理解运维平台的数据链路。

具体来说，比如我做过一类同步脚本，是把 APM 应用里的业务字段和 CMDB 里的模型字段做对齐，并进一步把 APM 应用和数据库、中间件实例建立关联。
这件事看起来像是在“同步字段”，但它实际解决的问题是：如果不把这些关系补齐，后面的告警只能看到一个原始事件，无法准确知道它属于哪个业务、影响哪类中间件或数据库，也没法自动补出负责人信息。

gAo pIn zhUi weN

为什么和 CMDB 打通：因为原始告警本身往往只有“发生了什么”，但没有足够的业务上下文。
比如它可能告诉你某个实例 CPU 高、某个接口报错、某个主机异常，但如果它不能和 CMDB 打通，你就很难快速知道：

它属于哪个业务
影响的是哪个系统或模块
对应哪个中间件或数据库
谁是负责人
应该通知谁
能不能自动转工单

而 CMDB 里沉淀的是业务、主机、中间件、数据库、负责人这些配置关系。
所以把告警和 CMDB 打通，本质上就是给原始告警补齐“归属”和“上下文”，让它从一个孤立事件，变成一个可定位、可分派、可闭环处理的事件。

具体脚本：主要有三类，监控源数据接入脚本，比如对接听云、华为云、Zabbix 这类外部监控源，通过接口拿到原始数据后，做字段清洗、标准化，再组织成平台侧需要的格式；CMDB关系补齐脚本，比如把 APM 应用和 CMDB 中的中间件、数据库模型建立关联，把上游系统里的业务字段同步到 CMDB 对应字段；主机归属业务脚本，将主机归属到具体的业务下的空闲主机池。

关系补齐：“关系补齐”，主要是把平台里原本断开的几层关系连起来。
比如：