3. 变更门禁概念：什么是变更门禁（Change Gate）
变更门禁（Change Gate）是 CI/CD 流水线中设置在关键阶段之间的自动化质量关卡。它通过预定义的规则集对变更产物（代码、配置、镜像）进行实时校验，只有通过所有门禁规则的变更才能进入下一阶段或最终发布。门禁的本质是将“事后发现”转变为“事前阻断”，是保障生产环境稳定性的第一道防线。
3.1 变更门禁的核心作用
| 作用维度 | 具体说明 | 典型场景 |
|---|---|---|
| 质量拦截 | 阻止未通过测试、代码规范检查或安全扫描的变更进入生产 | 单元测试覆盖率 < 80% 时阻断 |
| 合规审计 | 确保变更经过必要的审批流程和变更记录 | 缺少 Change Request 编号时阻断 |
| 风险控制 | 根据变更影响范围动态调整门禁阈值 | 核心服务变更需额外通过性能压测 |
| 可观测性联动 | 将日志、指标、链路数据纳入门禁判断依据 | Loki 查询到错误日志激增时阻断 |
3.2 变更门禁在 CI/CD 流水线中的位置
典型的 CI/CD 流水线包含多个阶段，变更门禁通常部署在以下关键节点：
- 代码提交门禁：在 Git Hook 或 PR 合并前触发，检查代码风格、静态分析、敏感信息泄露。
- 构建门禁：在镜像或制品构建完成后，校验构建产物完整性、依赖漏洞扫描结果。
- 测试门禁：在自动化测试执行后，根据测试通过率、覆盖率、性能基线进行判断。
- 发布门禁：在灰度或全量发布前，结合可观测性数据（如 Loki 日志异常率）做最终放行决策。
关键认知： 变更门禁不是单一的检查点，而是一套可编排的规则引擎。在《Loki变更门禁接口调用与日志平台联动调试方案》中，我们将重点实现“发布门禁”与 Loki 日志平台的深度联动——通过调用 Loki 的查询接口，将实时日志异常指标作为门禁判断的输入参数。
3.3 变更门禁的典型工作流程
下图展示了变更门禁在 CI/CD 流水线中的标准执行流程，以及它与日志平台联动的关键节点：
3.4 变更门禁的规则类型
根据数据来源和判断逻辑，变更门禁规则可分为以下三类：
- 静态规则：基于代码、配置、制品本身的属性判断，不依赖外部系统。例如：代码行数不超过阈值、禁止使用高危函数、镜像标签必须包含版本号。
- 动态规则：需要调用外部系统 API 获取实时数据。例如：调用 Loki 查询最近 5 分钟的错误日志数量、调用 Prometheus 获取 CPU 使用率趋势。
- 复合规则：组合多个静态和动态规则，通过逻辑运算（AND/OR/NOT）得出最终结论。例如：错误日志率 < 1% 且 CPU 使用率 < 80% 且 代码审查已通过。
实践建议： 在初始阶段，建议先实现 2~3 条核心动态规则（如 Loki 错误日志率、Prometheus 错误率），验证门禁与可观测平台的联动稳定性后，再逐步扩展规则库。避免一次性配置过多规则导致流水线执行时间过长。
3.5 变更门禁与可观测性平台的联动价值
传统门禁仅关注变更本身的质量（如代码规范、测试覆盖率），而忽略了变更对生产环境运行时状态的影响。将 Loki 等可观测性平台纳入门禁体系后，可以实现：
| 传统门禁 | 联动可观测性后的门禁 |
|---|---|
| 仅检查代码静态质量 | 同时检查代码质量和运行时日志异常 |
| 无法感知灰度期间的异常 | 通过 Loki 实时日志判断灰度流量是否正常 |
| 门禁结果只有通过/阻断 | 可输出详细的日志异常上下文，辅助排查 |
| 门禁规则变更需要重新部署 | 通过配置中心动态调整 Loki 查询语句和阈值 |
注意： 联动可观测性平台的门禁会增加流水线执行时间（通常增加 5~15 秒用于 API 调用和数据等待）。建议为日志查询设置合理的超时时间（如 10 秒），并在门禁规则中配置熔断机制——当 Loki 服务不可用时，默认放行并告警，避免阻塞整个发布流程。