2. 告警管理体系：告警来源、告警分类、告警级别定义
告警管理体系，说白了就是我们整个SLA闭环流程的“地基”。
你想想看，如果连告警从哪来、属于什么问题、到底有多严重都分不清楚，后面谈什么处置时效、升级策略，全都是空谈。
我个人习惯，在设计任何告警流程之前，先把“家底”摸清楚。也就是把告警的来源、分类和级别这三个东西定死。
核心观点： 告警管理体系的三个支柱——来源决定覆盖，分类决定处理路径，级别决定响应速度。
2.1 告警来源：你的“情报网”得织全
告警不是凭空冒出来的。它们都来自我们布设的各个监控系统。
如果来源没覆盖全，就好比打仗时地图少了几个区域，敌军都打到家门口了你还没收到信号。
常见的告警来源，我大致分为五类：
- 基础设施监控： 服务器CPU、内存、磁盘、网络流量。这是最传统的，也是基本盘。
- 应用性能监控： 接口响应时间、错误率、慢SQL。这部分直接关系到用户体验。
- 业务指标监控： 订单成功率、支付转化率、用户登录量。这块最容易漏掉，但往往最要命。
- 安全监控： WAF告警、DDoS攻击、异常登录。安全无小事，但它跟普通运维告警的处理流程完全不同。
- 日志告警： 通过关键词或异常模式从日志中提取的告警。比如OOM关键字匹配。
我在项目中遇到过，有个团队只配了基础设施监控，结果业务挂了半天才发现是数据库连接池耗尽。应用监控根本没布。所以我的建议是：每上线一个系统，必须复核它的“监控清单”，缺一不可。
2.2 告警分类：别让不同的问题进同一个管道
有了告警源，接下来就要分类。
为什么要分类？因为不同类型的问题，处置流程和责任人完全不一样。
我曾经见过一个团队，把所有告警都丢到同一个群里，结果网络问题和业务问题混在一起，运维和研发都去抢，效率低得吓人。
我建议按以下维度分类：
- 技术域分类：
- 基础设施类（网络、主机、存储）
- 应用类（代码错误、依赖故障）
- 中间件类（Redis、MQ、Kafka）
- 数据库类（慢查询、连接数、复制延迟）
- 业务域分类：
- 关键业务链路告警（如支付、登录）
- 非关键业务告警（如后台报表）
- 响应类型分类：
- 自动恢复型（比如丢一个包自动重试）
- 人工介入型（需要工程师上机排查）
- 通知知悉型（只是看看，无需立即处理）
分类明确了，后续的“告警路由”才好做。不同的分类，自动匹配不同的SLA目标和处置SOP。
| 告警分类 | 典型来源 | 默认处置角色 | SLA目标 |
|---|---|---|---|
| 基础设施 | Zabbix / Prometheus | 运维工程师 | P1: 30min介入 |
| 应用性能 | APM / 自定义监控 | 研发工程师 | P1: 15min介入 |
| 业务指标 | 业务监控平台 | 产品/研发 | P1: 5min介入 |
| 安全 | WAF / IDS | 安全工程师 | P0: 即时响应 |
2.3 告警级别定义：不是所有火都要用消防车
这是最容易扯皮的地方。什么算P0？什么算P3？
如果定义模糊，就会出现两种情况：要么全当P0处理，大家天天救火；要么P1降级成P2，拖到业务挂了才后悔。
我一般用“影响范围 + 业务重要性 + 是否涉及客户资金/数据” 来定级。
- P0（紧急）： 核心业务完全不可用，或涉及数据丢失/资金损失。需要立即拉通所有相关方，全员响应。
- P1（严重）： 核心业务功能受损，但有降级方案。需要专人跟进，SLA目标一般在30分钟内。
- P2（一般）： 非核心功能异常，或有明显的性能劣化。可排队处理，但需当日闭环。
- P3（提示）： 个别用户报障，系统偶尔报错，不影响整体。可由值班人员周知，不记入SLA考核。
注意：定级不是一成不变的。比如一个P2告警如果在1小时内没有好转，且影响范围扩大，就必须升级到P1。我曾经在项目里定义过“升级机制”：连续触发3次，或持续超过30分钟，自动提升一个级别。这个策略救了多次大故障。
2.4 三者关系：一根链条上的三个环
告警来源、分类、级别，不是三个独立的东西。它们是一个完整的管道：
来源（输入）→ 分类（分拣）→ 级别（标定优先级）
来源没覆盖，后面全是盲区。分类没做好，告警就进错了队列。级别没定准，SLA就形同虚设。
下面这张图描述了三者之间的逻辑关系。你可以把它当作设计体系的骨架图：
嗯，这里要注意的是，这张图只是一个总览。后面几章我们会深入到每一个环节，比如“告警来源的接入标准”、“分类标签的自动化方案”、“级别的动态调整机制”。
但无论如何，先把这三个东西画出来，跟团队达成共识。否则，所有告警只会是噪音。
我总结一句话： 告警管理的本质不是“收到告警”，而是“收到对的告警，分给对的人，并给一个合理的处理时限”。
把来源、分类、级别搞清楚，你就已经走完了一半的路。