门禁策略的取舍
哪些检查失败必须停下来（阻断），哪些先收集信息不打断（告警）。正确性、安全强相关的走阻断；风格类、探索期度量先告警观察，统计出基线后再对增量收紧阈值。判断标准是可行动、可复现——一个检查如果误报率高或团队不知道怎么修，设成阻断只会消耗信任：大家开始习惯性重跑，门禁整体失去公信力。
基本信息
| 阻断型 | 失败即停止流水线：测试失败、高危漏洞、密钥泄露 |
|---|---|
| 告警型 | 只记录不阻断：风格提示、覆盖率趋势、性能基线 |
| 升级路径 | 先统计基线，再对增量设阈值，最后收紧到阻断 |
| 选取原则 | 阻断项必须可行动、可复现；误报要先修误报再上阻断 |
| 责任人 | 阻断项要有明确负责团队与修复时限 |
检查项怎么归类
| 检查 | 建议形态 | 理由 |
|---|---|---|
| 单元测试、编译 | 阻断 | 失败可复现、修复路径明确 |
| 高危漏洞、密钥泄露 | 阻断 | 不处理风险直接进生产 |
| 代码风格 | 告警 | 价值存在但误报与争论成本高 |
| 覆盖率 | 先告警后阻断 | 先建基线，按增量收紧 |
| 性能趋势 | 告警 | 波动大，阈值需要时间校准 |
典型使用场景
- 新引入扫描工具：先以告警跑两周，收集误报清单再决定阻断范围
- 存量代码库：全量修复不现实，先对新增代码阻断（增量门禁）
- 发布前检查：关键路径测试设阻断，整体回归报告供参考
- 安全事件复盘：把曾漏过的检查升级为阻断，并补齐修复指引
- 多团队共用流水线：阻断项按服务分级配置，避免一刀切过严或过松
阶段分工示意
阶段分工示意
stages:
- build
- verify # 阻断型：测试 + 扫描
- report # 告警型：趋势类报告
- deploy把误报多的检查设为阻断：团队会习惯性重跑，门禁逐渐失去公信力。
门禁要有临时出口：紧急场景允许有人豁免并留痕，否则团队会用更隐蔽的方式绕过。