2. 值班环境基线定义：基线概念、核心要素与文档规范
值班环境基线（On-Call Environment Baseline）是 SRE 团队在接管生产环境前，必须预先定义并验证的一组最小可接受状态。它回答了这样一个问题：“当值班工程师打开终端时，环境应该已经具备哪些条件，才能保证故障响应不因基础设施缺失而延误？”
基线不是一次性配置，而是一份可审计、可自动化核验的契约。本章将拆解基线的核心概念、四大要素（网络、系统、应用、安全）以及文档规范。
2.1 基线概念：从“凭经验”到“按标准”
在没有基线的情况下，值班环境往往依赖个人经验搭建：A 工程师用跳板机 IP 1.2.3.4，B 工程师用 VPN + 堡垒机，C 工程师直接配了公网 SSH。一旦人员变动或环境重建，故障响应时间会急剧上升。
基线将环境状态显式化、版本化、可验证化。其核心特征包括：
- 确定性：每个环境变量、每个端口、每个证书路径都有唯一预期值。
- 可重复性：基于同一基线文档，不同工程师应能还原出完全一致的环境。
- 可自动化：基线内容应能被脚本或工具（如 Ansible、Terraform、自定义核验器）逐项检查。
- 版本化：基线文档本身纳入 Git 管理，变更需经过 MR/PR 评审。
实践建议：将基线视为“值班环境的单元测试”。每次环境变更后，自动运行基线核验脚本，未通过则阻断变更上线。
2.2 基线核心要素：网络、系统、应用、安全
基线覆盖四个维度，每个维度包含若干可核验的检查项。下表列出各维度的典型检查对象与预期状态示例：
| 维度 | 检查对象 | 预期状态示例 | 核验方式 |
|---|---|---|---|
| 网络 | 跳板机可达性、DNS 解析、端口连通性、VPN 隧道状态 | 跳板机 IP 10.0.1.100:22 响应 < 200ms；内网域名 api.internal 解析至 10.0.2.50 | ping、nc、dig、curl -I |
| 系统 | OS 版本、内核参数、时区、NTP 同步、磁盘余量、日志轮转配置 | Ubuntu 22.04 LTS；时区 UTC；/var/log 使用率 < 70%；ntpd 运行中 | uname -a、timedatectl、df -h、systemctl status ntpd |
| 应用 | 中间件版本、服务进程状态、健康检查端点、证书有效期、配置文件哈希 | Nginx 1.24.0 运行中；/health 返回 200；SSL 证书剩余 > 30 天 | curl -f、openssl x509 -checkend、sha256sum |
| 安全 | SSH 密钥权限、sudo 规则、防火墙规则、审计日志启用、敏感文件权限 | ~/.ssh 权限 700；sudo 仅允许特定用户；iptables 默认 DROP 入站 | stat、sudo -l、iptables -L、ausearch |
四个维度之间存在依赖关系：网络是连通基础，系统提供运行环境，应用承载业务逻辑，安全贯穿所有层级。任何一层的基线偏离都可能导致值班响应失败。
2.3 基线文档规范：结构、格式与版本管理
基线文档必须遵循统一的规范，才能被自动化工具解析。推荐采用 YAML + Markdown 混合的方式：YAML 用于机器可读的检查定义，Markdown 用于人工可读的说明与上下文。
2.3.1 文档结构模板
# 值班环境基线 - [环境名称]
# 版本: 1.2.0
# 最后更新: 2025-03-15
# 负责人: oncall-sre-team
## 1. 网络基线
- 跳板机:
host: 10.0.1.100
port: 22
timeout_sec: 5
expected: reachable
- DNS:
domain: api.internal
expected_ip: 10.0.2.50
- 端口:
- port: 443
host: lb.internal
protocol: tcp
expected: open
## 2. 系统基线
- os_version: "Ubuntu 22.04.3 LTS"
- timezone: UTC
- ntp_status: active
- disk_threshold:
path: /var/log
max_usage_percent: 70
## 3. 应用基线
- service: nginx
version: "1.24.0"
process_status: running
health_endpoint: "http://localhost/health"
ssl_cert_min_days: 30
## 4. 安全基线
- ssh_permission:
path: ~/.ssh
expected_mode: "0700"
- sudo_restriction:
allowed_users: ["deploy", "sre"]
- firewall_default_policy: drop_inbound
2.3.2 检查项字段规范
每个检查项至少包含以下字段：
- id：全局唯一标识，如
NET-001、SYS-023。 - description：人类可读的描述。
- command 或 check_type：核验时执行的命令或方法。
- expected：预期输出或状态。
- severity：critical / warning / info。
- remediation：偏离时的修复建议（可选但推荐）。
自动化核验示例：基于上述 YAML 基线，可编写一个简单的核验脚本逐项执行并比对结果。以下为伪代码片段：
for item in baseline['网络基线']:
result = run_check(item['check_type'], item['target'])
if result != item['expected']:
alert(f"{item['id']} 偏离基线: {item['description']}")2.4 基线核验流程与自动化闭环
基线定义完成后，需要嵌入值班环境的日常运维流程。下图展示了基线从定义到持续核验的闭环：
2.5 基线版本管理与变更流程
基线文档应像代码一样管理。推荐以下工作流：
- 创建/修改基线：在 Git 仓库中创建或编辑 YAML/Markdown 文件。
- 提交 MR/PR：附带变更说明，标注影响范围（如“新增 Redis 端口检查项”）。
- 评审与批准：至少一名 SRE 同事 review，确认检查项合理、预期值正确。
- 合并与发布：合并后 CI 自动触发基线核验，验证新基线在测试环境是否通过。
- 通知值班团队：通过 ChatOps 机器人广播基线版本变更。
常见陷阱：基线文档与真实环境脱节。例如，基线要求 Nginx 版本为 1.24.0，但安全团队已强制升级到 1.26.0。此时应更新基线而非忽略告警。建议每季度进行一次基线审计，确保文档与事实一致。
2.6 基线核验的自动化工具选型
根据团队规模与基础设施复杂度，可选择不同工具实现基线核验：
| 工具 | 适用场景 | 核验方式 | 学习成本 |
|---|---|---|---|
| Ansible | 已有 Ansible 管理的中大型集群 | Playbook + assert 模块 | 中 |
| Shell 脚本 | 小型环境或快速原型 | 逐条命令 + diff 比对 | 低 |
| Prometheus + Alertmanager | 需要持续监控基线偏离 | Exporter 暴露指标 + 告警规则 | 高 |
| 自定义核验器（Go/Python） | 需要深度定制与集成 | 解析 YAML 基线 + 并发执行检查 | 高 |
无论选择哪种工具，核心原则不变：基线定义与核验逻辑分离。基线文档只描述“应该是什么”，核验工具只负责“检查是否一致”。这样当环境变化时，只需更新基线文档，无需修改核验代码。
2.7 本章小结
- 基线是值班环境的“最小可接受状态”，必须确定性、可重复、可自动化、版本化。
- 四大要素：网络（连通性）、系统（OS 配置）、应用（服务状态）、安全（权限与策略）。
- 文档规范：YAML 定义检查项，Markdown 提供上下文；每个检查项包含 id、description、command、expected、severity。
- 自动化闭环：定义 → 核验 → 比对 → 告警 → 修复 → 重新核验。
- 版本管理：基线文档纳入 Git，变更需评审，合并后自动触发核验。