4. 基线核验流程设计：核验触发条件、核验步骤设计、核验结果判定标准
基线核验流程是值班环境自动化保障的核心环节。它定义了“何时触发核验”、“如何执行核验”以及“如何判定核验结果”三个关键问题。一个设计良好的核验流程，能够将被动响应转变为主动防御，确保环境在每次变更或周期性巡检中始终处于合规状态。
4.1 核验触发条件
触发条件决定了基线核验的启动时机。根据运维场景的不同，我们将触发条件分为三类：事件驱动型、时间驱动型和人工驱动型。下表列出了各类触发条件的典型场景与配置建议。
| 触发类型 | 触发条件 | 典型场景 | 推荐配置 |
|---|---|---|---|
| 事件驱动 | 变更事件 | 代码发布、配置推送、扩缩容、重启服务 | 变更工单状态变为“执行完成”后立即触发 |
| 事件驱动 | 告警事件 | CPU/内存/磁盘超过阈值、端口不可达、进程崩溃 | 告警确认后自动触发关联基线核验 |
| 时间驱动 | 定时巡检 | 每日凌晨低峰期、每周日全量核验 | cron 表达式：0 3 * * *（每日凌晨3点） |
| 时间驱动 | 周期合规 | 金融行业月度合规审计、等保季度检查 | 每月1日 00:00 触发全量基线扫描 |
| 人工驱动 | 手动触发 | 故障排查、环境验证、演练测试 | On-Call 工程师通过 ChatOps 命令 /baseline check 触发 |
设计建议： 事件驱动应作为主触发方式，确保变更后环境立即得到验证；时间驱动作为兜底，防止漏检；人工驱动用于应急场景。建议在自动化平台中为每种触发条件设置独立的 核验优先级（P1/P2/P3），以便资源调度。
4.2 核验步骤设计
核验步骤采用流水线（Pipeline）模式设计，每个步骤独立可复用，支持并行执行与失败重试。标准核验流水线包含以下五个阶段：
- 前置检查（Pre-check）：验证核验环境本身是否可用，包括 Agent 心跳、API 连通性、权限令牌有效性。
- 数据采集（Collect）：从目标主机、中间件、网络设备采集当前配置、版本、状态等基线相关数据。
- 规则匹配（Match）：将采集数据与预定义的基线规则库进行逐项比对，支持精确匹配、正则匹配、范围匹配。
- 差异分析（Diff）：对匹配失败的项进行深度分析，区分“预期变更”与“异常漂移”，并生成差异报告。
- 结果输出（Report）：汇总核验结果，写入事件数据库，并根据判定标准触发后续动作（如自动修复、告警升级）。
4.3 核验结果判定标准
核验结果判定采用三级分类体系：通过（Pass）、警告（Warning）、失败（Fail）。判定标准基于基线规则的匹配结果与差异分析的严重程度。
| 判定等级 | 判定条件 | 图标/颜色 | 后续动作 |
|---|---|---|---|
| 通过（Pass） | 所有基线规则匹配成功，差异分析未发现异常漂移 | 绿色 ✓ | 记录日志，更新状态为“合规”，无需人工介入 |
| 警告（Warning） | 存在非关键规则匹配失败，或差异分析识别为“预期变更”（如已审批的配置更新） | 黄色 ⚠ | 发送通知至 On-Call 群组，要求24小时内确认；自动创建低优先级工单 |
| 失败（Fail） | 存在关键规则匹配失败，或差异分析识别为“异常漂移”（如未授权的文件修改、端口变更） | 红色 ✗ | 立即触发 P1 告警，自动执行预设修复策略（如回滚配置、重启服务），同时升级至值班经理 |
关键规则 vs 非关键规则： 基线规则库中的每条规则都应标记 severity 属性（critical / major / minor）。critical 规则失败直接判定为 Fail；major 规则失败判定为 Warning；minor 规则失败仅记录日志，不改变判定等级。建议在基线设计阶段与安全、业务团队共同评审规则等级。
4.4 核验结果判定流程图
为了更直观地展示判定逻辑，下图描述了从数据采集完成到最终判定输出的完整决策路径。
4.5 核验结果处理策略
针对不同的判定结果，自动化平台应执行差异化的处理策略。以下为推荐的处理矩阵：
| 判定结果 | 自动修复 | 告警通知 | 工单创建 | 升级机制 |
|---|---|---|---|---|
| Pass | 不执行 | 不发送 | 不创建 | 无 |
| Warning | 仅对 minor 规则执行预设修复 | 发送至 On-Call 群组（低优先级） | 创建低优先级工单，24小时SLA | 超过24小时未确认，升级至中级 |
| Fail | 立即执行预设修复策略（如回滚、重启） | 发送 P1 告警至值班手机+群组 | 创建紧急工单，1小时SLA | 15分钟未响应，升级至值班经理；30分钟未解决，升级至技术主管 |
最佳实践： 在自动化平台中为每个基线规则配置 auto_remediation 字段，指定修复脚本或 API 调用路径。修复执行后应自动触发二次核验，确认修复是否生效。若二次核验仍为 Fail，则停止自动修复，完全交由人工处理，避免修复循环导致更大问题。