1. 值班基线核验概述：平台工程中值班基线核验的定义、目标与核心价值
1.1 什么是值班基线核验
在平台工程实践中，值班基线核验（On-Call Baseline Verification） 是指平台团队在每次发布、变更或周期性巡检中，对 Kubernetes 集群及其上运行的业务系统执行的一组最小化、可重复、自动化的验证动作。其核心目的是确保集群的部署状态与通信机制始终符合预先定义的“健康基线”，从而为值班工程师提供明确的“正常”参照系。
关键定义：值班基线核验不是一次性的压力测试或安全审计，而是一套持续集成到日常运维流程中的“信号灯”机制。它回答三个问题：集群是否还活着？业务是否还能被访问？变更是否引入了预期外的副作用？
1.2 核验的目标
值班基线核验的目标可以拆解为四个层次，从基础设施到业务体验逐级递进：
| 层次 | 目标 | 典型验证项 |
|---|---|---|
| L1 基础设施 | 集群控制面与节点健康 | API Server 响应、节点 Ready 率、etcd 集群状态 |
| L2 部署状态 | 工作负载与配置一致性 | Deployment 副本数、Pod 状态、ConfigMap/Secret 挂载 |
| L3 通信机制 | 服务发现与网络连通性 | Service/Endpoint 解析、Ingress 路由、Pod-to-Pod 延迟 |
| L4 业务体验 | 核心功能可访问 | HTTP 200 响应、API 返回正确 JSON、数据库连接正常 |
1.3 核心价值
在平台工程中引入值班基线核验，能够为团队带来以下可量化的价值：
- 缩短平均恢复时间（MTTR）：基线核验提供“已知正常”的参照点，值班人员无需从零排查，可直接对比基线定位异常。
- 降低变更风险：每次部署前自动执行基线核验，若基线失败则阻断发布，防止“带病上线”。
- 消除值班疲劳：自动化核验替代人工巡检，减少重复性手动检查，让工程师聚焦于真正需要判断的异常。
- 建立信任锚点：平台团队与业务团队之间形成统一的“健康语言”，避免因认知差异导致的误判。
实践建议：基线核验的通过率应作为平台工程团队的首要服务等级指标（SLI）之一。建议将核验结果暴露为 Prometheus 指标（如
baseline_verification_success），并配置告警规则：连续 2 次核验失败即触发 P1 告警。
1.4 核验范围与通信机制的关系
本课程特别强调通信机制在基线核验中的核心地位。Kubernetes 是一个分布式系统，其健康不仅取决于单个 Pod 是否运行，更取决于 Pod 之间、Service 与 Pod 之间、集群内外之间的网络路径是否畅通。下图展示了值班基线核验在 Kubernetes 通信链路中的覆盖范围：
1.5 基线核验的典型流程
一个标准的值班基线核验流程通常包含以下步骤，这些步骤将在后续章节中逐一深入：
- 基线定义：由平台工程团队与业务团队共同制定核验清单，明确每个核验点的通过标准（如：Ingress 响应时间 < 500ms）。
- 自动化编排：将核验清单转化为可执行的脚本或 Operator，集成到 CI/CD 流水线或定时任务中。
- 执行与记录：在每次部署前、部署后以及每日固定时间执行核验，结果写入日志或时序数据库。
- 异常处置：当核验失败时，自动阻断发布或触发告警，并附带失败节点的上下文信息（如 Pod 日志、网络抓包）。
- 基线迭代：根据历史故障和业务演进，定期更新基线核验项，确保基线始终反映当前系统的真实健康边界。
常见误区：不要试图将“所有”监控指标都纳入基线核验。基线核验应保持最小化——只包含那些一旦失败就代表系统不可用的关键路径。过多的核验项会导致“告警疲劳”，反而降低值班效率。建议初始基线不超过 10 项。