3. 可靠性评审概述：定义、时机与团队角色

可靠性评审是变更风险评估任务中的核心质量门禁。它并非一次性的技术检查，而是一个结构化的、由跨职能团队参与的正式评估过程，旨在识别、量化并缓解变更可能引入的可靠性风险。本节将系统阐述可靠性评审的定义、在变更生命周期中的触发时机，以及评审团队的关键角色与职责。

3.1 可靠性评审的定义

可靠性评审是一种基于证据的、系统化的审查活动，它通过对比变更方案与既定的可靠性设计准则、历史故障数据、行业最佳实践以及运营约束条件，来评估变更对系统可用性、可维护性及故障恢复能力的影响。其核心输出是一份经过签核的可靠性风险评估报告，其中明确列出已识别的风险项、缓解措施以及残余风险等级。

3.2 评审的时机：变更前、中、后

可靠性评审并非仅在变更实施前进行一次，而是贯穿变更生命周期的三个关键阶段。每个阶段的评审焦点与深度各不相同。

3.3 评审团队的角色与职责

一个有效的可靠性评审团队必须具备跨职能视角，通常由以下核心角色组成。每个角色在评审中承担不同的职责，共同确保评审的全面性与客观性。

3.4 角色职责详解

为确保评审效率，各角色在评审流程中的具体职责应明确界定，避免职责重叠或遗漏。

• 可靠性工程师（评审主席）：负责评审流程的完整性与公正性。在变更前阶段，主导 FMEA 审查；在变更中阶段，监控关键可靠性指标（如错误率、延迟 P99）；在变更后阶段，组织事后复盘并更新可靠性知识库。
• 变更发起人：作为变更方案的主要陈述者，需提前准备可靠性自检清单，并在评审中提供充分的工程证据，证明变更方案已考虑主要故障场景。
• 运维代表：从可运维性角度提出质疑，重点关注变更是否引入了新的运维复杂度、是否破坏了现有的自动化运维工具链、以及回滚操作的可靠性。
• 安全/合规代表：审查变更是否触及安全边界，例如数据加密策略、访问控制列表、审计日志完整性等。对于金融、医疗等强监管行业，此角色拥有一票否决权。
• 测试/QA代表：评估变更的测试策略是否充分，包括单元测试、集成测试、混沌工程测试的覆盖率，以及是否针对已识别的故障模式设计了专门的验证用例。
• 业务/产品代表：从用户体验与业务连续性角度评估变更的潜在影响，例如变更是否会导致功能降级、是否影响关键业务 SLA、以及是否有用户沟通计划。