📚 课程目录第2章故障定级标准

2. 故障定级标准：P0-P4 怎么分？响应时间多少？影响范围怎么评估？

说实话，故障定级这事儿，是 SLA 保障里最基础也最容易吵架的环节。我见过不少团队，一上线就为「这个算 P1 还是 P2」争得面红耳赤。为什么？因为标准没对齐。

今天我就把 P0 到 P4 这五个等级的定义、响应时间、影响范围，掰开了讲清楚。你拿回去就能直接用。

下面这张图，是我自己梳理的故障定级决策流程。每次出故障，按这个走，基本不会跑偏。

定义：核心业务完全不可用，所有用户都受影响。说白了，就是「崩了」。

响应时间要求：5 分钟内必须有人响应，15 分钟内开始排查，30 分钟内给出恢复方案。

影响范围：全量用户，或者核心链路（比如登录、支付、查询）完全中断。

我遇到过的情况：有一次凌晨 2 点，核心数据库主库挂了，所有读写都超时。那会儿我还在睡觉，被值班电话叫醒。嗯，P0 故障就是这样，不管几点，你都得爬起来。

注意：P0 故障必须同步给所有相关方，包括技术 VP 和业务负责人。别自己闷头修，该拉群拉群，该升级升级。

定义：核心业务部分不可用，或者非核心业务完全不可用。用户能感受到明显异常，但系统还没彻底挂。

响应时间要求：10 分钟内响应，30 分钟内开始排查，2 小时内恢复。

影响范围：部分用户（比如某个地域、某个渠道）或某个核心功能（比如搜索、下单）不可用。

我的习惯：P1 故障我会先拉一个临时群，把开发、运维、QA 都拉进来。然后快速确认影响面——是某个机房的问题，还是某个版本的问题？定位越快，恢复越快。

定义：非核心业务出现故障，或者核心业务有轻微异常但用户无感知。说白了，就是「能用，但不爽」。

响应时间要求：30 分钟内响应，2 小时内开始排查，8 小时内恢复。

影响范围：单个非核心功能（比如报表导出、历史数据查询）不可用，或者核心功能有性能下降但未中断。

举个例子：数据报表页面加载慢，从 2 秒变成 10 秒。用户能忍，但体验差。这种算 P2。我曾经遇到过一次，是因为后台一个慢查询把连接池打满了。嗯，优化一下 SQL 就解决了。

定义：极少数用户遇到问题，或者功能有轻微缺陷。用户可能不主动反馈，你都不一定知道。

响应时间要求：2 小时内响应，8 小时内开始排查，24 小时内恢复。

影响范围：个别用户、边缘场景、非核心功能的小 bug。

避坑指南：我曾经把 P3 故障拖了三天没处理，结果用户投诉到业务部门，最后升级成了 P2。所以，P3 虽然不急，但也要排期修，别攒着。

定义：不是故障，是用户咨询、功能建议、或者体验优化。说白了，就是「能用，但可以更好」。

响应时间要求：24 小时内响应，48 小时内给出反馈。不需要立即修复。

影响范围：无。不影响任何用户正常使用。

注意：P4 虽然不紧急，但别忽视。很多 P4 反馈其实是潜在故障的前兆。比如用户说「某个页面偶尔报错」，查一下可能发现是底层服务不稳定。

等级	定义	响应时间	排查开始时间	恢复时间	影响范围
P0	核心业务完全不可用	5 分钟	15 分钟	30 分钟	全量用户 / 核心链路中断
P1	核心功能部分受损	10 分钟	30 分钟	2 小时	部分用户 / 单个核心功能
P2	非核心功能异常	30 分钟	2 小时	8 小时	单个非核心功能 / 性能下降
P3	小范围问题	2 小时	8 小时	24 小时	个别用户 / 边缘场景
P4	咨询 / 建议 / 优化	24 小时	48 小时反馈	不要求立即修复	无影响

定级的时候，影响范围是最容易扯皮的。我个人习惯从三个维度来评估：

举个例子：有一次数据同步延迟了 10 分钟，影响了一个报表功能。用户量只有 50 人，而且报表不是核心业务。我评估下来给了 P3。但如果是支付数据延迟 10 分钟，那就是 P1 了。你想想看，同样的延迟，影响完全不同。

误区一：所有故障都往高了报。有人觉得报高一点显得重视，其实不然。P0 报多了，大家会麻木，真正出大事反而没人重视。
误区二：只看技术影响，不看业务影响。技术层面可能只是一个小 bug，但如果影响了核心业务，那就是 P1。反过来，技术层面很严重，但业务有替代方案，可能只是 P2。
误区三：定级后就不变了。故障是动态的。一开始可能是 P2，但排查后发现影响面更大，就要升级到 P1。别死扛。

我的经验：定级的时候，拉上业务方一起评估。他们最清楚用户能不能忍。技术觉得天塌了，业务可能说「没事，用户能等」。反过来也一样。