4. 核验机制原理

团队所有权回归检查的核验机制基于“采集-比对-判定-告警”四阶段闭环模型。该模型确保每次发布窗口开启前，服务目录中记录的团队所有权信息与运行时基线保持严格一致，从而避免因所有权漂移导致的告警路由失败、变更通知遗漏或故障响应延迟。

4.1 核验触发条件

核验并非持续运行，而是由三类明确事件触发，以平衡系统负载与检查时效性：

4.2 核验流程：采集-比对-判定-告警

核验流程严格遵循四阶段顺序，每个阶段输出结构化数据供下一阶段消费。以下 SVG 展示了完整的核验流水线：

4.2.1 采集阶段

采集器从两个数据源并行拉取信息：

• 服务目录声明（CMDB）：通过 API 获取当前服务条目的 owner_team、owner_contact、secondary_team、escalation_path 字段。
• 运行时基线（Git 仓库）：读取 service-ownership.yaml 或 catalog/ 目录下的基线文件，该文件由平台工程团队维护，作为所有权信息的权威参考。

采集结果以 JSON 格式暂存于内存缓冲区，每条记录包含 service_id、source（声明/基线）、fields 和 timestamp。

4.2.2 比对阶段

比对引擎逐字段执行差异计算，支持三种比对模式：

4.2.3 判定阶段

判定器根据比对结果计算每个服务条目的核验状态。判定逻辑如下：

# 判定伪代码（Python 风格）
def evaluate(service_id, diff_result):
    if diff_result.empty():
        return "PASS"
    elif diff_result.has_critical_diff():
        # 关键字段（owner_team）不一致
        return "FAIL"
    elif diff_result.has_minor_diff():
        # 非关键字段（contact、secondary）不一致
        return "WARNING"
    else:
        return "PASS"

4.2.4 告警阶段

告警模块根据判定结果执行分级响应：

• PASS：仅写入审计日志，不触发任何通知。
• WARNING：发送 Slack 通知至服务所属团队的频道，附带差异详情；不阻断发布窗口。
• FAIL：发送 PagerDuty 告警至 SRE 轮值组，同时向发布窗口系统返回阻断信号，阻止窗口开启。

4.3 核验结果分类

核验结果分为三类，每类对应不同的业务含义和后续动作：

以下 SVG 展示了核验结果分类的决策树，帮助理解不同差异组合如何映射到最终结果：