4. 可靠性评审定义与目标：评审范围、频率与角色

可靠性评审是自助目录从“可用”走向“可信”的核心质量门禁。本章定义评审的四个维度、触发频率以及三方协作角色，确保每个目录项在投产前达到 SLO 基线。

4.1 评审范围：四维可靠性检查

每个目录项在提交评审时，必须覆盖以下四个维度。任一维度不通过，评审即被阻塞。

4.2 评审频率：事件驱动 + 定期复审

评审并非一次性活动，而是贯穿目录项生命周期的持续机制。根据变更类型和风险等级，采用三种触发模式：

1. 首次提交评审 — 新目录项创建时，必须完成全量四维评审。
2. 变更触发评审 — 当目录项配置、依赖版本、安全策略或资源规格发生变更时，自动触发增量评审。
3. 定期复审 — 每季度对所有已上线目录项进行一轮全量复审，确保未因环境漂移而退化。

4.3 评审角色：SRE、平台工程师、应用 Owner

可靠性评审采用三方协作模型，每个角色拥有明确的职责边界和审批权限。

4.4 评审流程与状态机

下图展示了从提交到通过的完整评审状态流转，以及每个阶段对应的角色介入点。

4.5 评审工单与自动化集成

评审过程通过 GitOps 工作流自动驱动，无需人工跳转外部系统。典型集成方式如下：

# .github/workflows/reliability-review.yaml
name: Reliability Review
on:
  pull_request:
    paths:
      - 'catalog/**/reliability-review.yaml'
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Parse review manifest
        run: |
          for file in $(find catalog -name 'reliability-review.yaml'); do
            echo "Checking $file"
            # 配置合规性检查
            yq eval '.config' $file | grep -q 'replicas' || echo "::error::Missing replicas"
            # 依赖版本检查
            yq eval '.dependencies.redis' $file | grep -qE '^7\.' || echo "::error::Redis version must be 7.x"
            # 安全扫描结果检查
            yq eval '.security.critical_vulns' $file | grep -q '0' || echo "::error::Critical vulnerabilities found"
            # 性能基线检查
            yq eval '.performance.p99_latency_ms' $file | awk '{if ($1 > 200) print "::error::P99 latency exceeds 200ms"}'
          done
      - name: Post review status
        run: |
          # 将检查结果写入 PR 评论
          gh pr comment ${{ github.event.pull_request.number }} --body "✅ 可靠性评审完成"