2. 质量门禁基础概念
质量门禁（Quality Gate）是 DevOps 流水线中一道自动化的“检查关卡”。它通过预设的阈值规则，对交付物（代码、构建产物、部署环境）进行量化评估，只有通过所有门禁检查的变更才能进入下一阶段。门禁的本质是将质量决策从“人工评审”转变为“数据驱动”，从而在早期拦截缺陷、降低修复成本。
2.1 什么是质量门禁
质量门禁是一组可编程的、自动执行的检查条件，通常部署在 CI/CD 流水线的关键节点上。当代码提交、构建完成或准备部署时，门禁会触发一系列度量采集与阈值比对：
- 阻断（Block）：未通过门禁的变更被直接拒绝，无法合并或部署。
- 警告（Warn）：未通过门禁但允许继续，触发告警通知相关责任人。
- 记录（Record）：仅记录度量结果，用于趋势分析，不阻断流程。
核心原则：门禁阈值必须与业务 SLA 对齐，避免“过度门禁”导致流水线阻塞，或“门禁过松”导致质量失控。
2.2 门禁卡点类型
根据检查维度，质量门禁可分为三大类：代码质量门禁、性能门禁和可用性门禁。每类门禁关注不同的度量指标与阈值策略。
| 门禁类型 | 检查维度 | 典型指标 | 阈值示例 |
|---|---|---|---|
| 代码质量 | 静态分析、代码规范、安全漏洞 | 圈复杂度、代码重复率、安全热点数 | 圈复杂度 ≤ 15；重复率 ≤ 5%；0 个 blocker 漏洞 |
| 性能 | 响应时间、吞吐量、资源消耗 | P95 延迟、QPS、CPU 使用率 | P95 延迟 ≤ 200ms；QPS ≥ 1000；CPU ≤ 70% |
| 可用性 | 服务健康、错误率、SLA 达标 | 错误率、健康检查通过率、MTTR | 错误率 ≤ 0.1%；健康检查通过率 ≥ 99.9% |
实践建议：在门禁初期，建议先设置“警告”级别，观察一周数据后再调整为“阻断”。避免因阈值不合理导致大量误阻断，影响团队交付效率。
2.3 门禁在 DevOps 流程中的位置
质量门禁通常部署在以下四个关键节点，形成“四道防线”：
- 代码合并前（Pre-merge Gate）：在 Pull Request 阶段触发，检查代码质量与单元测试覆盖率。
- 构建完成后（Post-build Gate）：检查构建产物完整性、依赖安全漏洞、制品大小。
- 测试通过后（Pre-deploy Gate）：检查性能基准、集成测试通过率、环境一致性。
- 部署上线前（Production Gate）：检查金丝雀指标、错误预算消耗、SLO 达标情况。
2.4 门禁阈值与告警规则的协同关系
质量门禁与 Grafana 告警规则并非独立存在，而是形成“门禁-告警”协同闭环：
- 门禁负责阻断：在流水线中实时检查，未通过则阻止变更进入下一阶段。
- 告警负责通知：在运行环境中持续监控，当指标偏离基线时触发告警，驱动人工介入。
- 协同调优：门禁阈值应参考告警历史数据（如 P95 延迟的告警触发频率），避免门禁阈值过于严格或宽松。
常见误区：将门禁阈值与告警阈值设置为完全相同的值。这会导致门禁频繁阻断，或告警失去预警意义。正确做法是：门禁阈值应比告警阈值更严格（例如告警阈值 P95 200ms，门禁阈值设为 180ms），为运维响应预留缓冲时间。
2.5 门禁实施清单
在实施质量门禁时，建议按以下清单逐步落地：
| 步骤 | 动作 | 输出 |
|---|---|---|
| 1 | 识别关键质量指标（KQI） | 指标清单与采集方式 |
| 2 | 设定初始阈值（基于历史数据） | 阈值配置表 |
| 3 | 在 CI/CD 工具中集成门禁插件 | 流水线门禁步骤 |
| 4 | 配置 Grafana 告警规则（与门禁阈值联动） | 告警规则 YAML |
| 5 | 观察运行数据，调优阈值 | 调优记录与版本 |