在 Tinybird，我们制定了核心原则，赋予工程师处理问题的能力，并启动了一个论坛，分享 On-Call 流程中的困难以及改进建议。
On-Call 流程对于 SaaS 公司来说是一个敏感的话题。一方面，你必须要有它，因为你的生产服务器似乎总是在周六凌晨 2 点出现故障。另一方面，这给那些必须 On-Call 的人带来了沉重的负担，特别是在像 Tinybird 这样的小公司，我目前负责工程团队。
我在三家不同的公司积极参与了创建 On-Call 流程。其中两家表现得非常出色，而另一家则不然。在这里，我将分享我对于如何成功进行 On-Call 的一些经验。
当我加入 Tinybird 时，我们没有一个 On-Call 系统。我们拥有自动化的警报和良好的监控系统，但没有人负责 On-Call 流程或员工之间的轮换计划。
像我们这样的许多年轻公司都不想创建正式的 On-Call 流程。许多员工理所当然地回避了 On-Call 所带来的压力和个人责任。似乎最好的做法是像一个集体一样处理问题。
但实际上，这只会带来更多的压力。如果没有人负责，每个人都负责。
在没有正式流程的情况下，Tinybird 依赖于积极主动的员工和移动通知来处理一些警报通道。换句话说，这是杂乱无章且令人感到压力的。我们拥有多个警报通道，不断的噪音和许多无法执行的警报。如果这听起来很熟悉，那是因为在大多数公司中，这是典型的情况。
显然，这种处理生产故障的方法无法扩展，并且会导致糟糕的服务和不满的客户。我们知道我们需要一个正式的 On-Call 结构和轮换计划，但我们希望避免给我们相对较小的团队带来过多压力（当时，我们的工程师人数不到 10 人）。
人们并不想要一个 On-Call 流程。他们害怕这次 On-Call 经历会和上次的 On-Call 经历一样，那无疑是糟糕的。在这种恐惧之下，对于尝试解决一个你对其了解甚少的问题时，周围没有人（或没有醒着的人）来帮助，这种不安是明显的。责任的负担沉重得让人难以承受。有时候，你必须要做出一个可能产生重大影响的决定。停机时间可能就是 0 和 1 之间的差异造成的。
我们在 Tinybird 的目标是消除这些恐惧和不安，让人们感到在 On-Call 工程师方面有权利和受到尊重。
在我们讨论具体流程之前，我们为 On-Call 系统概述了一些核心原则，为我们的实施提供了界限和指导。
- On-Call 不是强制性的。 有些人出于各种原因不想或不能 On-Call 。我们尊重这种选择。
- On-Call 得到财务补偿。 如果你 On-Call ，你会因你的时间和精力而得到报酬。
- On-Call 是 24/7 的。 我们提供 24/7 的服务，我们必须有人主动 On-Call 以维护我们的 SLA。
- 减少噪音。 噪音会带来压力。如果警报没有可操作性，这种压力会导致倦怠。警报必须始终是可操作的。
- On-Call 不仅仅适用于SRE（站点可靠性工程师）。 每个工程师都应该有能力参与其中。这促进了所有团队成员之间的拥有权，并增加了每个人对我们的系统的意识和理解。
- 每个警报都应该有一个运行手册。 由于来自任何职能的任何人都可能 On-Call ，所以我们希望确保每个人都知道该怎么做，即使问题与他们的代码或系统无关。
- 减少 On-Call 时间。 我们的目标是每六周只需要人 On-Call 一次。当然，这取决于参与的人数，这可能无法实现，但我们仍然设定了这个目标。
- 备有备份人员。 我们的服务水平协议（SLA）很重要，所以我们总是希望在我们的主要 On-Call 人员由于任何原因都无法联系时备有备份。
- 呼叫某人应该是最后的手段。 除非维护我们的SLA绝对必要，否则不要在工作时间之外打扰某人。此外，每次发生故障时，都应采取措施尽量防止其再次发生。
接下来，我们来看看我们是如何实施 On-Call 流程的。
首先，我们列出了所有现有的警报。我们提出了两个问题：
- 它们是否可以理解？ 我们的任何工程师都应该能够迅速看到警报并理解其性质和严重程度。
- 它们是否可操作？ 无法执行的警报只是噪音。每个警报都应该需要采取行动。这样，当一个 On-Call 警报出现在你的收件箱时，就不会有任何疑问是否需要采取行动。
其次，我们尽可能使警报可以衡量，并且每个警报都指向了 Grafana 中描述异常情况的相应图表。
此外，我们将所有的 On-Call 警报迁移到了一个单一的通道。不再需要在不同的地方寻找警报。我们使用 PagerDuty 来发出警报。
至关重要的是，我们为每个警报创建了一个运行手册，描述了评估和（希望能够）修复潜在问题的步骤。有了运行手册，工程师们感到有能力解决问题，而不必寻找更多的背景信息。
在接下来的大约两个月里，每个星期一，Tinybird 的首席技术官和我都会与平台团队会面，以实现以下目标：
- 如果警报没有可操作性或者是误报，就进行纠正或者消除。
- 如果警报是真实的，就分析它以找到长期解决方案，并为其提供必要的优先级。
我们还开始与整个工程团队一起协作地审查每个事故报告。在实施这个流程之前，我们会创建事故报告（IR），并在内部共享。但我们决定进一步推进这一过程。
现在，每个 IR 都在一个公开的会议上向整个工程团队展示。我们希望每个人都能够理解发生了什么，如何解决以及受到了什么影响。我们利用这个会议来确定可以防止将来发生的行动点，比如改进警报、更改系统、架构变化、消除单点故障等等。这个流程不仅帮助我们减轻了将来可能发生的问题，还帮助增加了整个团队对我们的代码和系统的拥有权和整体知识。了解代码库的人越多，他们在 On-Call 时修复问题的能力就越强。
起初，我们只有三个人 On-Call （两名工程师和首席技术官）。我们知道这对这三个人来说是具有挑战性的，但这也是在将新流程推广到整个团队之前评估我们新流程的一种临时方式。
需要注意的是，我们仍然要求在工作时间内进行 On-Call 。每位工程师都应该在正常班次内轮流进行 On-Call 。这有一些好处：
1. 增加了拥有权： On-Call 让你意识到发布经过监控和易于操作的代码的重要性。如果你知道你要 On-Call 来修复你发布的东西，你会花更多时间确保你知道如何操作你的代码，如何监控它以及如何解析生成的警报。 2. 知识共享和减少摩擦： 在你独自一人时， On-Call 可能会让你感到害怕。但如果在工作时间内 On-Call ，你就不会孤单。对于新手来说，这有助于他们在不焦虑的情况下逐步适应 On-Call 流程。他们学会如何应对常见的警报，也会发现 On-Call 并不像他们想象的那么喧闹和可怕。
每周，当 On-Call 班次更换时，我们会审查上一班次的情况。我们利用这段时间来分享知识和技巧，确定必要的跨团队举措，以便改进整个系统等等。
最后，每当有人在夜间担任主要 On-Call 人员时，我们都会让他们在第二天休息一天。
经过大约一年的新 On-Call 流程实施，我们有九名人员在主要（24/7） On-Call 系统上轮换，而在工作时间内同时有六名人员在 On-Call 。
这效果非常好。虽然我不会说我们的工程师喜欢 On-Call ，但我认为可以公平地说他们有能力处理出现的问题，而且他们知道他们有一个可以分享有关 On-Call 系统困难和改进建议的论坛。
如果您对了解更多关于 Tinybird 和我们的 On-Call 系统的信息感兴趣，我很乐意听到您的意见。此外，如果您受到 Tinybird 的 On-Call 文化的启发，并认为您想与我们合作，可以在这里查看我们的空缺职位。