Scott Smitelli

把这 On-Call Rotation 丢到一边去

发布于 2025年3月27日

本页内容：

每天晚上六点整，熟悉的蓝金开场画面准时出现在屏幕上。 急促的断音弦乐让人联想起模糊的二手记忆，那是电传打字机可能发出的声音。 工作室的地板从高角度观看，中间放着一张巨大的覆有 Lexan 的桌子，然后淡入淡出到本次新闻广播的主持人的双人镜头。 音乐逐渐淡出，每个人都自我介绍，然后他们直接进入当晚的头条新闻。 一直以来都是这样。 他们从未未能将这个节目播出。 他们从未失败过。

你会呼叫谁？

一切都在不断失败。 Werner Vogels

制作任何类型的直播电视节目都是一项复杂的芭蕾舞。 工作室的摄像机和麦克风将其信号传送到视频切换器和音频混音器中，预先录制的节目包来自视频服务器，现场记者通过卫星链路双向连接，并从运动图形机器中撒上一些活力，最终产品发送到主控室，最终发送到整个城市的厨房柜台和家庭房间。

但是，在这种直接管道之外还有辅助系统。 工作室的照明非常重要，因为大多数专业广播摄像机在光线不足的情况下往往会产生令人沮丧的图像。 为主持人提供剧本的提词器显然很重要。 天气报告部分使用完全独立的图形渲染设备系统，该系统必须通过色键器连接，才能将气象学家放置在计算机生成的预报图像前。 并且很明显，这些设备需要少数操作员。

演播室级设备价格极其昂贵，但它们也非常可靠。 东西彻底失效的情况很少见，但经过足够的日常使用后，任何东西最终都会磨损。 如果摄像机出现故障，也许他们可以将体育桌上的那台摄像机推过来以覆盖广播的这一部分。 如果提词器出现故障，主持人会在他们的桌子上放一份剧本的副本，他们可以向下看。 如果其中一位主持人请病假，他们可以从早间新闻团队中选拔人才。

这些都是冗余备份系统或可在需要时重新分配的剩余容量的示例。 从技术上讲，在正常情况下，广播不需要任何这些突发事件才能发挥作用，但是在出现问题的情况下，这可能意味着成功与彻底失败之间的区别。

并非所有事物都可以完全冗余。 灯光电源系统的故障很可能会使整个工作室陷入黑暗，这不是运行新闻节目的方式。 同样，如果价值 50,000 美元的视频切换器死机，他们极不可能在储藏室里藏有备件。 为了确保避免任何可能出错的事情，他们将不得不在城市电网的单独部分上建造第二个工作室，并配备所有设备和广播内容的冗余副本，以及随时准备接管的替补人员。 这是任何注重预算的电视台都无法合理实现的冗余程度。

在两种选择之间存在一种混合模式，允许电视台仅维护任何昂贵设备的单个实例，同时确保他们确实拥有的设备在需要时可以正常工作：他们可以找到某种专家，能够修复任何足以让广播播出的东西。 我们将这个人命名为 Alex。 如果麦克风电池没电了，Alex 会更换它。 如果视频服务器出现问题，Alex 知道如何使其再次工作。 如果雪佛兰气象野兽中的轮胎压力灯亮起，或者工作室的空调出现故障，或者技术总监双手骨折并且需要有人代表他们按下按钮，那么现在就是 Alex 发光的时候了。

现在，很自然地，大多数时候一切都很好，Alex 无事可做。 因此，Alex 在工作室里还有其他一些常规工作，例如运行音频混音器。 实际上，音频混音器是他们的正式职位和他们在电视台的主要职责； 只有在出现问题时，他们才会进入通用问题解决模式。 问题解决后，他们会回到音频混音器。

关于这一切的另一件事是，嗯，很难找到和培训像 Alex 这样的人。 因此，既然他们反正整个晚上都在电视台，为什么不让他们也呆在那里以防 7:00 新闻和 11:00 新闻期间出现任何问题？ 如果凌晨 4:30 至 7 点的新闻期间发生任何事情，电视台可以打电话给 Alex，让他们过来解决问题。 哦，还有中午的新闻和下午 4 点的节目。 显然，该电视台每天播出六个小时的直播新闻节目。 至少星期日只有四个小时。 在电视台看来，没有必要让任何人接替 Alex，因为在大多数情况下，他们根本不需要 Alex 的紧急响应技能。 不应聘用和培训其他人来做这些事情，因为他们几乎不使用他们已经拥有的人的服务。

当然，电视台还有另一种选择，他们从未认真考虑过：根本不要让 Alex 承担任何这些责任，如果事情真的出了问题，他们可以播放旧的 The Price Is Right 重播，并希望在下一次计划的新闻广播中运气更好。

爷爷，什么是寻呼机？

1-800-759-7243

但是如果你没有那个密码，傻瓜，你就不能打电话给我

要想和 Mix 见面，你必须拨打那个号码

然后坐在电话旁，想知道

他会打电话来吗？ 如果你很好，我可能会

如果你是一只鸭子，晚安

Sir Mix-A-Lot，《Beepers》

曾经有一段时间——真的不是很久以前——如果人们不知道你在哪里，他们就无法联系你。 电话实际上是用螺丝固定在房屋和企业的墙壁上的。 便携式双向无线电确实存在，但是携带和操作它们非常麻烦。 如果有人希望与你联系，他们不会专门打电话给你，而是打电话给 你的房子 或 你的工作场所，你当时可能或可能不在的地方。 如果你不在那里，也许他们会尝试打电话给你兄弟的房子、你最喜欢的酒吧、基瓦尼斯俱乐部或对你来说有意义的另一个地点。 如果他们仍然找不到你，最终他们会放弃。 过去的人们在这方面更放松。

在更有结构的环境中——例如医生在房间之间移动但留在同一栋建筑物内的医院——重要的是能够在不知道他们在哪个房间的情况下联系到特定的人。 为了完成此任务，电话接线员会通过建筑物公共广播扬声器上的公告寻呼所需的人员：“正在寻呼 Johnson 医生，Johnson 医生，请致电四楼护士站。” 假设 Johnson 医生在建筑物内听到此消息，他们会找到电话并按照指示致电站点。 “寻呼”一词的动词形式与名词“page”的意思相同，“page”是一个古老的词，大致意思是“侍应生”。 我寻呼你，就像我要求 Kenneth，NBC 页面来自 30 Rock 来给你发消息一样。

这种方式效果很好，但是它产生了许多“无用”的噪音，因为大多数员工都未参与他们听到的寻呼。 感谢技术的逐步改进，语音公告逐渐被单向无线电广播所取代，该广播覆盖了整个建筑物。 无线电消息的内容与语音公告相同：寻呼对象是谁，以及该人需要联系谁来响应。 每个需要接收寻呼的人都获得了一个寻呼机，这是一个无线电接收器，经过预编程，仅响应专门针对它的寻呼而激活。 每个寻呼机都包含一个小型数字显示器，可以在其中显示有关要呼叫谁的信息。 这些通常被称为 beepers，因为，嗯，它们会发出哔哔声来宣布每个传入的寻呼。

要发送寻呼，一个人会拿起建筑物中的电话之一并拨打寻呼系统的号码。 系统会提示他们输入收件人的 PIN 或唯一标识码以及回拨号码。 如果发送者希望收件人直接回电，则回拨号码将是发送者准备接听的电话。 不过，不必如此。 例如，发送者和收件人可以拥有一个预先安排的系统，其中像“505”这样的代码可以解释为求救信号 SOS，并具有某种相互理解的含义。 这些代码在收件人熟悉的发送者中更为常见，代表着他们经常需要交换的消息。 对于建筑物维护人员来说，“234”可能表示枫树大道 234 号发生紧急情况，而“5300”可能表示榆树街 5300 号。 这些代码的含义取决于发送者和收件人同意的含义。

技术变得更好了。 东西变得更小更快了。 单向寻呼机网络开始被移动电话网络所掩盖，移动电话网络很快获得了发送双向 SMS 消息的能力。 微处理器的发展达到了这样的程度，即电池供电的手持设备可以充当电话，还可以发送和接收文本消息。 这些进步使得可以使用更具表现力的字符集在也可以做其他事情的设备上发送更长的消息。 我的第一部手机可以运行客观上很烂的贪吃蛇游戏。 但是功能已经具备。 电话不断获得功能，电话运行的网络不断变得更快且覆盖范围更广，但是“我需要将 此 消息发送到 该 设备”的核心线程与 Sir Mix-A-Lot 在 20 世纪 80 年代向他的女朋友求爱时一样清晰。

此外，到目前为止描述的系统有一个共同点：发送寻呼的人是人。

达成共识

老兄： 他们给了老兄一个寻呼机，所以每当这些人打电话来时...

沃尔特： 如果是在比赛期间怎么办？

老兄： 哦，我告诉他们如果在联赛比赛期间...

多尼： 什么是联赛比赛期间？

沃尔特： 生活不会在你方便的时候停止和开始，你这个可怜的混蛋。

The Big Lebowski (1998)

就像技术行业中令人沮丧的许多事情一样，关于 on-call 职责是什么样子，没有真正的标准。 每个组织，甚至是每个团队内部！ 都可以自由地以适合自己口味的任何方式进行设置，因此最终的实践差异很大。 为了使本文立足于具体内容，我将描述 Alex 的 on-call 安排，这对于商业模式是“拥有网站和/或移动应用程序，并且要么在上面放置广告，要么说服用户输入他们的信用卡信息以使用它”的美国公司来说似乎很典型。 这些组织普遍认为，产品必须始终有效，否则会导致无法展示广告或收取付款。 这两者都会对收入产生负面影响。

Alex 的公司使用 SEV 系统，该系统可能再次，没有标准。 有人从 Amazon 或 Facebook 或其他地方复制了部分理念，但从未费心对该缩写对他们的意义进行确切的编纂。 意思是“sev erity”、“s ite ev ent”、“s ignificant ev ent”、“s erious ev ent”或您可以想出的任何其他符合该模式的东西。 SEV 根据其对产品体验的影响进一步分为编号的类别； SEV 1 意味着该业务当前无法成为业务，因为它无法执行其核心功能和/或收取其收入。 较低的 SEV 3 可能表示应用程序某些非关键部分的性能下降。 SEV 3 的一个例子可能是用户仍然可以更改他们的个人资料图片的情况，但是由于某种处理延迟，这些更改没有及时显示在应用程序中。 这_可能_不会以可衡量的方式影响季度财务报表。 另一方面，SEV 1 的一个例子可能包括移动应用程序在每次向每个用户发出的请求上都显示一个永久的加载微调器。 这种类型的事情往往会引起注意。

在 SEV 系统之下，存在着一些微妙的损坏或即将完全损坏，但在目前可以正常运行的事物的翻滚混乱。 一个很好的例子是磁盘已满 98%。 在其当前状态下，实际上没有任何问题。 但是一旦它最终达到 100% 并且无法接受任何更多的数据，系统中的其他东西就会做出不良响应，并且这很可能会级联为某种 SEV。 大多数组织中的大多数系统都具有针对此类事情的监控功能，并且 on-call 工程师通常会收到由于（例如）高磁盘使用率而发出的寻呼，以进行专门调查以避免将来可能出现的 SEV。 实际上，所有此类寻呼都是通过自动方式生成和发送的，并且如果（例如）磁盘使用率自然消退，则这些寻呼有时无需外部干预即可自行解决。

Alex 部门中的 on-call 工程师是从所有团队成员的 rotation 中选出的。 On-call shift 是连续七天 24 小时的支持，或 168 个整点小时。 ±1 小时，具体取决于夏令时的变化。 On-call 工程师不需要连续七天保持清醒； 他们的想法是，他们应该在工作时间内处理典型的任务，并像往常一样进行非工作生活，但是能够在收到任何寻呼后随时快速处理问题。“快速”部分正式定义为确认时间，持续时间从 5 分钟到 30 分钟相当典型。 Alex 的团队希望在 15 分钟内确认寻呼。

如果 on-call 工程师未确认寻呼，则会开始 escalation 系统。 升级策略通常遵循以下模式之一：

在上面描述的每个设置中，团队的经理可能会或可能不会成为升级链的一部分。 如果他们是，则会为 on-call 计算增加一个全新的层次：没有人希望他们未确认的寻呼最终通知他们的经理，尤其是在工作时间之外。 Alex 的团队使用“单个 on-call 工程师”模型，并升级到经理。

On-call shift 每 N 周发生一周，其中 N 是团队中的人数。 对于主/次安排，shift 频率为每 N 周 两 周，即使其中一周理想情况下只会看到很少或零个寻呼。 尽管如此，次工程师必须在此期间保持完全可用。 如果一个团队有 15 个人，那么每个人几乎不需要每季度覆盖一个 shift。 在两人团队中，每个人都是 on-call_每隔一周。_ 这是可变性的一个重要来源，并且会随着团队成员休假、请事假或与团队或公司分道扬镳而突然改变。 Alex 在一个有四个人的部门工作，导致大约每月一次 on-call shift。

有时生活会干扰 on-call 安排，对于那些时候，通常有一种机制可以让团队成员在彼此之间交换部分或完整的 on-call shift。 如果活跃的 on-call 工程师需要几个不间断的时间来参加家庭活动或不可避免的约会，他们可以寻找愿意承担该时间段责任的同事。 在将来的某个日期，当另一个人 on-call 并且需要有人来代替他们时，可以报答这个恩情。

当工程师收到寻呼并且需要做出计划外的工作以响应时，该工作称为 on-call load。 每个组织都期望每个 shift 有一定数量的 on-call load。 或者，他们_应该_这样做，但是发现有些地方从未认真考虑过这个想法也就不足为奇了。 如果发生过多的问题并且 load 超出 shift 的预期，则会变成 on-call pain。 事实。 我为什么要捏造呢？ 在正常工作时间之外发生的寻呼被认为比在工作日发生的寻呼更痛苦。

至于 on-call 工程师在 incident response 期间需要做什么——从确认寻呼到解决导致寻呼的问题的时间——这是另一个差异巨大的领域。 有时他们需要登录到某个 Web UI 并单击一个按钮。 有时他们会连续十个小时尝试抢救完全无法访问的产品。 一个团队可能会因为运气好而在一个星期到另一个星期经历 load 谱的两个极端。

有时，on-call 工程师将面临一个客观上无法修复的情况。 有时AWS 的整个 us-east-1 区域的一个关键部分会发生故障，最终会削弱大部分互联网以及它。 有时，在桑迪飓风用海水淹没其燃油泵后，33 Whitehall 失去发电机电源。 Alex 的公司非常努力地削减运营成本，方法是将过多的核心功能外包给客户支持周转时间差的第三方，然后他们的中断成为 Alex 的中断。 在这种情况下，有时 on-call 工程师只需要举手投降。 除了简单地等待问题过去之外，唯一可行的选择是进行一些雄心勃勃的迁移到完全不同的提供商。 这不是任何人都可以合理地在任何时间范围内完成的事情，并且在服务中断的压力下这样做充其量是不明智的。 在某个时候，Alex 能做的最好的事情就是打开 The Price Is Right 并等待事情过去。

现在，很明显，on-call 职责绝不是技术行业特有的工作要求。 医生和外科医生可以 on-call。 公寓大楼的建筑主管可以 on-call。 修理空调的人可以 on-call。 不同之处在于，这些行业的人们因这样做而获得公平的报酬。

等等，你们有工资拿？

工作工作工作，日复一日

每周 50 小时，支付 40 小时的工资

没有时间克服所有这些加班

是的，我总是在奔跑，但我总是落后

Tracy Lawrence，《Runnin' Behind》

在美国，有很多方法可以简单地看待员工工资。 员工按每小时 $X 的费率雇用，他们每周工作 Y 小时，总工资是这两个数字的乘积。 在联邦级别甚至州级别存在最低工资，该工资规定了 $X 的最小合法金额。 员工应该每周最多工作 Y 小时，即 40 小时，否则他们将进入 overtime 状态，其中他们的每小时 $X 变为 $X 的 1.5 倍。 那些自命不凡的白领工人基本上都是一样的，只是他们的 Y 固定为 40 小时，而不管实际工作时间如何，因此他们的总工资每周都保持不变。 这就是它的运作方式，对吗？

这是 1938 年公平劳动标准法案 (FLSA) 及其许多修正案中规定的系统。 这是支撑最低工资、加班、每周工作 40 小时以及童工可能不是一件好事等概念的法律。 它还定义了一组规则 exemptions，从而创建了 exempt employee 的概念。 如果你是美国的全职技术工作者，那么我会在黑暗中尝试一下，并假设你几乎肯定被归类为免税员工。 这意味着 FLSA 的保护 实际上对你不存在。 你不能保证加班费，并且你可能会在一个星期内工作如此多的时间，以至于你的实际时薪最终低于最低工资。 现在我想知道雇主是否可以通过将他们归类为免税员工来逃避雇用童工。 我猜不会，否则外面会有人在做这件事。

FLSA 旨在考虑重复且可预测的工作：在装配线上工作的人、在仓库中搬运箱子的人、司机和快递员等等。 这些类型的工作人员倾向于在任何给定的时间内产生相似且可预测的工作量。 在工作日的某个小时拜访他们，你会观察到他们与在任何其他小时所发现的生产力水平大致相同。

免于 FLSA 约束的员工的工作日往往具有可变性。 最初的想法是，这适用于高管和高技能的专业人员，他们全天执行的任务范围如此广泛，以至于某些小时的价值明显高于其他小时。 这些观点发生了变化，最终演变为“支付高薪的白领工作”。 目前的法规在其免税领域列表中专门列出了与计算机相关的职业。 从某种角度来看，如果你真的眯起眼睛看，这是有道理的！ 想想你编写了数百行代码的时间，然后将其与你坐在会议室里盯着闪烁的文本插入光标而不是注意演示者的时间进行比较。 有时，你可能在一整个工作日中都不会对一个棘手的挑战取得任何进展，这可能会被你稍后在晚上洗碗时产生的单个创造性灵感所完全抵消。

总而言之，美国的法规中没有任何内容可以保护 Alex 免于每周工作超过 40 小时。 没有要求向他们支付加班费。 如果工作需要每周超过 40 个小时，哦，好吧，Alex 倒霉了。 这意味着从技术上讲，Alex 可以通过应用相同的逻辑来减少工作时间，前提是他们完成了所有必要的工作。 他们一直想鼓起勇气有一天尝试一下。

所以。 有了这些背景知识，很明显，只要将责任分配给免税员工，雇主就没有法律或法规要求为执行 on-call 职责支付任何费用。 根据我自己的经验和对业内其他人士的非正式调查，普遍的看法是，on-call 是工作描述的一部分，并且“包含”在总薪酬中。 发现 on-call shift 未收到额外付款或对携带寻呼机没有任何考虑的情况并不少见。 通常也没有为响应在正常工作时间之外发生的寻呼而支付的额外费用。

再次，没有关于此的绝对规则。 有些地方实际上确实为每个 on-call shift 支付适度的荣誉奖金。 有些地方会提供“非官方的”补偿时间 如果你的雇主给予补偿时间，给你一个小问题：当他们休假时，他们_也会_减少他们期望你完成的 sprint 故事点吗？ 以平衡在典型工作时间之外处理的寻呼。 传说中有些组织人员配备充足，系统根本不会寻呼。 想象一下一个神奇的地方，一个人每年只需 on-call 大约三周，并且在那些时间里永远不会收到寻呼。 Alex 曾经整个夏天每隔一周 on-call，偶尔会在一天之内接到十几个寻呼，他无法做到。

大多数地方甚至不会提供电话或补贴移动运营商账单，也不会提供公司支付的移动热点用于笔记本电脑共享。 人们只是假设你会很高兴地在个人设备的主屏幕上安装 PagerDuty 或 Opsgenie 或其他一些违反你个人设备神圣性的可恶应用程序，就在 Okta Verify 旁边。 简短的题外话：Fxxk Okta Verify。 你的个人电话变成了你的寻呼机，这个东西将你从休闲时间拉回到工作时间。 过了一段时间，你可能会开始注意到 on-call 开始从根本上改变你与设备的关系。

最大的可变性来源来自一个团队改善 on-call 情况的意愿，而不是简单地接受事情就是这样。 一些团队将每个寻呼——无论多么微不足道——都视为一个信号，表明需要立即修复某些东西以防止该特定事情_再次_发生。 其他团队则将其视为支持产品自然而然发生的事情，就像每个人都已经习惯了几年的烟雾探测器电池发出哔哔声一样。 它是已经沸腾了多年的技术债务的体现，正在寻找一个减压阀来逃脱，并且它只是碰巧通过 Alex 的寻呼机找到了释放。

也许不足为奇的是，最愿意防御重复寻呼的团队也最有可能执行深入的事后分析，以便他们可以编写和维护他们的 on-call 运行手册。 有时运行手册是 on-call 工程师的唯一朋友，没有什么比发现这个朋友无法帮助修复任何东西更令人失望的了。

漫长、寒冷、孤独的168小时

我整天只想做的就是呆在床上

但这对身体有害，对我的头脑更糟

所以我会试着找一个没有人会问我任何问题的地方

它会帮助我忘记，帮助我唱歌

Reel Big Fish，《Drunk Again》

可以想象，寻呼可以在任何时间（白天或黑夜）到来。 Alex 需要在 15 分钟内收到警报并开始处理问题，这意味着他们必须在该时间承诺内拥有合适的办公电脑和足够的互联网连接。 他们必须了解手机的信号质量和附近 Wi-Fi 网络的可用性。 除非他们随身携带笨重的工作笔记本电脑， 顺便说一句，并非每个人都生活在完美的田园诗般的地区。 有很多地方停在停车上的汽车上的电脑会被盗，包会被抢走。 在某些情况下，携带这些东西对人们来说是一种_真正的风险_。 否则不可能前往任何需要超过几分钟才能返回的地方。

甚至某些家务——例如割草——都需要特别考虑。 如果在此活动期间收到寻呼，Alex 需要在一定程度上将割草机收起来 在某些地区，如上所述，无人看管的割草机可能会被盗。 在其他地区，这可能会导致 HOA 罚款。 然后才能进入室内进行清理，以便进行知识工作。 从家庭劳动跳到复杂的问题解决在精神上是令人疲惫的，并且在问题最终解决后再次返回同样困难。

事实证明，生活中有很多事情在技术上与 on-call shift 兼容，但是需要如此精心的计划和预见，以至于有时最终更容易在 on-call 期间根本不做任何这些事情。 没有重要的旅行或长途步行/驾驶，没有过度饮酒或 咳 ，无法简单地拔掉电源并减压。 即使从未收到实际寻呼，也始终存在收到寻呼的 可能性。 也许主要 on-call 在没有告诉任何人的情况下关掉了手机，去参加 Oppenheimer 的放映。 确实发生了。 也许有时间快速去杂货店来回跑一趟，但可能时间不够。 也许最好等到本周末再呆在家里。 停在电视前，把时间耗完。 但是不要看任何太吸引人的东西； 在精彩的部分收到寻呼真的太糟糕了。

这种情况最终会发生，即使在预期 on-call load 接近零的组织中也是如此。 在随时准备处理任何寻呼的同时，不可能完全正常地生活。 将这种经历与被软禁的经历进行比较可能有些夸张，但这与我们很多人将经历的那种自由但又受到限制的程度最为接近。

而且，当然，当寻呼确实到来时，它会设法找到最不合时宜的时间来这样做。 Alex 在美好的晚餐中、在现场娱乐活动中以及在应该专门用于与家人和朋友相处的时间中被寻呼。 更不用说警报声和手机锁屏上的通知框了。 Alex 的手机成为了怨恨和负面情绪的来源，以至于他们基本上不得不禁用几乎所有其他声音和所有其他通知，因为每次弹出通知时他们的心都会跳动。 Alex 不会说这会导致 PTSD，但它确实导致了相当数量的 PTSD_症状_。

此外，它经常破坏我的睡眠。 哎呀，我指的是 Alex 的睡眠。 我不是 Alex。 不是。

有时寻呼决定在夜间进行。 这是半夜发生寻呼时发生的事情：首先，如果你碰巧有重要的另一半，警报声总是会在你醒来之前唤醒他们。 你起床了。 天很黑。 天很冷。 你打开你的工作笔记本电脑。 即使在最低亮度设置下，16 英寸 Liquid Retina XDR 显示屏也会以其刺眼的强度照亮房间。 你登录你的电子邮件和 Slack，打开一些仪表板，在你的手机上打开 Okta Verify，Fxxk Okta Verify。 你基本上完成了你在正常工作日早上 9 点通常所做的一切。 在你应该到这里上班前六个小时，你就在这里了。 仍然半睡半醒——如果打算在这件事结束后尝试上床睡觉，那就没有理由喝咖啡因了——在这种状态下，在生产系统上摸索不熟悉且着火的代码真的不是正确的头脑。 并且由于现在是半夜，没有人在这里帮助诊断或仔细检查任何东西。 如果你能够注意到它，这里会有一种明显的孤独感。 也许你会手动寻呼其他人来帮助。 或者也许你无法忍受成为那个负责将这种 on-call 痛苦传播到他们身上的人。

最终，问题以某种方式得到解决。 你关闭笔记本电脑，试图悄悄地回到床上。 你的重要另一半（如果适用）再次被此唤醒。 你最终躺在那里一段时间，由于脑力劳动、电脑屏幕的光线和相当多的剩余肾上腺素而无法入睡。 不妨保持清醒； 问题可能实际上没有解决，并且可能会在几分钟后再次寻呼。

嘿，你知道这听起来像什么吗？ 焦虑！ On-call 基本上会导致焦虑。 如果你是一个因为某些其他先前存在的原因_已经患有_焦虑症的人，恭喜你！ 现在你有额外的焦虑症了。 这是为了什么？ 因为一些 Kafka 代理停止运行了吗？

我们需要谈谈 Kafka

我认为，由于 Kafka 是一个针对写作优化的系统，因此使用作者的名字是有道理的。 我在大学里上过很多文学课，并且喜欢 Franz Kafka。 此外，这个名字听起来很酷，适合开源项目。

Jay Kreps，《Kafka：权威指南》，第二版

Jay Kreps 在 LinkedIn 工作时，为最终成为 Apache Kafka 的技术做出了贡献。 广义上讲，Kafka 可以被认为是一个消息队列，它从一侧接收数据并将其发送到另一侧一个或多个感兴趣的方。 与典型的队列不同，它还将此消息流持久化到磁盘上，以便可以推迟、批量甚至在将来的某个日期重复传递。 从规模上看，它可能被赋予了处理如此庞大的数据量的任务，以至于系统的运行变成了屁股上的一大痛点。

这种运行困难的部分原因是 Kafka 在多个独立的计算机上运行，这些计算机必须不断地相互协作才能表现为一个更大的系统。 很像《星际迷航》中的 Borg。 但是 Google 已经使用了这个名字。 如果计算机集群中的任何成员断开连接或性能下降，则整个组的性能和稳定性都会受到影响。 如果一个组织在生产环境中运行 Kafka，则很有可能由于磁盘空间不足、处理滞后或其他难以理解的小精灵而定期寻呼某人。

正如上面的 Kreps 引用中所提到的，Kafka 想要写入磁盘的大量数据是导致其名称的原因。 Apache Kafka 写入很多，就像作者 Franz Kafka 一样。 肯定没有理由对此进行进一步的思考。

Franz Kafka 创造了一个文学世界，在这个世界里，令人难以忍受的荒谬事情发生得似乎没有任何理由，人们期望简单地忍受它们，就好像没有任何不寻常的事情发生一样。 他的环境只_部分_有意义，产生了任何试图理解的官僚机构。 他故事中的主角感到疏远和孤立。 一种令人作呕的焦虑暗流，有时甚至是彻底的恐惧贯穿了他的整个作品。 这位作者可能患有神经病，他摧毁了他所写的大约 90% 的东西，然后在他可能应该这样做之前就死了——留下了一些未完成的实质性作品。 在这方面，Apache Kafka 有一些相似之处。

_这_就是你证明项目名称的方式。 说“我在大学里上了一些文学课，我以为我记得我喜欢它们”只是智力上的懒惰。

重要的无意义的事情/有意义的不重要的事情

Jesse： 听着，我喜欢制作樱桃产品，但是让我们保持真实，好吗？ 我们为不在乎的人制造毒药。 我们可能拥有世界上最不挑剔的客户。

《绝命毒师》，《苍蝇》（第 3 季第 10 集）

我将提出一个听起来似乎不可思议的问题：这重要吗？

我的问题是真诚的。 此服务或产品是否满足了如此关键的需求，以至于有合理的理由始终让一个或多个人员为其 on-call？ 或者我个人最喜欢的，通常由工程师试图将彼此拉回螃蟹桶中，大概是这样的：“你不认为你应该对你投入生产环境中的自己的代码负责吗？” 当然，对此的正确回答是“什么 我的 代码？ 我们是一个团队； 这是