# 三个客户同时来电，先帮的不该是嗓门最大的

> 把严重程度、紧急程度和已签的 SLA 分开看，前线部署工程师（FDE）就能在十五分钟内排好上午的工作，并讲得出理由。

原文: https://fdetimes.net/zh/guides/fde-incident-triage-severity-urgency-sla/

设想这样一个场景：早上 8:40，手机十分钟内响了三次。三个客户，三个焦急的声音，每个人都确信自己的问题最要紧。

这时多数工程师会凭本能行事：谁嗓门大就先处理谁，或者谁先打来就先处理谁。无论哪种做法，都可能在不知不觉中违反已经签下的承诺。

假设你负责三个部署，每个客户都有自己的合同、工作时间和重要程度。你需要的能力，是在十五分钟内把工作排好顺序，并且能说清为什么这样排。

## 三个不同的问题，而不是一个

根本错误在于把一切都塞进一个词：“紧急”。其实每通电话都包含三个独立的问题，各有各的答案。

第一个是严重程度：这起事件对用户和业务造成多大伤害。在最高一级，PagerDuty 举的例子是 SEV-1：影响大量客户的严重事件，通常需要发布公告，并需要有人直接与高层管理者协同处理。

第二个是紧急程度，即问题对时间有多敏感。一个小 bug，如果客户下午 2 点要交报告，照样可能非常紧急。

第三个是你承诺的响应时间。按 Plain 的说法，支持类服务等级协议（SLA）是对客户的一项可衡量的承诺，规定你多快响应、多快解决。这个问题的答案不取决于任何人的感受，它写在合同里。

优先级不是第四个问题，而是前三个问题的结果。它决定你何时开始处理、反应要多快。ITIL 的做法把它概括为 Priority = f(Impact, Urgency)。

## 一个上午，三通电话

回到前面的假设。客户 A 是一家物流公司：报表导出功能对一位分析师失效了，而这份报表下午 2 点要提交董事会。影响小，紧急程度高。

客户 B 是一家零售连锁企业：回答库存问题的 Agent 给所有门店员工报出错误的数字。影响面广，并假设合同承诺 P1 事件 30 分钟内首次响应。

Plain 指出，P1 事件的首次响应目标通常是 15 到 60 分钟，所以这个假设数字处在常见区间内。

客户 C 是一家正在试点的银行，也是战略上最重要的客户。他们反映某个内部看板上的模型延迟略有上升，没有截止时间。影响小，紧急程度低，但名头很大。

下表是一个示例矩阵，用来把两个维度换算成优先级。具体阈值因公司而异，关键是在电话响起之前就把矩阵准备好。

| | 时限紧 | 时限宽 |
|---|---|---|
| **影响面广** | P1 — 客户 B | P2 |
| **影响面窄** | P2 — 客户 A | P3 — 客户 C（考虑升级之前） |

合理的顺序是：先 B，再 A，C 排进日程。但修复的顺序不等于联系的顺序，很多人恰恰在这里失分。

## 先响应，再修复

Plain 把 SLA 拆成两个计时：首次响应和解决。解决时间更难控制，因为有些 bug 需要工程团队介入，所以 Plain 建议为每个优先级分别设定目标。相比之下，首次响应完全掌握在你自己手里。

所以在 8:50，还没打开任何日志，你就发出三条消息。给 B：“已收到，定为 P1，下次更新时间 9:20。”给 A：“明白，你们的截止时间是下午 2 点，11 点前会给出解决方案。”给 C：“已收到，我们今天下午评估，下班前回复。”

**要点:** 先回复每个客户以守住承诺，再按严重程度和时限依次修复。

写这三条消息只要几分钟。换来的是：B 在承诺时限内收到了首次响应，A 知道你理解他们的截止时间，C 虽然暂时没有被处理，但知道自己的问题有人听到了。

对 A 来说，时限紧并不意味着必须马上修复根因。11 点前发过去一份手动导出的 CSV，就能满足他们的真实需求，也就是开会要用的报表。底层 bug 可以明天再修。

## 大客户能插队吗？

incident.io 承认，影响大客户的低严重程度事件，可能值得提高级别。这很合理，你完全可以把客户 C 从 P3 提到 P2。但提级要有一个能写下来的理由，比如试点的评审会快到了，而不是出于害怕。

如果让客户 C 排到客户 B 前面，你调一个内部看板的时候，成千上万的零售员工还在拿到错误的库存数字。事后有人问起，你拿不出任何理由为这个决定辩护。

## 动手试试：前十五分钟的五个步骤

第一步：把每通电话用一句话记下来：影响了谁、多少人、症状是什么。第二步：按受影响的用户数和被阻断的业务流程给严重程度打分，而不是看来电者的语气。

第三步：直接问：“你们最晚什么时候需要结果，为什么？”这个“为什么”往往能引出变通方案。第四步：查每个客户的 SLA，发出首次响应，从承诺时限最短的客户开始。

第五步：把优先级顺序和理由发到团队的共享频道。当经理或客户经理问为什么客户 C 要等时，答案已经摆在那里。

## 常见的陷阱

最常见的陷阱是把严重程度和优先级当成一回事，结果一个时限紧的小 bug 被忘到下午 1:55。第二个陷阱是在电话里承诺解决时间，而你真正能掌控的只有响应时间。

第三个陷阱是修复期间一声不吭。客户看不到你在看日志，只看到一直没有消息。定好下次更新的时间并按时兑现，哪怕没有新进展。

## 把这项能力变成证据

阅读前线部署工程师（FDE）的岗位描述时，留意 on-call、SLA、escalation、同时对接多个客户这类表述。它们说明这个岗位恰恰要求这项能力。面试时，讲一次真实的分诊经历，覆盖影响、时限和承诺三个维度，再说明你做了什么选择、为什么。

在简历上，一句具体的话比“抗压能力强”更有分量。例如：“同时为四个客户进行事件分诊，一个季度内首次响应 SLA 零违约”。只写你能证明的数字。

三通电话的早上还会再来。准备好矩阵和消息模板，前十五分钟就不会那么手忙脚乱。

**本周动手试试:**

- 回顾你最近的 10 个工单，给每个工单的严重程度和紧急程度打分，再和你实际处理的顺序对比。
- 阅读你负责的客户的合同或 SLA，写下每个优先级承诺的首次响应时间。
- 起草一份首次响应消息模板，包含三点：已收到、正在评估、下次更新时间。

## 信源

- [Understanding the differences between severity vs priority in incident management](https://incident.io/blog/differences-between-severity-and-priority)

- [Incident severity vs priority: What's the difference?](https://firehydrant.com/blog/incident-severity-and-priority-101/)

- [Incident Severity Classification: Best Practices to Speed Resolution](https://www.pagerduty.com/resources/incident-management-response/learn/incident-severity-classification/)

- [How to Create Priority Calculation](https://oneuptime.com/blog/post/2026-01-30-priority-calculation/view)

- [Customer Support SLAs for B2B SaaS: How to Set, Measure, and Actually Hit Them (2026)](https://www.plain.com/blog/customer-support-slas-b2b-saas-2026)