2. 验收标准体系
在OpenShift企业平台的验收交付中，最容易引发争议的不是“功能有没有”，而是“算不算达标”。如果验收标准停留在“集群运行正常”“应用可访问”这类定性描述，甲方与交付方对同一现象的判断可能完全相反。因此，验收标准体系的核心任务，是把平台能力翻译成一组可测量、可复现、可判定的量化指标，并明确每项指标的来源、测量方法、目标值与判定规则。
一、五类标准的分工与来源
一套完整的OpenShift验收标准通常由五个维度构成，它们并非并列堆砌，而是存在明确的上下游关系：
- SLA（服务等级协议）：面向业务与合同的承诺，回答“平台对业务承诺了什么”。例如“核心业务系统月度可用性不低于99.95%”。SLA是验收的顶层依据，通常由业务方与交付方在合同阶段约定。
- SLO（服务等级目标）：面向平台内部的可测量目标，是SLA的技术分解。例如为支撑99.95%的SLA，控制面API可用性SLO设为99.99%，节点就绪率SLO设为99.9%。SLO必须能被监控系统直接采集。
- 业务连续性：回答“故障发生时平台能承受多大损失”。包括RTO（恢复时间目标）、RPO（恢复点目标）、多可用区容灾能力、备份恢复成功率等。
- 安全合规：回答“平台是否满足安全基线与监管要求”。包括等保级别、CIS Benchmark符合率、镜像扫描通过率、RBAC最小权限覆盖率、审计日志留存周期等。
- 性能指标：回答“平台在负载下的表现”。包括API响应延迟P95/P99、Pod启动时间、调度吞吐、etcd写入延迟、网络带宽与存储IOPS等。
这五类标准的关系可以用下面的结构图表示：SLA是合同层承诺，SLO是平台层可测量目标，业务连续性、安全合规、性能指标是支撑SLO达成的三类技术证据。验收时，先核对SLA条款，再逐项验证SLO，最后用连续性、安全、性能的实测数据作为判定依据。
二、把SLA拆成可测量的SLO
SLA通常是业务语言，不能直接用于验收测试。以“核心业务月度可用性不低于99.95%”为例，需要先做可用性分解。假设核心业务由API网关、应用Pod、数据库三层组成，串联可用性为各层可用性之积。若数据库层由外部保障99.99%，应用层目标99.98%，则API网关层需满足：
0.9995 ≤ A_gateway × 0.9998 × 0.9999
A_gateway ≥ 0.9995 / (0.9998 × 0.9999) ≈ 0.99980
即API网关可用性SLO应不低于99.98%。这个计算过程本身就是验收标准的一部分：它说明了SLO数值的来源，避免目标拍脑袋。实际交付中，还应把可用性定义为“成功请求数 / 总请求数”，并明确哪些请求计入分母（如健康检查是否排除）、哪些状态码算失败（5xx算失败，4xx通常不算平台故障）。
haproxy_backend_http_responses_total与apiserver_request_total的聚合。健康检查探针请求单独标记并从分母中剔除。
三、业务连续性的量化验收
业务连续性不能只写“支持容灾”，必须落到RTO与RPO两个数字上。RTO是故障发生到业务恢复的最长可接受时间，RPO是允许丢失的数据时间窗口。验收时通常通过故障注入来验证：
- RTO验证：主动关闭一个可用区的全部worker节点，记录从节点失联到业务Pod在其余可用区重新就绪并恢复服务的时间。若SLO要求RTO≤30分钟，则实测值必须≤30分钟，且过程中无数据不一致。
- RPO验证：对etcd执行快照恢复演练，对比快照时间点与故障时间点之间的数据写入量。若RPO≤5分钟，则etcd快照周期必须≤5分钟，或采用持续备份方案。
- 备份恢复成功率：连续执行N次备份恢复演练，成功率必须为100%。任何一次失败都需要根因分析并重新演练。
这些演练结果应形成可追溯的记录，包括演练时间、注入故障类型、影响范围、恢复时间、数据丢失量、参与人员。验收评审时，这些记录是业务连续性达标的直接证据。
四、安全合规的验收要点
安全合规验收通常依据等保级别或行业监管要求展开。在OpenShift平台上，可量化的检查项包括：
| 检查项 | 量化标准 | 验证方式 |
|---|---|---|
| CIS Benchmark符合率 | ≥ 95%，高危项100%通过 | 运行OpenShift Compliance Operator，导出扫描报告 |
| 镜像高危漏洞 | 生产命名空间内高危漏洞数 = 0 | Quay/ACS镜像扫描报告 |
| RBAC最小权限 | 无cluster-admin绑定的普通用户，特权容器数 = 0 | 审计RBAC绑定与SCC使用记录 |
| 审计日志 | 留存 ≥ 180天，且可检索 | 检查日志存储后端与保留策略 |
| 网络策略 | 核心命名空间NetworkPolicy覆盖率 = 100% | 遍历命名空间检查NetworkPolicy对象 |
安全合规的判定原则是“一票否决”：高危项未通过时，即使性能与可用性全部达标，整体验收也不能通过。因此，安全扫描应尽早介入，而不是留到验收末期。
五、性能指标的测量方法
性能指标必须明确测量工具、负载模型和判定阈值。以API响应延迟为例，常用测量方式为：
# 使用kube-burner对API Server施加负载并采集延迟
kube-burner init -c api-load.yaml --metrics-endpoint=http://prometheus:9090
# 关键PromQL：API P99延迟
histogram_quantile(0.99,
sum(rate(apiserver_request_duration_seconds_bucket{verb!="WATCH"}[5m])) by (le)
)
验收时，应在约定的负载模型下运行测试，例如“500个命名空间、5000个Pod、每秒50次创建请求”，持续30分钟，取稳定阶段的P95与P99。若P99超过1秒，则判定性能SLO未达标。需要注意的是，性能测试结果与集群规格、etcd磁盘类型、网络插件强相关，验收标准中应同时记录测试环境规格，否则数据不可复现。
六、验收标准表的组织方式
把上述内容整理成一份可执行的验收标准表，是交付团队最实用的成果。表中每一行应包含：指标名称、所属维度、SLA/SLO目标值、测量方法、数据来源、判定规则、责任人。例如：
| 指标 | 维度 | 目标值 | 测量方法 | 判定规则 |
|---|---|---|---|---|
| API Server可用性 | SLO | ≥ 99.99% | Prometheus月度聚合 | 低于目标即不通过 |
| 核心业务RTO | 连续性 | ≤ 30min | 故障注入演练 | 超时即不通过 |
| CIS高危项 | 安全 | 100%通过 | Compliance Operator | 任一未通过即不通过 |
| API P99延迟 | 性能 | ≤ 1s | kube-burner + PromQL | 稳定阶段超标即不通过 |
这张表的价值在于：它把“验收”从一次主观评审变成了一次可重复执行的核对过程。每一项都有明确的数字、来源和判定规则，交付方可以自测，甲方可以复核，争议空间被压缩到最小。验收标准体系建立之后，后续的验收执行、问题整改和最终签字，都围绕这张表展开。