4. 常见质量门禁类型：代码扫描门禁、单元测试覆盖率门禁、集成测试门禁、安全漏洞扫描门禁

质量门禁是发布流水线中的自动化检查点，用于在代码从提交到上线的每个阶段拦截不符合质量标准的变更。在 MTTR 复盘口径下，门禁的配置粒度、执行时长和失败率直接影响故障恢复的决策路径。本章逐一拆解四种核心门禁类型的检查对象、阈值设定原则及对 MTTR 的潜在影响。

4.1 门禁类型全景对比

四种门禁覆盖了代码静态质量、动态正确性、集成兼容性和安全合规性四个维度。下表从检查时机、主要工具、典型阈值和 MTTR 关联度四个维度进行横向对比：

4.2 代码扫描门禁

代码扫描门禁在变更进入主分支前执行静态分析，检查代码规范、潜在缺陷、重复代码和复杂度指标。其核心价值在于将质量问题左移到开发阶段，避免缺陷流入下游环节。

关键检查项：

• 阻断性缺陷（Blocker）： 空指针、资源未关闭、SQL 注入等必须修复的问题。
• 新增代码覆盖率： 确保新代码有足够的测试覆盖，通常要求 ≥ 80%。
• 圈复杂度： 单个方法复杂度超过 15 时建议重构。
• 重复代码率： 超过 3% 时触发告警。

MTTR 复盘关注点：

• 扫描执行时长是否超过 5 分钟？长扫描会阻塞流水线，间接延长 MTTR。
• 误报率是否过高？频繁的误报会导致开发人员忽略真实问题，增加故障排查成本。
• 阻断性缺陷是否集中在特定模块？如果是，说明该模块的代码质量存在系统性风险。

4.3 单元测试覆盖率门禁

单元测试覆盖率门禁确保代码变更具备足够的测试防护网。覆盖率指标通常包括行覆盖率、分支覆盖率和方法覆盖率。门禁在构建阶段执行，失败时阻止制品进入下一环节。

阈值设定原则：

• 行覆盖率： 建议 ≥ 70%，核心业务模块 ≥ 85%。
• 分支覆盖率： 建议 ≥ 60%，条件逻辑复杂的模块 ≥ 75%。
• 增量覆盖率： 新增代码的覆盖率必须 ≥ 80%，防止通过大量低覆盖代码拉低整体指标。

MTTR 复盘关注点：

• 覆盖率门禁失败后，修复时间是否超过 30 分钟？如果是，说明测试设计存在缺陷。
• 是否存在“覆盖率盲区”？即覆盖率达标但故障仍然逃逸的模块。
• 单元测试执行时间是否超过 10 分钟？长执行时间会拖慢整个流水线。

4.4 集成测试门禁

集成测试门禁在构建完成后、部署到生产环境前执行，验证服务间的交互、API 契约和端到端业务流程。它是发布前的最后一道自动化防线。

典型检查场景：

• 关键业务路径： 登录、下单、支付等核心流程必须 100% 通过。
• API 契约验证： 请求/响应结构、状态码、字段类型必须与契约一致。
• 性能基线： 关键接口的 P99 响应时间不能超过基线值的 120%。
• 数据一致性： 跨服务事务的最终一致性检查。

MTTR 复盘关注点：

• 集成测试失败时，定位根因的平均时间是多少？如果超过 15 分钟，说明测试用例的断言粒度不够细。
• 是否存在“脆性测试”？即因环境波动而非代码缺陷导致的失败，这类测试会制造噪音。
• 集成测试套件的执行时间是否超过 30 分钟？长执行时间会延迟故障发现。

4.5 安全漏洞扫描门禁

安全漏洞扫描门禁在制品入库前或部署前执行，检查依赖库、容器镜像和代码中的已知漏洞。它是防止安全事件进入生产环境的最后屏障。

扫描维度：

• 依赖库漏洞： 通过 CVE 数据库匹配第三方组件的已知漏洞。
• 容器镜像扫描： 检查基础镜像、操作系统包和应用程序依赖中的漏洞。
• SAST（静态应用安全测试）： 检测代码中的安全缺陷，如注入、XSS、硬编码密钥。
• DAST（动态应用安全测试）： 对运行中的应用进行黑盒扫描。

阈值设定原则：

4.6 门禁执行流程与 MTTR 影响

下图展示了四种门禁在发布流水线中的执行顺序及其对 MTTR 的潜在影响路径：

4.7 门禁配置的 MTTR 复盘清单

在 MTTR 复盘会议中，针对质量门禁部分，建议逐一核对以下清单：

1. 门禁执行时长： 每个门禁的平均执行时间是否超过 10 分钟？如果是，考虑并行化或优化扫描策略。
2. 门禁失败率： 过去 30 天内，每个门禁的失败率是否超过 15%？高失败率可能意味着阈值过于严格或代码质量存在系统性问题。
3. 误报率： 门禁失败中，有多少是误报？误报率超过 20% 时需要调整规则或工具配置。
4. 漏报率： 已发布的故障中，有多少未被门禁拦截？漏报率超过 5% 时需要补充新的检查规则。
5. 门禁与故障关联性： 最近 3 次生产故障中，是否有门禁本应拦截但未拦截的？如果有，说明门禁覆盖存在盲区。
6. 人工干预频率： 因门禁失败而触发人工审批的次数是否在增加？频繁的人工干预会削弱自动化的价值。