实习日志04

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

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

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

— 这类工作的核心难点，其实不在写代码本身，而在于把单点任务理解成一条完整链路，因为刚开始接触的时候，看到的是很多零散任务：有的是接听云数据，有的是补 CMDB 字段，有的是同步业务 ID，有的是处理告警字段。如果只站在“写脚本”的角度去看，会觉得这些事情很碎，也不知道自己到底在支撑什么。但后来慢慢发现，这些任务其实都在服务同一件事：
把外部监控数据和平台内部的 CMDB/告警/工单体系打通。一旦从链路角度理解，就会知道为什么要做字段映射、为什么要补关系、为什么有些数据能采到但还是不能落地。
所以对我来说，最大的成长不是会写更多脚本，而是开始能从系统视角理解一项工作在上下游里的位置。

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

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

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

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

在这期间，我体会特别深的一个词就是“闭环”。
我负责的工作是在整条链路里的一环，如果我这边只做到“脚本跑完了”，但结果不完整，或者异常没有继续推进，那下游其实还是没法用，这个任务就不算真正完成。

我印象比较深的一个例子是同步人员信息到主机模型。当时主机模型里有六千多条数据，脚本跑完以后，从日志看只同步成功了三千多条。这个时候我不会把它简单理解成“脚本执行成功了”，而是会继续去排查剩下那部分为什么没同步上。
后面我会把未同步的数据先导出，再按原因分类排查，比如源字段为空、目标模型缺实例、IP 对不上、或者上游数据本身不完整。分类之后再结合日志和同事沟通，确认哪些问题需要我调整脚本，哪些需要补基础数据，哪些需要依赖其他链路继续推进。
这件事让我体会比较深的是，运维开发很多时候不是代码写完就结束，而是要把结果真正推进到可用、可解释、可跟进，这才算闭环。所以我后来比较重视的是“结果闭环”而不是“动作闭环”。

动作闭环只是把脚本执行完，结果闭环是确认数据真的落地、异常真的被解释、下游真的能继续使用。我理解的闭环也不是所有问题都必须我一个人解决，而是我要把问题归因清楚、同步清楚，并持续推进到它有明确结论。

SRE / 运维开发很多工作本身就不是孤立编码，而是在复杂链路里解决问题。
比如数据同步、监控接入、告警流转、配置管理，这些事情往往都涉及上下游依赖，不是把某一段代码写完就结束。
我这个例子虽然规模不算特别大，但让我开始真正理解：
运维开发更重要的是对结果负责，对链路负责，而不只是对代码负责。

gAo pIn zhUi weN

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

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

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

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

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