# 没有统一的 P1 定义，每个 Bug 都会变成危机

> 上线前约定一张四级表，分清哪些故障值得半夜打电话，哪些可以等到早上。

原文: https://fdetimes.net/zh/guides/define-incident-severity-levels-with-client/

晚上十一点，手机震了。客户的运营负责人发来消息：“P1，导出报表按钮错位了。”你打开电脑，确认按钮确实偏了几个像素，这才意识到，这已经是本周第三次为一个不必在早上之前修好的故障被叫醒。

客户并不是故意刁难。他们按自己的理解使用 P1 这个词，你则按自己团队的理解。事件管理平台 Rootly 说得很直白：P1/P2/P3 或 SEV0/SEV1/SEV2 这类标签并没有通用标准。

对前线部署工程师（FDE）来说，这个问题比内部 SRE 团队更棘手，因为你夹在两个组织之间。OneUptime 写道，没有清晰的定义，每起事件都会变成一场争论。

避免的办法是：上线前和客户坐下来，写清 P1 到 P4 四个等级，双方签字。

## 一个标签，两个问题

客户说“P1”时，其实同时回答了两个问题：情况有多严重，要多快处理。Rootly 把两者分开：严重度衡量事件的影响，优先级决定行动的速度。人们往往把这两个概念混为一谈，半夜的争执通常就从这里开始。

严重度应当用可以计数的东西来衡量。PagerDuty 建议每个组织自定等级，通常以受影响用户或账户的百分比为依据。OneUptime 给出了一个高影响的示例阈值：超过 25% 的用户受影响，或者某个创收功能性能下降。

分几级合适？按 incident.io 的经验，3-5 级比较合适，再少就无法区分不同的事件。P1-P4 四级正好落在这个区间，足以区分“现在就叫人起来”和“放进下一个迭代”。

## 为具体客户定制的表

假设你在为一家保险公司部署一个读取理赔材料的 Agent，每天有 400 名理赔员使用。对这个客户来说，25% 的阈值意味着超过 100 人。你带去会议的表格可以像下面这样，每一行同时写明影响和响应速度。

| 等级 | 影响 | 响应 | 保险公司场景示例 |
|---|---|---|---|
| P1 | Agent 停止运行，或 400 名理赔员中超过 100 人无法处理理赔 | 立即处理，7×24 小时，暂停计划内工作，通知双方管理层 | 模型更新后，每一笔理赔都返回错误 |
| P2 | 较小的一群人在核心功能上受阻 | 在工作日内响应，排在 P1 工作之后 | 30 人无法上传某一类扫描表单 |
| P3 | 质量下降，但有变通办法 | 纳入常规工作排期；除非情况恶化，不在非工作时间打电话 | Agent 把少数罕见理赔分错类，审核人员可以手动纠正 |
| P4 | 轻微或外观上的故障，不影响任何人使用产品 | 开工单；不呼叫任何人 | 导出报表按钮偏了几个像素 |

注意这张表如何在使用单一标签的同时把两个问题分开：“影响”一列回答严重度问题，“响应”一列回答优先级问题。把两者放在同一行，意味着双方事先同意：这种规模的影响对应这种速度的响应，没人需要在半夜重新谈判。

“响应”一列也不是凭空编的：它与 Rootly 对 P1、P2、P3 的定义一致，也符合 OneUptime 关于低等级不在非工作时间打电话的规则，以及 PagerDuty 把外观类故障转为工单的做法。

P1 时通知管理层，对应 PagerDuty 的 SEV-1，即需要公开通报、并与高管直接沟通的事件等级。

现在代入数字。表单故障卡住 30 人，占 400 人的 7.5%，仍低于 25% 的阈值。所以它是 P2，哪怕这 30 个人这一天过得很糟。

如果同一个故障扩散到 120 人，即 30%，就越过阈值，变成 P1。等级由数字决定，而不是由消息的语气决定。至于晚上十一点那个错位的按钮，是 P4：开一张工单，谁也不用被叫醒。

## 上线前的那次会议

草拟的表格只有在客户亲自设定阈值时才有价值。不要问“你希望 P1 是什么？”，这只会招来“什么都重要”的回答。要问人，问时间：

> 你：“如果 Agent 在周日凌晨 3 点停止运行，你希望打电话给谁？你自己要不要接电话？”
>
> 客户：“当然要，整个理赔部门都会停摆。”
>
> 你：“那如果只是某一类表单出问题，大约 30 人受阻，需要半夜叫人起来吗，还是可以等到周一早上？”
>
> 客户：“周一早上就行，只要当天有人处理。”

这两个回答之后，客户自己就画出了 P1 和 P2 之间的界线。你只需要把它记成一个数字。

流程是这样的：会前，统计真实用户数，找出哪些功能与收入挂钩，再用客户自己系统里的例子填好草拟表格。会上，用上面的话术调整阈值。

签字前，在表格底部加两条规则。第一条来自 PagerDuty：拿不准事件属于哪一级时，按更高一级处理，复盘时再回顾。第二条来自 Rootly：初始定级只是临时的，调整等级说明流程在正常运转。

**要点:** 在大家都冷静的时候约定事件等级，而不是在系统着火的时候。

## 为什么这么多表格最后成了废纸？

最常见的错误是只有标签、没有标准。一行写着“P1：严重”，半夜帮不上任何人，因为“严重”恰恰是双方争论的焦点。每一级都需要一个数字或一个具体功能，让值班工程师几分钟内就能核实。

第二个错误是不愿降级。一起按 P1 开出的事件，20 分钟后发现只影响十个人，就应降为 P2，并记录原因，让双方都能看到。如果没人敢降级，客户就会学到：标成 P1 就有人跑过来。不出几周，这张表就失效了。

第三个错误是写完表格就束之高阁。它必须与告警配置和值班排班保持一致。如果 P3 仍会在凌晨 2 点触发呼叫，这张表就只是纸上的承诺。最后，不要因为双方各想要一个例外就加上 P5、P6：等级太多，值班工程师就会把时间花在挑标签上，而不是解决问题。

## 把这张表变成职业履历

当 FDE 岗位描述里出现“on-call”、“incident response”或“SLA”时，正好可以在面试中问一句：谁负责与客户定义事件等级？这个定义写在哪里？答案能相当清楚地告诉你，以后值班的夜晚会是什么样子。

简历上，一句具体的描述比形容词更有分量：“与客户共同制定基于受影响用户比例的 P1-P4 分级表，并直接接入呼叫配置。”如果你有非工作时间呼叫次数的前后对比数据，也写上。

面试时，讲一次你给事件降级的经历，以及你是如何向客户解释的。

这张四行的表格并不会让系统少出故障。它只保证下次手机在半夜震动时，是为了一件真正值得起床的事。

**本周动手试试:**

- 统计你正在部署的系统的真实用户数，把 25% 的阈值换算成具体人数
- 起草一张四行的 P1-P4 表格，每一行写明影响、响应速度，以及来自客户自己系统的例子
- 拿出最近三张标为紧急的工单，按新表格重新定级，看看其中有几张真的值得在非工作时间叫人

## 信源

- [Severity Levels | PagerDuty Docs (Incident Response Guide)](https://docs.pagerduty.com/ops-guides/incident-response-guide/severity-levels)

- [Incident priority vs severity: P1, P2, P3 and SEV levels](https://rootly.com/blog/practical-guide-to-sre-incident-severity-levels)

- [Incident priority vs severity: P1, P2, P3 and SEV levels](https://rootly.com/incident-response/support-levels.md)

- [How to Build Incident Severity Definitions](https://oneuptime.com/blog/post/2026-01-30-incident-severity-definitions/markdown)

- [Designing your incident severity levels](https://incident.io/blog/designing-your-incident-severity-levels)