1. 课程导论：告警降噪的背景与挑战、CI/CD流水线在可观测性中的角色、SLI/SLO基本概念回顾
1.1 告警降噪：从“告警风暴”到“精准触发”
在微服务与云原生架构下，一个底层故障可能引发数百条关联告警，形成“告警风暴”。SRE团队面临的核心矛盾是：告警数量爆炸式增长，但有效告警占比不足20%。告警降噪的目标并非消除告警，而是通过算法、流程与工程手段，让每一条告警都具备可行动性（Actionable）。
| 维度 | 传统告警模式 | 降噪后目标模式 |
|---|---|---|
| 触发方式 | 静态阈值 + 固定规则 | 动态基线 + 多维度聚合 |
| 告警量级 | 日均数千条，重复率高 | 日均数十条，去重聚合 |
| 关联能力 | 单指标孤立告警 | 拓扑关联 + 事件压缩 |
| 误报率 | > 40% | < 5% |
| MTTR影响 | 告警淹没，定位延迟 | 精准定位，快速恢复 |
关键挑战：告警降噪不是纯算法问题，而是数据质量、流水线工程与组织协作的综合命题。CI/CD流水线正是连接这三者的“工程化纽带”。
1.2 CI/CD流水线在可观测性中的角色
传统认知中，CI/CD流水线只负责构建、测试与部署。在可观测性体系下，流水线需要承担三个新角色：
- 数据生产者：流水线执行过程中产生的构建时长、测试通过率、部署频率等数据，本身就是重要的可观测性指标。
- 质量门禁执行者：在流水线中嵌入SLI检查点，确保每次变更都满足SLO要求，从源头阻断劣化。
- 告警降噪的“前哨”：通过流水线自动化验证，将“部署后才发现问题”提前到“部署前拦截”，减少生产环境告警。
实践要点：在流水线中嵌入可观测性数据采集（如OpenTelemetry），让每次部署都生成一份“部署健康报告”，而非仅关注构建是否通过。
1.3 SLI/SLO基本概念回顾
SLI（Service Level Indicator）是服务质量的具体度量指标；SLO（Service Level Objective）是SLI的目标阈值。两者共同构成服务健康度的量化标准。
1.3.1 SLI口径：定义与分类
SLI口径决定了“测量什么”以及“如何测量”。常见的SLI分类如下：
| SLI类别 | 典型指标 | 测量口径示例 |
|---|---|---|
| 可用性 | 服务存活率、接口可达性 | 成功请求数 / 总请求数 × 100% |
| 延迟 | P50/P95/P99响应时间 | P99延迟 < 500ms |
| 吞吐量 | QPS、TPS | 每秒处理请求数 > 1000 |
| 错误率 | HTTP 5xx、业务异常 | 错误请求数 / 总请求数 < 0.1% |
| 饱和度 | CPU、内存、连接数 | CPU使用率 < 80% |
1.3.2 SLO：从指标到承诺
SLO将SLI转化为可管理的目标。例如：
- SLI：API P99延迟
- SLO：在30天滚动窗口内，P99延迟 ≤ 500ms 的比例 ≥ 99.9%
SLO的设定需要平衡用户体验与成本，通常采用“错误预算（Error Budget）”机制：
错误预算 = 1 - SLO目标值
示例：SLO = 99.9%，则错误预算 = 0.1%
30天内允许的不可用时间 = 30 × 24 × 60 × 0.001 = 43.2分钟
常见误区：SLI口径不一致是告警降噪失败的主要原因之一。例如，前端监控与后端监控对“成功请求”的定义不同，导致同一故障产生两条不同口径的告警，增加排查噪音。