MTTR优化：事件触发Runbook联动CICD方案 - 第4节

4.1 CI/CD 定义与核心价值

CI/CD（持续集成/持续部署）是现代 DevOps 实践的基石，也是事件触发 Runbook 联动方案中自动化流水线的底层引擎。理解 CI/CD 的定义与边界，是构建 MTTR 优化体系的前提。

4.1.1 持续集成（CI）

持续集成要求开发人员频繁地将代码变更合并到共享主干（通常每天多次）。每次合并都会触发自动化构建与测试，以尽早发现集成错误。

• 频率：每次代码推送（push）或合并请求（PR/MR）触发。
• 核心活动：代码编译、单元测试、静态代码分析、代码风格检查。
• 目标：快速反馈，在几分钟内告知开发者代码是否“健康”。
• 失败处理：流水线失败则阻止合并，修复前不允许进入下一阶段。

4.1.2 持续部署（CD）

持续部署在 CI 的基础上，将通过所有测试的构建产物自动部署到目标环境（测试、预发布、生产）。它消除了手动点击“发布”按钮的环节。

• 频率：每次 CI 通过后自动触发，可达到每天数十次甚至上百次。
• 核心活动：环境配置、制品分发、数据库迁移、服务滚动更新、健康检查。
• 目标：缩短交付周期，让新功能或修复在数分钟内到达用户。
• 安：必须包含自动化回归测试、金丝雀发布、蓝绿部署或回滚机制。

4.2 持续集成与持续部署的区别

下表从多个维度清晰对比 CI 与 CD 的差异，帮助你在 Runbook 设计中正确划分职责边界。

4.3 CI/CD 流水线核心组件

一条完整的 CI/CD 流水线由多个标准化组件串联而成。每个组件在事件触发 Runbook 联动方案中都有明确的职责和可观测性要求。

4.3.1 流水线组件全景

下图展示了一条典型 CI/CD 流水线的核心组件及其数据流向，从代码提交到生产部署的完整链路。

4.3.2 组件职责与选型参考

下表列出每个核心组件的关键职责、常见工具选型以及在 MTTR 场景中的特殊要求。

4.3.3 流水线门禁与质量阈

在事件触发 Runbook 联动方案中，流水线门禁是防止“修复引入新故障”的关键防线。每个门禁点都应配置明确的质量阈值。

# .ci-pipeline-gates.yaml
gates:
  - name: "代码规范检查"
    type: "lint"
    threshold: "error_count == 0"
    action_on_fail: "block_pipeline"
  - name: "单元测试覆盖率"
    type: "coverage"
    threshold: ">= 80%"
    action_on_fail: "warn_only"  # 紧急修复可放宽
  - name: "安全漏洞扫描"
    type: "sast"
    threshold: "critical == 0 AND high <= 3"
    action_on_fail: "block_pipeline"
  - name: "集成测试通过率"
    type: "e2e"
    threshold: "pass_rate == 100%"
    action_on_fail: "auto_rollback"

4.4 CI/CD 与 Runbook 联动的架构示意

下图展示事件触发 Runbook 如何与 CI/CD 流水线各组件交互，形成“告警→诊断→修复→验证→部署→观测”的闭环。