3. 可靠性评审框架：定义可靠性评审的输入、输出、评审委员会角色与评审生命周期
可靠性评审是连接可观测性数据生产与自助目录消费的核心质量门禁。没有评审框架，OpenTelemetry 自助目录将退化为无管控的指标仓库，最终导致数据沼泽。本章定义评审框架的四个关键要素：输入工件、输出产物、评审委员会角色与评审生命周期。
3.1 评审框架全景
下图展示了可靠性评审在自助目录架构中的位置与核心流程：
3.2 评审输入：必须携带的可靠性证据
每次评审请求必须附带以下四类工件，缺少任意一项将触发预审拒绝：
| 输入类别 | 具体内容 | 来源 | 格式要求 |
|---|---|---|---|
| 服务拓扑 | 基于 OpenTelemetry 导出的服务依赖图，包含上下游、协议、调用频率 | OTel Collector + 服务注册中心 | OTel Resource 语义 + YAML/JSON |
| SLO/SLI 定义 | 至少包含可用性、延迟、错误率三个黄金指标的目标值与测量窗口 | 服务方 SRE 团队 | OpenSLO v2 格式 |
| 错误预算报告 | 过去 28 天的错误预算消耗曲线、燃烧率、剩余预算百分比 | 可观测性平台 | Prometheus 指标 + 截图 |
| 变更事件日志 | 最近 7 天内的生产变更记录，包括变更类型、影响范围、回滚状态 | CI/CD 管道 + 事件管理平台 | 标准变更事件 JSON |
实践建议：在 OpenTelemetry Collector 中配置
transformprocessor，自动从 span 和 metric 中提取服务拓扑与 SLO 数据，减少人工准备输入工件的负担。
3.3 评审委员会角色与职责
评审委员会由四个固定角色组成，每个角色拥有一票表决权。委员会采用简单多数通过原则，但可靠性架构师拥有一票否决权。
| 角色 | 所属团队 | 核心职责 | 表决权重 |
|---|---|---|---|
| 可靠性架构师 | 平台工程 / SRE 中心 | 评估整体架构可靠性、SLO 合理性、目录一致性 | 1 票 + 否决权 |
| SRE 代表 | 值班 SRE 轮值 | 审查错误预算、燃烧率、告警规则与 on-call 准备度 | 1 票 |
| 服务负责人 | 业务服务团队 | 陈述服务可靠性设计、变更风险与改进计划 | 1 票（不参与自身评审表决） |
| 可观测性平台代表 | 可观测性平台团队 | 验证数据接入合规性、OTel 语义正确性、目录元数据完整性 | 1 票 |
3.4 评审生命周期：五阶段模型
每个评审请求经历五个严格定义的阶段，阶段之间通过状态机转换：
- 提交（Submitted）：服务方通过自助目录门户提交评审请求，上传所有输入工件。系统自动生成唯一评审 ID 并通知委员会。
- 预审（Pre-check）：自动化管道执行 8 项硬性检查，包括：OTel 语义校验、SLO 格式验证、错误预算数据完整性、变更日志时间戳合理性等。预审未通过直接退回并附带错误详情。
- 评审会（Review Meeting）：委员会召开同步或异步评审会议。可靠性架构师主持，服务负责人做 15 分钟陈述，随后进行 20 分钟问答与表决。
- 决策（Decision）：输出三种结果之一——准入（Approved）、条件通过（Conditionally Approved，附带改进项清单）、拒绝（Rejected，附带拒绝理由）。
- 归档（Archived）：所有评审记录、表决结果、改进项追踪链接写入评审数据库，保留至少 12 个月用于审计与复盘。
关键指标：目标评审周期 ≤ 5 个工作日（从提交到决策）。预审阶段应在 30 分钟内完成自动化检查。评审会阶段不超过 2 个工作日排期。
3.5 评审输出：目录准入契约
评审通过后，系统自动生成以下输出产物，作为自助目录的准入契约：
| 输出产物 | 内容说明 | 存储位置 | 有效期 |
|---|---|---|---|
| 目录准入证书 | 包含服务名称、评审 ID、准入日期、可靠性等级（Tier 1/2/3） | 自助目录元数据存储 | 6 个月（需续期评审） |
| 可靠性等级标签 | 以 OpenTelemetry Resource Attribute 形式注入：reliability.tier=1 |
OTel Resource 属性 | 随证书有效期 |
| 改进项追踪列表 | 条件通过时生成，包含改进项描述、负责人、截止日期 | 评审数据库 + 事件管理平台 | 直至所有改进项关闭 |
| 评审记录归档 | 完整评审日志、表决记录、附件、会议纪要 | 评审数据库（只写一次） | 12 个月 |
3.6 评审框架与 OpenTelemetry 的集成点
评审框架并非独立系统，而是深度嵌入 OpenTelemetry 生态：
- 预审自动化：通过 OTel Collector 的
batchprocessor和filterprocessor实时校验传入数据的语义完整性。 - 可靠性标签注入：评审通过后，通过 OTel SDK 的
ResourceAPI 将可靠性等级标签注入到所有后续产生的 span、metric、log 中。 - 评审指标暴露：评审框架自身暴露 Prometheus 指标，如
review_duration_seconds、review_decision_total，用于监控评审流程本身的可靠性。
常见陷阱：评审框架不应成为服务上线的阻塞点。建议将评审与 CI/CD 管道解耦——评审通过仅影响目录可见性，不影响服务部署。服务方可以先上线，后补评审，但未评审的服务在自助目录中标记为“未认证”状态。