分级的难点不在定义四级，而在周五晚上那三十秒里判断它属于哪一级。
一、周五晚上的「小问题」
周五 21:40，一位客户在支持群里发了一句「导出按钮点了没反应」。司南在手机上点了两下，转圈两秒后没有动静，他判断是前端的小毛病，标成 P3，写进下周的列表，然后关掉电脑。
周一 09:20，同一个群里三位客户说导出失败。日志显示，从周五 22:10 起，导出接口在任务超过 2000 条时超时，周末累计 41 次 504。三位都是月付最高的那批客户，其中一位在邮件里问：「你们周末是不是没人值班？」
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
定级错，后面的动作全错。 时限、通知、是否打断周末，都由级别决定；级别错一格，处置就慢一档。
分级是分配注意力，不是分类归档。 一个人一天只有几小时能修缺陷，级别决定这几小时先给谁。
级别要能被别人复核。 如果只有他能判断，级别就成了心情；判定条件要写成别人看得懂的句子。
报告里的措辞会误导定级。 「按钮没反应」听起来像前端，实际可能是接口超时；定级前先看日志里的状态码，不看用户描述里的动词。
周末的判断力是要打折的。 同一条报告，周六早上的他和周二下午的他，会给出不同的级别；例外规则承认这个折扣，而不是假装没有。
二、四级：判定、例子与时限
四级对应四种打断程度，不是四种严重感。
| 级别 | 判定 | 例子 | 时限 | 谁来决定 |
|---|---|---|---|---|
| P0 | 丢数据、收错钱、所有人进不去 | 结账 500、登录全挂、误删项目 | 2 小时 | 他本人，且立刻停手 |
| P1 | 关键路径坏了，但有绕行 | 导出失败、邀请邮件不发、权限保存无效 | 24 小时 | 他，需一位客户确认影响 |
| P2 | 非关键路径坏了或体验明显受损 | 排序错、筛选丢状态、报表少一列 | 下一个周末前，最长 9 天 | 他，可批量处理 |
| P3 | 文案、边缘场景、低频问题 | 错别字、罕见浏览器样式错位 | 本季度 | 他，季度批量 |
P0 只认三个触发词。 丢数据、收错钱、进不去；其余一律不进 P0。否则每周都会有 P0，P0 就不再意味着停手。
P1 要有一个具体客户。 说不出「谁受影响、影响了什么」，就不是 P1；这条要求能挡掉大半的情绪化升级。
P2 的时限按「下一个周末」算。 周五报的问题，下一个周末可能是九天以后；这个口径让 4.6 天的中位修复落在时限内，而不是自欺欺人。
P3 进季度批量。 每季度末清一次，清不完的重新定级；P3 不是垃圾桶，是「这一季不值当单独发版」的集合。
级别与工时无关。 一个改价格文案的 P0 仍然要两小时内修；一个要重写模块的 P3 仍然可以排到季度末。级别看后果，不看要花多少时间。
判定句里不放「严重」两个字。 「严重」无法复核；「所有人无法登录超过五分钟」可以复核。定义要写成第三个人也能验证的句子。
三、四十七个缺陷的实际表现
把一年 47 个线上缺陷按级摊开，才能看出时限是否真被遵守。
| 级别 | 数量 | 中位修复 | 时限内 | 达标率 |
|---|---|---|---|---|
| P0 | 3 | 1.2 小时 | 3/3 | 100% |
| P1 | 9 | 18 小时 | 7/9 | 77.8% |
| P2 | 21 | 4.6 天 | 17/21 | 81.0% |
| P3 | 14 | 23 天 | 11/14 | 78.6% |
| 合计 | 47 | — | 38/47 | 80.9% |
P0 的 1.2 小时不是效率，是样本太少。 三次都是同一类问题：迁移漏字段、密钥过期、队列停摆；修得快是因为见过，不是因为流程好。
P1 漏掉的两条都在等客户回复。 18 小时的中位里有一半是等确认；时限应该从「确认影响」开始算，而不是从收到报告开始，否则守时的定义会被别人的回复速度决定。
P2 是最大的一格，也最容易拖。 21 条里 17 条按时，4 条超时；超时的共同点都是「不影响付款」，于是每周都被往下推一周。
P3 的 23 天看着差，其实在季度内。 一个季度 90 天，23 天的中位修复离时限还有很大余量；这一级的纪律不是快，是不遗忘。
达标率要按级看，不看总数。 80.9% 这个总数字没有行动含义；P1 的 77.8% 才指出问题出在等客户确认这一段。
中位修复时间会掩盖长尾。 P2 的 4.6 天中位后面还有超过 20 天的个案；不单独看最长的那几条，分级会显得比实际更有效。
四、周末例外与工时复算
周末例外只有一句：周五 18:00 到周一 09:00 收到的报告，如果 30 分钟内判不出级别，先按 P1 收，24 小时内给答复，周一再降级。
过去一年触发 6 次，其中 4 次周一降为 P2，2 次确认是 P1。代价是 4 次提前排查，都发生在周末的碎片时间里，没有占用工作日的修复预算。
复算：
3 + 9 + 21 + 14 = 47
3 + 7 + 17 + 11 = 38
38 ÷ 47 = 0.8085 ≈ 80.9%
修复工时 = 3×2.5 + 9×4 + 21×1.5 + 14×0.5 = 7.5 + 36 + 31.5 + 7 = 82.0 h
82.0 + 回归沟通 4.5 = 86.5 h
周末例外的成本可控。 它把「周末无法准确判断」这个真实约束写进流程，而不是要求自己在周六早上做出冷静分级。
降级要留一句话。 周一降级时写「为什么当时按 P1 收」，下次遇到同类报告能直接判对。
例外不能反向用。 工作日 30 分钟判不出来的，也该先按 P1 收；例外是时间窗口，不是级别豁免。
86.5 小时里没有「排查」。 82.0 小时是四级的修复工时，4.5 小时是回归与沟通；排查散在各处没有单独记账，这是这套账的一个缺口。
例外要写进模板，不写进文档。 文档没人翻；缺陷表单上多一个「是否周末报告」的勾选，才会在填的时候被想起。
降级的动作要具体。 「降为 P2」不够，要同时改时限、从当周列表移到下周、并在原报告下留一句原因。
这套账每季度对一次。 47 个缺陷、86.5 小时、80.9% 三个数放在一页上，能看出哪一级在恶化；不对账，分级会慢慢退化成称呼。
五、行动清单与复算验收
先把判定句写进缺陷模板，再谈达标率。
- 把四级判定写成四句话，放进缺陷模板的必填项。
- 每条缺陷必填「影响谁、能否绕行、是否涉及钱和数据」。
- P0 只保留三个触发词：丢数据、收错钱、进不去。
- P1 时限 24 小时，超时必须给客户一句书面说明。
- P2 时限写成「下一个周末前，最长 9 天」，注明起算点。
- P3 每季度末清一次，未清的重新定级。
- 周末例外：30 分钟内判不出级别的一律先按 P1 收。
- 每月统计各级数量、中位修复与达标率。
验收标准：随手抽 10 条已关闭缺陷，你能在 30 秒内说出它为什么是那一级；说不出来，分级就只是标签。
使用边界与实操验收
分级只管时限，不管顺序，也不管对客户的承诺。
两个 P1 同时来，仍要选一个先修。 分级给的是最晚什么时候修，不是先修哪个；顺序看影响面和绕行成本。
级别会随规模变化。 同一个导出超时，在 40 个客户时是 P1，在 300 个客户时可能是 P0；每次周复盘重看未关闭的 P2。
时限是内部节奏，不是 SLA。 对客户的承诺写在合同或服务条款里，与这里的 2 小时、24 小时是两套东西，不能混用。
级别不能代替沟通。 P0 修完仍要写一句人话说明发生了什么；本文不构成对客户 SLA、赔偿或合规义务的承诺。
关键参考与核验范围
链接只用于核对错误语义与止损手段的一般定义。
- MDN HTTP 状态码 ：用于说明 5xx 与 4xx 在定级时的区别。
- RFC 9110 ：用于说明服务端错误语义的规范定义。
- Stripe Webhooks ：用于说明支付回调失败为何要按最高级别处理。
- 功能开关 ：用于说明用开关降级换取修复时间。
- Stripe 测试模式 ：用于说明测试密钥与生产密钥的前缀差异，以及为什么这类差异值得单独定级。
以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。
范围上只讨论缺陷的级别、时限与周末处理，不讨论客户支持流程、赔偿口径与事故公关；那些属于支持与运维的题目。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。