告别值班：关于 On-Call 的反思
告别值班：关于 On-Call 的反思
2025年3月11日 · 1839 字 · 9 分钟
领导力 软件工程 客户支持 On-Call AI
作者
Alexey Karandashev
我帮助公司更好地构建软件。
目录
目录
2025年3月14日编辑：扩展了“AI”部分
Introduction#
本文探讨了大型科技公司中目前 On-Call 的缺陷，或者说是如何正确地开发软件。 令人惊讶的是，根据我的经验，小型公司在这方面做得很好，而大型企业往往会倾向于采取一种手把手的解决方案。
tl;dr#
Pintrest 上的一个守望塔
在我的兵役期间，我最不喜欢的事情之一就是站岗。坐在塔里，俯瞰着空旷的田野，被打喷嚏的奶牛从无意的瞌睡中惊醒。
我不喜欢它，我的任何一个同伴也不喜欢。然而，我们都认为这是一项必要的任务。我们是第一个在发生入侵时向我们的朋友和同事发出警报的人——这是一项至关重要的责任。
我完成了兵役，加入了商业 IT 行业。我真的相信我已经把紧急响应的义务抛在了身后。但是，出乎我的意料，我遇到了一大堆被称为 On-Call 的任务，它们伪装成极其重要的职责——通常是为了在技术或软件服务崩溃时让客户放心而设立的。
这种 On-Call 以不同的方式表现出来：一个 pager 应用、一个 ticketing 系统和电子邮件。
Startups#
在我工作过的一家初创公司里，On-Call 是在工作时间内进行的。被指派的人会回答客户的问题，跟进之前与客户的对话，并在必要时在内部提交一个 bug。我认为，这项职责的产生是由于初创公司资源有限以及糟糕的管理判断，这确实影响了工程师的士气。然而，在任何时候，它都不是关于手把手地“照顾”软件：请求客户重启服务或远程执行此操作——真正的云计算。
你试过了吗？ via The IT Crowd©
你可能会认为，大型领先的科技公司会拥有资源来一次性地解决或避免这个问题。然而，他们选择扩大 On-Call 的范围，使其常态化，并将其根植于公司内外软件工程文化之中。
FAANG, MAANG, SCHMANG#
My experience#
如果我可以用一个词来定义我在大型科技公司的工作经验，我会选择“摩擦”这个词。提交一个新的功能实现需要详尽的文档，这是理所当然的，接下来是一场政治活动，说服主要的工程师和经理们接受这个新功能。这些利益相关者有他们自己的动机和原则——这些动机和原则不一定总是与解决问题的真正工程精神或满足客户的需求相一致。
同样的摩擦也适用于修复 bug 或有缺陷的流程。我会重现 bug：启动整个环境、适当的二进制工件和应用程序的重现状态，创建测试用例并为利益相关者准确地指出问题，并提出可能的解决方案。我会参加十几次会议，来回讨论我的想法，直到收到可怕的判决——完全拒绝修复这个 bug。
对于一个有缺陷的流程，通常会从编写文档开始，与一小部分开发人员及其经理达成协议，然后是其余工程师的完全无视或拒绝这个新流程。在某些情况下，我不得不求助于在 Jenkins 中开发一个脚本来阻止某些不符合协议的变更请求，并引用和链接到该协议——我想这是一种不同的逆向工作方式。但即便如此，一些团队也会利用政治手段来解锁他们的变更请求，而代价是整个组织及其代码库的进步。
让代码比你发现它时更好。 Photo by William ‘Bud’ Hardy / Neuse News
The promotion incentive#
我认为大型科技公司中的 On-Call 是激励机制的产物。这些激励机制不包括：
- 及时维护和改进项目。
- 培养一种持续所有权的文化。
在大型科技公司工作时，趋势是人们加入一个项目一年，引入新功能或改进的设计，（一半）完成它，然后跳到下一个项目。但在初创公司里却不是这样：我多年前用 Java 编写的代码仍然会困扰着我，即使我正在承担作为 C++ 开发人员的新职责。幸运的是，我编写的软件是健壮的，而且这种情况很少发生。
在大型科技公司里，没有编写没有 bug 的软件的激励措施。这听起来牵强而傲慢，但这是可能的。我编写的大部分软件基本上不需要任何干预或修复，除非需求发生了变化。这是有代价的，一种 童子军心态（或顺路修复）和一种积极主动的方法是必要的。从长远来看，这种方法会带来红利。
让代码比你发现它时更好。#
在处理一个变更时，我会记下将来需要改进的部分。通过这种方法，在很多情况下，我在客户和我的同事之前发现了 bug 和漏洞。我将在另一篇文章中更详细地介绍我开发健壮软件的程序。
The management’s silver bullet#
让我们从更大的角度来看，软件工程师们遵循的命令是从哪里来的呢？在我在各种初创公司的职业生涯中，员工和领导之间没有等级制度。我们实际上是与技术主管和 CTO 一起工作的。目标非常明显，让客户和我们开发人员的生活尽可能简单。我会努力编写能让自己变得多余的代码，第二天，一个新员工就可以接替我的位置，并以最小的努力从同一个正在进行的 commit 继续工作。这些小公司里的管理层的激励措施也是一致的，激励开发人员交付完全成熟的代码。
在大型科技公司里，我感觉情况有所不同。绝望的经理们被大量的问题/功能请求压垮，此外还有员工的社会问题：倦怠、家庭和健康问题，以及晋升请求。一些经理将来自高层管理人员的压力传递给员工，使情况变得更糟。更好的经理充当缓冲，一道屏障，在团队的能力已满时进行反击，并在必要时将团队成员重新分配到不同的项目。
大型科技公司中好的和坏的经理都屈服于四处救火。大型科技公司的经理的衡量标准是他们及时完成的目标数量以及他们发起的计划数量。交付一个功能比解决项目中的技术问题更有价值，因为它是可以直接衡量的。创建一个 On-Call 流程来手动检查测试套件中的错误比改进项目以使其更可靠更有价值，因为你可以直接衡量每周失败的测试数量。这是可以衡量的，并且可以向高层管理人员展示。
完全成熟。 kingarthurbaking.com©
AI#
我们每天都被承诺 AI 即将到来，我们作为软件工程师的工作已经过时，AI 将为我们编写代码并修复我们所有的技术债务。Google 提到 公司所有新代码的 25% 都是由 AI 生成的，然后由工程师审查并接受（！）。在 Google 的文章中，紧接着这段话之后就是他们想要销售的产品——Gemini。有多少代码低于平均水平的样板代码？这些 Google 工程师在最终生成的代码中进行了多少干预？这些生成的微小代码块对你开发的整个系统有什么影响？幸运的是，你可以自己测试 Gemini。根据我的经验，LLM 用于编码时，可以充当橡皮鸭，或者是我实际阅读我不熟悉的软件文档的强大动力，因为我总是被所谓的智能误导。
但这与 On-Call 有什么关系呢？
AI, what is it actually good for#
LLM 非常擅长翻译，正如最初设想的那样，通过使用注意力机制。现在存在着这些系统的巨大用途：
- 在英语和 SQL 查询之间来回翻译。
- 将日志和错误简化为人类可读的语言。
此外，为了获得更强大的解决方案，你可以使用 embedding models 本身，它们位于 LLM 的核心。这些可以用于搜索相同的堆栈跟踪和/或问题。以下是一个非常简化的解决方案示例，它可以节省你搜索客户报告的相同问题的时间：
(不幸的是，脚注无法应用于图表。你可以在这里找到它们12) 新工单出现 对你的工单/问题/错误报告的标题和内容进行分词和嵌入 将嵌入向量存储在向量数据库¹中 使用相同的模型对其进行分词和嵌入 使用向量距离函数²搜索类似的问题 但这与 On-Call 有什么关系呢？
Implications#
好吧，这些工具可以自动化 On-Call 工程师的日常任务：搜索与客户报告相关的问题、跟踪相关的软件（或硬件）崩溃、验证 On-Call 期间出现的当前问题是否是回归或已知 bug 等等。你甚至可以更进一步，自动化将任务分配给负责的工程师、作者或代码的最近修改者，这些代码可能会导致回归（联系我，我能为你的业务提供解决方案）。
The exception#
我理解在某些情况下，On-Call 是不可避免的，特别是如果你的产品与 SLA 绑定，并且在质量和可用性方面具有非常严格的误差范围。但是，你必须培养一种工程文化，在这种文化中，On-Call 是常态的例外。你的工程师将加入这场战斗，因为它会解放他们的时间（和你的钱）来专注于有意义的任务，并且会使你的客户更快乐。
Contact me#
如果你有兴趣改进公司的工程结构或探索自动化 On-Call 工作流程的选项，我随时为您提供帮助——只需联系我进行咨询。
- 使用 pgvector 或其他内存解决方案，如 Annoy。↩︎
- 许多工单可能与新工单相关。你需要决定截止结果的阈值（距离）。考虑使用 re-ranking 方法，以获得与查询问题相关的最相关的问题。↩︎