渠道对比
| 渠道 | 打扰强度 | 适用级别 | 注意点 |
|---|---|---|---|
| 电话 / 呼叫 | 强 | P0、P1 | 需要个人可触达通道与兜底 |
| 短信 | 较强 | P0、P1 | 内容短，要有送达回执 |
| IM 群 / 机器人 | 中 | P2 与协同场景 | 消息量大时容易被淹没 |
| 邮件 | 弱 | P3 与留痕 | 适合长文与事后追溯 |
要求“确认收到”的告警必须走强打扰通道；群消息适合告知，不适合承载确认责任。
本包目录（282 条）
监控体系与方法40 条Prometheus 与采集64 条Grafana 与看板53 条日志平台52 条链路追踪23 条
告警与响应50 条
- 告警分级：P0-P3 与响应时效
- 路由树：continue 与子路由匹配顺序
- Alertmanager 的职责与告警数据流
- 抑制规则：高层故障压制衍生告警
- group_by 分组：把相关告警压成一条
- 静默：窗口内压制通知与到期清理
- 通知节奏：group_wait、group_interval 与 repeat_interval
- 通知模板：define、range 与常用字段
- 值班轮换：排班、交接与兜底
- 无责复盘：时间线、贡献因素与改进项
- 匹配器语法：=、!=、=~ 与 !~
- amtool：告警、静默与配置校验的命令行
- Runbook：把排障动作写成一页纸
- 事故处理流程：先止损，后追因
- Alertmanager 配置骨架：一份可参考的结构
- 告警收敛：去重、聚合、抑制与静默的分工
- 页面、工单与日志：按可行动性分三档
- 事故分级：SEV1-SEV4 与宣布机制
- 告警即代码：评审、校验与回滚
- Kubernetes 告警：PrometheusRule 实践
- Webhook 接收器：payload 结构与中继要求
- Alertmanager 高可用：gossip 集群
- 告警风暴：从依赖树顶部掐断传导
- 升级策略：未确认时逐级唤醒
- 告警疲劳：信号识别与治理顺序
- 变更窗口静默：发布流水线自动化
- Grafana 统一告警：组件与适用场景
- Grafana 告警规则：条件与待触发期
- AlertmanagerConfig：命名空间级路由
- 邮件接收器：smtp 参数与投递要点
- PagerDuty 接收器：routing_key 与去重
- Alertmanager API v2：查询告警与自动化静默
- 事故角色：IC、OL 与 CL 的分工
- 告警定期巡检：合并、降级与删除
- 告警生命周期：pending 到 resolved
- 误报分析与阈值调参顺序
- 静默治理：审计、过期与责任
- Grafana 接触点与通知策略
- Slack 接收器：api_url 与消息字段
- 企业微信接入：应用消息与群机器人两条路
- 配置热重载：校验、单台验证、逐台推进
- 值班质量周报：页面次数与噪声度量
- 通知渠道选型：电话、IM 与邮件的分工
- 维护窗口：计划静默与收尾核对
- 通知通道例行测试与升级链演练
- 告警文案：一行说清什么坏了
- 告警归属：owner 与服务目录对齐
- Grafana 静音定时：周期维护窗口
- 值班交接检查单
- 通知限流：保护人与通道
通知渠道选型：电话、IM 与邮件的分工
渠道按打扰强度配级别：电话/短信给必须立刻响应的 P0/P1，IM 给在班内处理的 P2，邮件给留痕类；每级保留一条兜底通道。
易错点
- 用 IM 承载 P0：夜间静音模式下无人被叫醒
- 所有渠道无条件全发，打扰叠加，疲劳加倍
数据来源与参考
- PagerDuty 文档 · Notification Channels
- Google SRE Book · 第 6 章