监控体系（Observability / Reliability Platform）
目标：看到异常” → “定位问题” → “持续可靠性治理
P0（可观测基础）
├── Metrics（Prometheus）
├── Logging（ELK / Loki）
├── Tracing（Jaeger / Zipkin）
├── Error Tracking（Sentry）
P1（定位与响应）
├── 秒级大盘（Grafana）
├── 告警平台
├── 事件中心（Incident）
P2（可靠性治理）
├── SLA / SLO 评估平台
├── StatusPage
├── 变更 / 发布关联分析
P3（智能化）
├── RCA 根因分析系统
├── 拓扑感知 / 依赖图
├── 智能异常检测（AIOps）
看见信号 → 定位问题 → 控制影响 → 复盘改进 → 可靠性提升
告警平台
下面我把 告警平台（Alerting Platform） 当成一个独立的一等平台能力来系统展开，而不是“Prometheus + Alertmanager 配几个规则”。
我会从 定位 → 数据模型 → 告警生成 → 降噪 → 事件化 → 人与自动化 → 治理与成熟度 全链路拆解，尽量贴近你前面已经构建的 Observability / Reliability 语境。
一、先定性：告警平台到底是什么
一句话定义：
告警平台不是“发现问题”，而是“在正确的时间，把正确的问题，通知给正确的人或系统”。
这句话里有四个关键词：
- 正确的时间
- 正确的问题
- 正确的对象
- 人 or 自动化系统
👉 任何一个做不好，告警都会变成噪音。
告警 ≠ 监控 ≠ 事件
| 概念 | 本质 |
|---|---|
| Monitoring | 数据采集与观测 |
| Alert | 异常信号 |
| Event / Incident | 需要处理的事故 |
告警是“信号”，不是“事故”。
二、告警平台在体系中的位置
Metrics / Logs / Traces / Error Tracking
↓
告警规则引擎
↓
告警降噪 & 关联
↓
事件（Incident）
↓
Oncall / 自动化
👉 告警平台是“可观测 → 稳定性工程”的闸门。
三、告警数据模型（很多平台做得不完整）
1️⃣ Alert（告警实例）
一次被触发的异常信号
核心字段：
- alert_name
- source（metric / log / error）
- service / env
- severity
- labels / annotations
- start_time / end_time
2️⃣ Alert Rule（告警规则）
不是“阈值”，而是逻辑表达式：
- 条件（What）
- 时间窗口（When）
- 严重级别（How bad）
- 目标对象（Who）
3️⃣ Event / Incident（事件）
多个告警 → 一个事件
字段包括：
- 影响范围
- 状态（Open / Mitigated / Resolved）
- Owner
- RCA / 处理记录
四、告警来源（不只是 Metrics）
1️⃣ Metrics 告警（最常见）
- Error Rate
- Latency
- Saturation
- Burn Rate（强烈推荐）
2️⃣ Log 告警（谨慎使用）
正确方式：
- 日志聚合
- 日志 → 指标 → 告警
错误方式：
- 单条 ERROR 触发
3️⃣ Error Tracking 告警
- 新 Error Issue
- 已修复 Issue 回归
- 高频错误影响用户
👉 这是对开发最友好的告警类型。
4️⃣ 外部信号
- SLA 探测
- 业务健康检查
- 安全 / 风控系统
五、告警规则设计（成败关键）
1️⃣ 告警对象必须是“服务健康”
❌ 错误：
CPU > 80%
✅ 正确：
5分钟内 error_rate > 1%
2️⃣ 时间维度是第一公民
- for: 3m / 5m
- 滑动窗口
- 连续失败次数
👉 大量误报，来自“没有时间概念”。
3️⃣ SRE 推荐：Burn Rate 告警
ErrorBudgetBurnRate > 2x
优点：
- 稳定
- 与 SLO 强绑定
- 不随流量变化抖动
六、告警降噪（告警平台的灵魂）
没有降噪能力的告警平台，一定会失败。
1️⃣ 去重（Deduplication）
- 相同指纹
- 同一服务 / 指标
2️⃣ 聚合（Aggregation）
- 多实例 → 服务级
- 多指标 → 症状级
3️⃣ 抑制（Suppression）
- 根因告警抑制下游
- 维护窗口
4️⃣ 收敛（Correlation）
- 拓扑关系
- 变更关联
- 时间相似性
七、告警 → 事件（Incident）转化
这是平台分水岭。
告警多 → 人崩
事件少 → 可治理
Incident 的最小能力
- 创建 / 升级 / 关闭
- 影响范围评估
- 责任人
- 时间线（Timeline）
和你前面提到的 事件中心 的关系
告警平台负责“信号收敛”， 事件中心负责“事故管理”。
八、通知与响应（Oncall）
1️⃣ 通知不是“发消息”
它是一个责任机制。
- 值班表
- 升级策略
- 兜底策略
2️⃣ 通知渠道
- IM
- 电话 / 短信
- 工单
- 自动化接口
3️⃣ Ack / Resolve 是必须的
没有 Ack 的告警 = 没人负责。
九、告警与自动化 / 自愈
成熟平台一定支持：
- 告警触发 Runbook
- 自动扩容
- 自动重启
- 自动降级
人只处理“机器处理不了的告警”。
十、治理能力（长期不崩的关键）
1️⃣ 告警目录（Alert Catalog）
- 告警含义
- 影响范围
- 处理建议
2️⃣ 告警评审机制
- 新告警必须评审
- 无响应告警必须下线
3️⃣ 指标与告警比例
- 不是所有指标都该有告警
4️⃣ 效果度量
- 告警数量
- 告警命中率
- MTTA / MTTR
十一、成熟度模型（告警平台）
| 阶段 | 特征 |
|---|---|
| L1 | 阈值告警 |
| L2 | 服务级告警 |
| L3 | 降噪 / 聚合 |
| L4 | Incident 驱动 |
| L5 | 自动化 & 智能 |
