4. 基线核验数据模型设计

基线核验数据模型是值班环境基线管理的核心资产。一个设计良好的数据模型需要同时支撑配置项的精确描述、版本演进追踪、以及高效的数据同步机制。本节将围绕基线配置项的数据结构、版本号与时间戳设计、增量与全量数据模型三个维度展开。

4.1 基线配置项的数据结构

基线配置项（Baseline Configuration Item, BCI）是核验的最小原子单元。每个 BCI 应包含标识、属性、元数据和状态四类信息。

4.2 版本号与时间戳设计

基线数据在持续演进，必须建立可靠的版本管理机制。版本号用于标识基线快照的全局顺序，时间戳则记录每次变更的精确时刻。

4.2.1 版本号策略

采用 单调递增的全局版本号，结合 语义化基线标签 形成双层标识体系。

• 全局版本号（global_version）：64 位无符号整数，由中心化版本服务分配，严格递增，用于增量同步的断点续传。
• 基线标签（baseline_tag）：形如 v2025.04.13-r01，用于人工识别与回滚操作。
• 配置项版本（item_version）：每个 BCI 独立维护的版本计数器，仅在该配置项变更时递增。

4.2.2 时间戳设计

时间戳采用 RFC 3339 纳秒精度 格式，并遵循以下规则：

4.3 增量与全量数据模型

基线核验的数据传输需要平衡完整性与效率。全量模型适用于初始化与灾难恢复，增量模型适用于日常持续核验。

4.3.1 全量数据模型

全量快照包含指定 scope 下所有活跃 BCI 的完整信息，用于重建基线状态。

{
  "baseline_id": "bl-20250413-001",
  "global_version": 1042,
  "baseline_tag": "v2025.04.13-r01",
  "scope": "cluster:prod-east",
  "snapshot_time": "2025-04-13T14:30:00.123Z",
  "items": [
    {
      "bci_id": "0191f3a0-...",
      "config_key": "k8s.apiServer.auditPolicy",
      "config_value": {"enabled": true, "logLevel": "RequestResponse"},
      "checksum": "a1b2c3d4e5f6...",
      "item_version": 7,
      "status": "active"
    }
  ],
  "checksum_overall": "f6e5d4c3b2a1..."
}

4.3.2 增量数据模型

增量模型只传输自上次同步点以来发生变更的 BCI，包含操作类型与变更内容。

{
  "baseline_id": "bl-20250413-001",
  "from_version": 1035,
  "to_version": 1042,
  "changes": [
    {
      "op": "update",
      "bci_id": "0191f3a0-...",
      "config_key": "k8s.apiServer.auditPolicy",
      "config_value": {"enabled": true, "logLevel": "RequestResponse"},
      "checksum": "a1b2c3d4e5f6...",
      "item_version": 8,
      "prev_checksum": "z9y8x7w6v5u4..."
    },
    {
      "op": "delete",
      "bci_id": "0191f3b1-...",
      "config_key": "k8s.apiServer.deprecatedFlag",
      "item_version": 3
    }
  ],
  "change_count": 2
}

4.4 数据模型关系图

下图展示了基线、配置项、版本号与时间戳之间的核心关系，以及增量/全量同步的决策路径。

4.5 增量变更事件流

下图展示了从配置变更发生到增量数据被消费的完整事件流，突出版本号与时间戳在各个环节的作用。

4.6 模型选型对比