让值班不再糟糕

值班系统失效

解决方案

回报

值班不应该糟糕

以前我们团队规模还小的时候，我们安排了单次 on-call 轮岗。每个开发人员都参与轮岗，每次 on-call 一周。刚开始轮岗的时候，我们团队只有 5 名开发人员。一年又一年过去了，尽管团队规模不断扩大，我们仍然坚持单次 on-call 轮岗。最终，团队规模变得非常大，人们每 3-4 个月 on-call 一次。这听起来像是梦想成真，但实际上，远非如此。

值班系统失效

由于各种原因，单一的轮班值班对每个人来说都是痛苦的。

大旋转

大规模的轮换意味着值班时间非常少，开发人员无法获得有效处理值班问题所需的经验和代表。此外，我们的代码库规模巨大，同时开发的项目太多，以至于当问题出现时，值班开发人员很可能对问题本身或导致问题的代码一无所知。

这导致惊慌失措的开发人员经常向站点可靠性工程(SRE) 团队寻求帮助。频繁地介入并帮助解决待命问题很快开始耗费 SRE 团队大量的时间和资源。实际上，该团队开始表现得像是全天候待命一样。持续不断的问题和请求几乎让整个团队精疲力竭，并占用了他们处理自身项目所需的宝贵时间。

无所有权

除了 SRE 团队精疲力竭、效率低下之外，开发人员对 on-call 的另一个抱怨是，他们感觉自己对所支持的代码缺乏归属感。一个人负责编写代码，如果代码出错，另一个人负责调试。由于应用程序规模过大，任何人都不可能对生产代码有归属感，因为代码量实在太大，而他们又需要支持所有代码。

三个团队，一个申请

由于我们工程部门的规模，我们现在有3个独立的开发团队。每个团队有5-7名开发人员和一名经理。每个团队也有自己的项目。然而，我们的主要应用程序仍然是一个单一的单体Rails应用程序。这三个团队在整个代码库上平等地工作。与其他应用程序的后端组件由各个团队各自负责不同功能的应用程序不同，我们并没有清晰或明显的所有权界限。解决这个问题将成为修复我们的on-call系统时最困难的任务。

解决方案

3次旋转

我们知道，如果想要继续发展，就必须打破轮岗制度，但问题是如何打破？尽管所有开发人员都在同一个应用程序上工作，而且没有明确的职责分工，但我们还是制定了一项计划，将原来的轮岗制度拆分成三个轮岗，三个开发团队各负责一个轮岗。这缩短了轮岗时间，也意味着开发人员可以安排更多代表。虽然听起来可能有点落后，但更多地保持 on-call 状态确实有好处，因为开发人员已经习惯了这种制度，并且能够真正找到最适合自己的策略。

分割应用程序所有权

三次轮换让开发人员能够获得更多的 on-call 代表，但这仍然存在最大的问题，那就是所有权问题。没有人愿意支持他们感觉不属于自己的项目。为了实现这一点，我们选择将 on-call 应用程序的所有权分配给三个开发团队。这并非一朝一夕就能实现的，但经过几次会议和大量的团队讨论，我们最终将应用程序中的所有内容分配给了三个团队。

• 我们分解了所有后台工作者，例如：
  • 团队 1：索引作业
  • 团队 2：夜班报道工作
  • 团队 3：客户沟通工作
• 我们将所有单独的服务警报分开，例如：
  • 团队 1：Redis 警报、队列备份警报
  • 团队 2：Elasticsearch 警报、API 流量警报
  • 团队 3：MySQL 警报、用户加载页面警报
• 我们分解了应用程序组件，例如：
  • 团队 1：用户和警报模型和控制器
  • 团队 2：资产和漏洞模型及控制器
  • 团队 3：报告和电子邮件模型和控制器

划定界限后，我们向每个开发团队强调，尽管我们尽力平衡代码，但仍可能需要进行一些调整。这向开发人员表明，我们全力投入，确保新的 on-call 轮岗制度公平公正，对每个人都更有利。

代码拆分后，SRE 团队花时间与每个开发团队坐下来，彻底审查他们现在负责的应用组件、工作器和警报。我们仔细讨论了所有内容，从常见问题到每段代码的具体功能及其对应用程序其他部分的影响。这些会议让开发人员对自己处理 on-call 情况的能力更有信心，因为他们现在对自己负责的内容以及处理方式有了清晰的了解。即使他们没有亲自编写过某些代码，但他们也清楚地了解了这些代码的工作原理和功能。

除了为每个团队提供各自代码部分的培训外，我们还利用了Gitlab 的 CODEOWNERS文件。CODEOWNERS 文件允许您指定组织中哪些团队或哪些人拥有某个文件。当 PR 中的任何人更新该文件时，该文件的所有者都会自动被标记为需要审核。

合理的后备方案

最初，SRE 团队是值班开发人员的后备团队。如果值班开发人员有问题或需要帮助，他们会联系当周值班的 SRE 团队成员。我们的 SRE 团队目前只有 3 名成员，所以你可以理解为什么我们总是因为需要后备而精疲力竭。在新系统下，3 名值班开发人员互相充当后备团队。如果他们中的任何一个人不知所措或被问题卡住，我们鼓励他们联系其他值班开发人员寻求帮助。

更加专注

除了上述变更之外，我们还取消了值班开发人员的一些职责。在这些值班轮岗变更之前，值班开发人员负责确定在事件发生时是否需要状态页面或任何客户消息。现在，我们已将这项职责移交给支持团队。支持团队距离客户最近，因此最有能力沟通任何问题。当发生影响客户的事件时，支持团队会收到通知，并负责确定是否需要状态页面或任何客户沟通。将此职责交给支持团队，使开发人员能够专注于诊断和解决当前问题。

回报

改进警报

最初，SRE 团队已经设置了所有警报和监控工具。然而，当我们将警报移交给各个开发团队后，他们就照做了。由于每个团队都对自己的警报有了新的归属感，他们开始改进和构建警报。他们不仅发出了更多警报，还提高了现有警报的准确性。

主人翁意识

即使一个团队可能会编辑另一个团队支持的代码，支持团队仍然会保持强烈的主人翁意识。支持团队几乎是其所在代码段的领域专家。使用 CODEOWNERS 文件可以确保支持团队知晓并签署其他团队所做的任何更改。由于一个团队支持的每个代码段都很小，因此他们实际上可以学习和支持所有代码段，而不像以前那样，代码量太大，任何人都无法处理。

更快的事件响应

由于有 3 名开发人员同时值班，并且每人专注于应用程序的一小部分，他们可以更快地发现问题。每个团队都希望确保在出现问题时能够迅速发现，因此许多团队选择调整警报，以便比最初设置的速度更快地发出问题警报。

问题分类和根源查找也快了很多。团队对警报和自身代码非常熟悉，这使得他们能够比以前更快地解决问题。

永不孤单

同时有三位开发人员待命，意味着他们不会感到孤单。如果应用程序的某个部分出现问题，负责该部分的开发人员知道还有另外两位开发人员可以提供帮助。知道身边有其他人随时待命，就能极大地提升你的自信心。

改善跨团队沟通

正如我之前所说，三个开发团队各自负责整个应用程序的开发。这意味着有时一个团队编写的代码可能会导致另一个团队收到警报。

例如，假设一个高负载的 Redis 警报响起。这并不保证负责该警报的团队也负责导致问题的应用程序部分。但是，由于 Redis 警报团队对此类警报经验丰富，他们知道如何快速有效地进行分类。然后，分类团队可以轻松地将问题组件移交给负责该组件的团队。这种跨团队沟通有助于各团队了解彼此的工作进度，但他们不会觉得需要修复其他团队的代码。

值班不应该糟糕

值班是这个行业很多人害怕的事情，但事实不应该如此。如果人们害怕值班，那你的系统肯定出了问题。当然，每个人有时都会收到那种深夜或周末的电话，这很烦人，但这种烦人不应该成为常态。如果值班让人一直抓狂，你就必须找出问题所在并解决它。