3. 报警级别定义：P0/P1/P2/P3 四级报警定义与响应时效
报警级别这事，说白了就是给故障分个三六九等。
我刚带团队那会儿，大家一窝蜂地报故障，什么破事都往群里丢。结果呢？真出大事了，反而没人理。后来我痛定思痛，搞了这套 P0-P3 四级体系。嗯，用了好几年，效果还不错。
3.1 为什么是四级？
你想想看，一个线上系统出问题，影响面能一样吗？
用户付不了款，跟后台某个日志查询慢了几秒，能是一个级别吗？
我个人习惯把故障按「影响范围」和「紧急程度」两个维度来切。四级刚好够用——少了分不清轻重，多了又记不住。
核心原则：P0 是灾难，P1 是事故，P2 是问题，P3 是瑕疵。
3.2 P0：系统瘫痪级
这是最要命的级别。整个核心业务挂了，或者大面积用户无法使用。
我记得有一次，支付网关整个集群挂了，所有订单都卡在「待支付」状态。那会儿我正吃着火锅呢，电话就炸了。
- 定义：核心功能完全不可用，影响所有用户
- 响应时效：5 分钟内必须有人响应
- 处理时效：30 分钟内恢复服务
- 升级机制：直接拉 VP 进群
注意：P0 故障不需要走审批流程。先恢复，后复盘。我曾经见过有人还在等领导批准重启服务器，结果多挂了半小时。
3.3 P1：核心功能受损
比 P0 低一级，但依然很严重。核心功能部分不可用，或者影响了一部分重要用户。
举个例子：用户能登录，但查不到历史订单。这算 P1。为什么不是 P0？因为用户还能用其他功能，不至于完全没法用。
- 定义：核心功能部分不可用，影响部分用户或重要客户
- 响应时效：15 分钟内响应
- 处理时效：2 小时内恢复
- 升级机制：通知技术经理
我的经验：P1 故障最容易被人忽视。因为它不像 P0 那么疼，但拖久了就会变成 P0。我曾经见过一个 P1 的慢查询，没人管，结果三天后数据库直接挂了。
3.4 P2：非核心功能异常
这个级别，说白了就是「能用，但体验不好」。
比如：用户头像加载不出来、某个统计报表数据延迟、后台管理页面打开慢。这些不影响核心交易链路，但会让用户不爽。
- 定义：非核心功能异常，不影响主业务流程
- 响应时效：1 小时内响应
- 处理时效：8 小时内修复
- 升级机制：记录到工单系统，按排期处理
这里要注意：P2 故障虽然不急，但不能不处理。我建议每个 P2 都要有明确的负责人和截止时间。
3.5 P3：低优先级问题
这是最轻的级别。通常是体验优化、文案错误、非关键链路的小 bug。
比如：某个按钮颜色不对、帮助文档里有个错别字、某个页面加载慢了 200 毫秒。
- 定义：体验优化类问题，不影响功能使用
- 响应时效：24 小时内确认
- 处理时效：下个迭代版本修复
- 升级机制：纳入产品需求池
避坑指南：我曾经见过有人把 P3 问题直接忽略了。结果呢？用户反馈了半年，最后变成了舆情事件。P3 可以慢，但不能丢。
3.6 四级报警对比表
| 级别 | 定义 | 响应时效 | 处理时效 | 升级对象 |
|---|---|---|---|---|
| P0 | 系统瘫痪，核心功能完全不可用 | 5 分钟 | 30 分钟 | VP 级别 |
| P1 | 核心功能部分受损 | 15 分钟 | 2 小时 | 技术经理 |
| P2 | 非核心功能异常 | 1 小时 | 8 小时 | 工单系统 |
| P3 | 低优先级体验问题 | 24 小时 | 下个迭代 | 需求池 |
3.7 报警级别判定流程图
下面这张图，是我自己画的一个判定流程。每次不确定该定什么级别时，走一遍这个流程就清楚了。
3.8 一些实操建议
最后，分享几个我踩过的坑：
- 别把 P0 当 P1 报。 我曾经有个同事，数据库主库挂了，他觉得「还能读从库」，报了 P1。结果从库也扛不住，半小时后全挂了。该升级就升级，别犹豫。
- P3 也要有闭环。 我见过太多 P3 问题，提了之后石沉大海。建议每个 P3 都要关联到 Jira 或工单系统，至少有个状态跟踪。
- 定期复盘级别定义。 业务在变，报警级别也要跟着调。我每季度会拉一次会，重新审视每个级别的定义是否还合理。
一个小技巧：在报警系统里，把 P0 和 P1 的推送设为「强提醒」——电话+短信+钉钉/微信全渠道轰炸。P2 和 P3 走邮件或工单通知就行。别让不重要的报警吵死人。