4. 核验触发机制：定时轮询核验、事件驱动核验、变更事件联动核验、手动触发核验

配置偏差核验的触发时机直接决定了基线一致性的发现时效与系统开销。单一触发模式无法覆盖所有场景：定时轮询适合稳态巡检，事件驱动适合快速响应，变更联动适合源头阻断，手动触发适合应急排查。本章详细拆解四种触发机制的设计原理、适用场景与工程实现要点。

4.1 四种触发机制对比总览

4.2 定时轮询核验

定时轮询是最基础的核验触发方式，通过固定时间间隔或Cron表达式触发全量或增量基线比对。适用于对实时性要求不高的稳态环境巡检。

4.2.1 轮询策略设计

• 全量轮询：每次扫描所有目标资源，适合资源规模较小（< 500节点）或合规要求严格的场景。周期建议 4h～24h。
• 增量轮询：基于上次扫描时间戳或变更日志，仅扫描有变更迹象的资源。周期可缩短至 15min～1h，大幅降低API调用开销。
• 分层轮询：核心资源高频轮询（如 5min），普通资源低频轮询（如 6h），实现资源分级保障。

# 定时轮询配置示例（YAML）
baseline_check:
  mode: "incremental"          # full | incremental | tiered
  cron_expression: "0 */30 * * * ?"  # 每30分钟执行一次
  tiered_policy:
    critical: "*/5 * * * *"    # 核心资源5分钟
    normal: "0 */2 * * *"      # 普通资源2小时
    archive: "0 0 3 * * ?"     # 归档资源每天凌晨3点
  retry:
    max_attempts: 3
    backoff: "exponential"

4.3 事件驱动核验

事件驱动核验通过监听基础设施的实时事件流（如配置变更事件、状态更新事件），在事件到达时立即触发基线比对。相比定时轮询，事件驱动能实现秒级发现，是告警降噪的关键前置能力。

4.3.1 事件源与事件类型

4.3.2 事件去重与降噪

事件驱动核验面临的最大挑战是事件风暴——短时间内大量重复或无关事件涌入，导致核验引擎过载。必须引入事件去重与降噪策略：

• 窗口去重：相同资源、相同配置项的变更事件在 30s 窗口内只触发一次核验。
• 事件聚合：将同一资源在短时间内的多次变更合并为一次批量核验。
• 优先级过滤：仅对基线中标记为“关键”或“重要”的配置项触发核验，忽略非基线属性变更。

# 事件驱动核验配置示例
event_driven_check:
  sources:
    - type: "kubernetes_watch"
      resources: ["configmaps", "secrets"]
      namespaces: ["production", "staging"]
    - type: "aws_cloudtrail"
      events: ["UpdateSecurityGroupRule", "ModifyInstanceAttribute"]
  dedup:
    window: "30s"
    key_fields: ["resource_id", "config_key"]
  aggregation:
    max_batch_size: 10
    flush_interval: "5s"

4.4 变更事件联动核验

变更事件联动核验是事件驱动核验的增强模式，它将核验动作与变更管理流程深度绑定。只有当变更经过审批、计划、执行等完整流程后，才触发基线核验。这种机制能从源头阻断配置漂移。

4.4.1 联动流程

1. 变更发起：运维人员或CI/CD流水线提交变更工单。
2. 变更审批：变更通过审批后，系统自动记录变更目标、变更内容、预期影响范围。
3. 变更执行：变更工具（Ansible/Terraform/K8s Apply）执行配置修改。
4. 联动触发：变更执行完成后，核验引擎立即收到联动信号，对变更涉及的资源进行基线比对。
5. 结果反馈：核验结果自动回写至变更工单，标记“通过/失败/偏差详情”。

4.4.2 联动接口设计

# 变更联动核验API示例（RESTful）
POST /api/v1/baseline/verify-on-change
{
  "change_id": "CHG-20250321-001",
  "target_resources": [
    {"type": "kubernetes_deployment", "id": "prod/web-app/v1.2.3"},
    {"type": "aws_security_group", "id": "sg-0a1b2c3d4e5f"}
  ],
  "expected_baseline_version": "v2.1.0",
  "trigger_source": "change_management",
  "callback_url": "https://cmdb.internal/change/CHG-20250321-001/verify-result"
}

4.5 手动触发核验

手动触发核验作为兜底与应急手段，允许运维人员通过CLI、API或Web UI主动发起一次基线核验。适用于以下场景：

• 故障排查：怀疑配置漂移导致故障时，立即手动触发核验确认。
• 合规审计：审计人员需要特定时间点的基线快照。
• 变更验证：变更执行后，手动触发核验验证变更效果。
• 定时轮询异常：定时轮询任务失败或超时，手动补扫。

# 手动触发核验CLI示例
$ baseline-cli verify --target "prod/*" --baseline "v2.1.0" --output json
{
  "verify_id": "vfy-20250321-001",
  "status": "running",
  "total_resources": 156,
  "completed": 0,
  "estimated_duration": "45s"
}

4.6 四种触发机制协同架构

下图展示了四种触发机制在平台工程环境中的协同工作方式。定时轮询作为兜底巡检，事件驱动作为实时感知层，变更联动作为流程嵌入点，手动触发作为应急通道，共同构成完整的核验触发体系。

4.7 触发机制选择矩阵

在实际平台工程环境中，不同资源类型、不同变更频率、不同合规要求需要匹配不同的触发机制组合。下表提供了推荐的选择参考：