4. 核验工具链选型：Ansible、SaltStack、Prometheus、自定义脚本的对比与选型原则

在构建值班环境基线核验体系时，工具链的选型直接决定了核验的覆盖率、执行效率与维护成本。本章从SRE实战角度，对四种主流方案进行系统性对比，并给出可落地的选型决策原则。

4.1 四种工具的核心定位与适用场景

4.2 核验工具链选型对比矩阵

以下从SRE关注的七个关键维度进行量化对比（★越多表示该维度表现越优）：

4.3 工具链协同架构

下图展示了一套经过生产验证的基线核验工具链协同架构，将Ansible与Prometheus有机结合，覆盖“核验-告警-修复-验证”闭环：

4.4 选型决策原则

基于实际值班环境中的核验需求，总结以下五条选型原则：

1. 原则一：核验优先于监控
   基线核验的核心是“主动发现偏离”，而非“被动等待告警”。优先选择具备主动执行能力的工具（Ansible/SaltStack）作为核验引擎。
2. 原则二：标准化优先于灵活性
   自定义脚本虽然灵活，但缺乏标准化输出。核验结果应统一为JSON/YAML格式，便于后续聚合与可视化。Ansible的ansible.builtin.assert模块和Prometheus的Exporter模式是推荐方案。
3. 原则三：修复能力不可缺失
   核验发现偏离后，工具链应具备自动修复或半自动修复能力。Prometheus本身不具备修复能力，需与Ansible联动形成闭环。
4. 原则四：可观测性必须内置
   核验执行记录、结果指标、执行耗时等数据应暴露给监控系统。推荐使用Prometheus Gauge 或 Counter 指标类型记录核验结果。
5. 原则五：维护成本决定长期成败
   选择团队已有技术栈的工具，避免引入过多异构系统。如果团队熟悉Python，Ansible是低门槛选择；如果已有Prometheus生态，优先复用。

4.5 典型组合方案推荐

4.6 自定义脚本的合理边界

尽管标准化工具是首选，但在以下场景中，自定义脚本仍是必要补充：

• 硬件级核验： 如BIOS版本、RAID卡状态、固件版本等，Ansible模块可能不支持。
• 遗留系统兼容： 老旧操作系统或专有设备，无法安装Agent或Python环境。
• 临时应急核验： On-Call期间需要快速验证某个特定参数，编写临时脚本比编写Playbook更快。
• 复杂逻辑核验： 涉及多步骤条件判断、循环、外部API调用的核验逻辑。

自定义脚本的标准化输出模板：

#!/bin/bash
# 基线核验脚本模板 - 输出标准化JSON
result='{
  "check_name": "kernel_version",
  "status": "PASS",
  "expected": "5.10.0-28-generic",
  "actual": "5.10.0-28-generic",
  "timestamp": "'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"
}'
echo "$result"

4.7 选型决策流程图

以下流程图帮助SRE团队快速确定工具链选型方向：