2. 可靠性评审基础：评审流程、评审角色、评审输出物（基线文档）
可靠性评审是混沌工程基线核验的“守门人”。在正式注入故障前，必须通过结构化的评审机制确认：环境配置是否满足基线要求、参数配置是否与生产特征对齐、监控埋点是否完整。本章定义评审的三要素：流程（何时做）、角色（谁来做）、输出物（留下什么）。
2.1 评审流程：三阶段五节点
可靠性评审采用“预审-正式评审-复审”三阶段模型，覆盖从环境准备到基线冻结的完整链路。每个阶段包含明确的入口条件和出口标准。
关键原则：评审不通过，基线不冻结；基线不冻结，混沌实验不启动。
2.2 评审角色与职责
评审角色分为决策层、执行层和质量层三层，每层角色在评审中承担不同职责。角色缺失或职责混淆是评审失效的首要原因。
| 角色 | 所属层级 | 核心职责 | 评审中的关键动作 |
|---|---|---|---|
| 评审主席 | 决策层 | 把控评审节奏，裁决争议 | 宣布评审结论（通过/有条件通过/不通过） |
| 可靠性架构师 | 决策层 | 审核基线完整性，确认故障模型覆盖度 | 签署基线文档的“架构合规”章节 |
| 环境配置工程师 | 执行层 | 提供环境配置清单，演示环境就绪状态 | 回答预审阶段的环境检查项 |
| 参数配置工程师 | 执行层 | 展示参数配置表，解释参数取值依据 | 在正式评审中逐项核验参数 |
| 测试代表 | 质量层 | 验证监控埋点，确认可观测性 | 提供监控覆盖度报告 |
| 记录员 | 质量层 | 记录评审决议、待办项、风险项 | 输出评审纪要，跟踪待办闭环 |
实践建议：评审主席不应由环境或参数配置工程师兼任，避免“既当运动员又当裁判员”。建议由不直接参与环境搭建的可靠性架构师或技术经理担任。
2.3 评审输出物：基线文档体系
评审的最终输出物是基线文档，它不仅是混沌实验的输入，更是环境与参数配置的“法律依据”。基线文档包含三个核心子文档，分别对应环境、参数和监控三个维度。
2.3.1 基线文档结构
2.3.2 基线文档的评审通过标准
每个子文档在评审中必须满足以下通过标准，否则基线文档不予冻结：
- 环境基线配置表：所有硬件规格与生产环境偏差 ≤ 5%（CPU 核数、内存大小、磁盘 IOPS）；网络拓扑与生产环境一致；中间件版本号精确匹配。
- 参数基线配置表：每个参数必须有取值依据（生产值、压测值、理论计算值）；参数变更历史可追溯；无未注释的“魔法数字”。
- 监控基线配置表：监控覆盖度 ≥ 95%（按预定义监控项清单计算）；告警阈值与 SLO 对齐；链路追踪采样率 ≥ 1%（生产环境不低于 1%）。
常见评审失败原因：
- 环境基线中遗漏了关键中间件版本（如 Redis 6.2 误配为 6.0）。
- 参数基线中使用了“与生产一致”但未提供生产实际值的模糊描述。
- 监控基线中告警阈值设置为默认值，未根据历史故障数据调整。
2.4 评审输出物的版本管理
基线文档通过评审后进入冻结状态，任何变更必须触发变更评审流程。版本管理规则如下：
| 版本状态 | 说明 | 允许的操作 | 触发条件 |
|---|---|---|---|
| 草稿 | 评审前准备阶段 | 编辑、更新、删除 | 环境/参数首次配置完成 |
| 已评审 | 通过正式评审 | 只读（可查阅不可修改） | 评审主席签署通过 |
| 已冻结 | 基线锁定，混沌实验依赖此版本 | 只读，变更需走变更评审 | 复审通过，所有待办项关闭 |
| 已废弃 | 被新版本替代 | 归档，不可用于实验 | 新基线文档通过评审并冻结 |
版本管理工具建议：使用 Git 管理基线文档，每个评审节点打 Tag（如
baseline-v1.0-reviewed、baseline-v1.0-frozen），确保版本可追溯、可回滚。
2.5 评审效率指标
为持续改进评审质量，建议跟踪以下指标：
- 评审周期：从预审申请到基线冻结的总时长，目标 ≤ 5 个工作日。
- 一次通过率：无需重大修改即通过正式评审的比例，目标 ≥ 80%。
- 待办项关闭率：评审中提出的待办项在复审前关闭的比例，目标 100%。
- 评审缺陷密度：每份基线文档发现的配置错误数，用于评估配置质量。
以上指标应在每次评审后由记录员更新至评审看板，作为下一轮评审的输入。