FDE Times 数据在招 FDE 职位 838▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 66在招公司 169支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

技能指南 · 指南

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

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

分享微博

要点速览

  • 严重程度衡量损害,优先级决定何时动手。两者不是一回事,不要混为一谈。
  • 首次响应只需几分钟,却能守住 SLA 承诺,所以开始修复前先给每个客户发一条。
  • 时限紧但影响小的问题,往往用变通方案就能交差,根因修复可以往后放。
2×2 矩阵:横轴是时限(紧、宽),纵轴是影响(广、窄)。影响广、时限紧的格子是 P1,即客户 B,以橙色标出,最先修复;影响窄、时限紧的格子是 P2,即客户 A,第二个处理;影响窄、时限宽的格子是 P3,即客户 C,排进日程;剩下一格为 P2,空置。注释:开始任何修复之前,三个客户都先收到首次回复。
优先级由影响和时限两个维度合成。修复顺序是先 B 后 A,C 排进日程,但三个客户事先都会收到首次回复。来源:文中的示例矩阵与假设案例,依据 ITIL、Plain 和 incident.io 的实践。

设想这样一个场景:早上 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 零违约”。只写你能证明的数字。

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

这篇文章对你有帮助吗?

5 个信源
路线图上的下一篇 · 阶段 7: 项目主导埃森哲已经在场,FDE 来做什么?集成商按 SOW 交付;FDE 负责以业务结果衡量的“完成”标准、平台知识和运维交接。