Uber的随叫随到工程师通过保持应用程序的全天候可靠性，为全球的乘客和司机提供无缝体验。然而，为了实现这种可靠性，我们需要确保我们的随叫随到团队能够成功。

直到2016年1月，我们的待命工具箱分散在几个系统中，这使得工程师很难快速有效地响应警报。雪上加霜的是我们当时使用的跟踪解决方案的无能- - - - - -电子邮件报告- - - - - -有效地将之前轮班的相关信息传递给当值工程师。我们需要一种解决方案，它可以集中我们的待命工具箱，并为下一个待命工程师提供一个更全面的系统交接状态的图片。

为了构建更好的随叫随到体验，我们的现场可靠性工程(SRE)团队构建了一个多功能的新工具，用于实时事件响应、轮班维护和事后分析，这些都是动态响应随叫随到系统的关键组件。目前，Uber的数百个团队都在使用“随叫随到仪表板”，它包含了注释、运行手册、内置响应动作和标准化的信噪比调查，可以更容易地解释和处理重要警报。该解决方案还通过详细的分析跟踪和可视化度量，使工程师能够更好地理解他们所继承的系统的状态。

在这篇文章中，我们通过概述其旗舰功能来介绍随叫随到仪表盘，并分享Uber的工程团队如何使用这一强大的工具。

一切随叫随到，都在一个屏幕上

在设计我们的新仪表板时，我们希望通过在一个屏幕上显示关于给定班次的所有必要上下文信息来改善随叫随到的工程师的用户体验，并消除在许多工具之间切换的需要。

下面，我们将讨论几个关键特性关于这个仪表板:

• 注释。On-Call Dashboard最有价值的组件之一是注释警报的能力。注释使工程师能够提供警报上下文的书面说明以及随叫随到的工程师所采取的相应操作。注释是警报上下文和所采取的操作的非自动帐户;当持续交付时，它们使未来的随叫随到工程师更容易解决反复出现的警报。
• Runbook。每当相应的警报响起时，查看运行手册可能会很乏味。想象一个完美的世界，在这个世界中，每个警报及其相关的运行手册只需要点击一下!On-Call Dashboard使这成为可能。
• 内置响应动作。为了更有效地处理注释，我们还需要合并内建的响应动作来确认和解析警报。由于所有警报的真实来源都在on - call Dashboard之外，我们必须能够将其状态上的操作代理到各自的服务。一旦有了代理，我们实际上就可以改善这些服务。通过内置响应操作导入服务所有权信息，我们促成了故障服务和修复它们的人员之间更紧密的映射。这确保了负责维护服务的团队将得到通知，而不管可能的所有权转移。

从噪声中分类信号

嘈杂的警报对每个“听到”它们的人来说都是沉重的负担。不可操作或更琐碎的警报会分散注意力，浪费宝贵的工程时间，而这些时间本可以更好地花在其他地方。如果给定的警报事件的模式是“这并不重要”，那么当某些事情确实偏离轨道时，人为错误的可能性就会增加。

由于On-Call Dashboard包含了用于收集关于警报的反馈的注释，我们也利用它来指示噪音。我们需要为所有团队标准化一个单一的标签方案，所以我们提出了一个与注释相关的两个问题的信噪比(SNR)调查，以帮助我们的工程师消除噪音。

在对不同团队进行调查后，我们意识到信噪比不能包含在一个维度中:它需要衡量准确性(例如，服务是否损坏)和可操作性(例如，特定团队权限下的服务损坏了，他们需要修复它)。

然而，如果调查不是强制性的，这些指标就毫无意义。如果我们的客户在标注警报时牢记我们的信噪比调查，随叫随到仪表板团队就可以最好地跟踪我们的监控系统对每个用户的有效性。一旦我们有了这些数据，我们就可以与团队合作，进一步提高他们的信噪比结果。

信噪比调查有助于工程师- - - - - -尤其是经理们- - - - - -跟踪他们随叫随到的轮换情况，并使我们的团队能够建立随叫随到的解决方案，更好地为用户服务。

信噪比警报分类

为了方便随叫随到的工程师进行注释，信噪比警报根据可操作性和准确性分为六类，如下图所示:

毫不奇怪，团队尽可能地将警报定位在绿色区域(可操作和准确的交叉点)，而尽可能少地将警报定位在红色区域(不可操作和未知的准确性，表明严重的警报问题)。我们使用以下三个指标来判断信噪比水平:标注的信噪比百分比、准确的信噪比百分比和可操作的信噪比百分比。

信噪比调查结果与其他警报属性一起保存以供进一步分析，并合并到随叫随到仪表板统计数据和轮班报告电子邮件中。

测量换挡质量

在设计随叫随到仪表板时，另一个主要考虑因素是我们如何使用该工具不仅监控警报和信噪比，而且还确保随叫随到的负载在各个团队之间平均分配。为了成功地做到这一点，我们必须量化和跟踪当前个人团队和整个组织对随叫随到责任的看法。

为了解决这个问题，我们开发了一个包含各种随叫随到的轮班指标的通用方程。对于我们的用例，函数的输出是两个数字，代表随叫随到的轮班负载和随叫随到的工程师操作的质量。负载、质量及其相应的度量标准被用作kpi，根据目标和时间的进展来衡量随叫随到的体验。初始实现根据以下指标计算移位负载:警报数量、干扰、运行簿和注释，以及信噪比和孤立警报的缺失。下面，我们将详细分析这些指标:

• • 警报。警报指标基于警报计数。例如，低紧急警报被认为不如高紧急警报重要，并且手动创建或升级的警报需要更多的时间来解决。前几个警报会被忽略，接下来会对整体轮班负载评分产生明显但逐渐衰减的影响。
  • 干扰。“扰动”分数表示随叫随到的动作分布。如果工程师在换班期间不断受到警告，则干扰效果会增加。为了评估这一点，我们从工程师的生产时间中扣除每个警报15分钟。
  • 运行手册。每个警报包含一个运行本和运行本质量评分，由值班工程师在前一班分配。运行手册度量仅仅是运行手册分数的平均值减去100%。0%的“糟糕运行记录”指标意味着在该班次的所有警报中，所有运行记录得分都是5颗星。
  • 注释和信噪比。标注和信噪比指标分别表示标注警报和信噪比标记警报的比例。较高的注释和标记率表明在移交时提供了关于位移的更完整的信息，并为将来的分析收集。
  • 孤儿警报。孤立的警报，意味着在轮班结束时仍然打开但没有注释的警报，表明在下一个轮班期间随叫随到的参与度较低，工作量增加。孤立警报度量度量的质量与警报度量相似，在最初几个警报之后呈指数下降。

由负载和质量值组成的各个组件以及随叫随到的轮班指标包括在轮班报告中，与下一个随叫随到的工程师共享。这些轮班报告本质上是给定轮班结束时随叫随到情况的快照，包括一个警报时间轴，如下图9所示:

报告包括警报时间表、所有警报的压缩列表、它们的注释以及工程师离职的自由形式的摘要。总结统计数据和质量数据也包括在本报告中。

分析

除了跟踪特定的警报、信噪比和指标外，随叫随到的仪表板还包含详细的分析，描绘这些随叫随到的数据，以改进流程，并最终为我们的工程师提供整体随到随到的体验。我们的分析解决方案基于Elasticsearch和Kibana框架(广泛应用于我们的技术堆栈)，因为Kibana的表格、线条、柱状图和大数字可视化是我们规模和规模的理想解决方案。

每个警报作为单独的文档存储在Elasticsearch中，其中包含警报细节，如警报处理时间、注释和警报源，共有超过70个属性。包含多个用于聚合特定于移位数据的数值字段的移位文档也会在每次移位结束后立即发布到Elasticsearch。shift活动的摘要由90多个属性组成，包括注释统计信息、snr -注释统计信息和警报持续时间统计信息等等。除了每周、每月和每年的仪表板之外，随叫随到的团队还可以创建定制的随叫随到摘要来显示团队特定的数据。

下面的图10-13概述了通过On-Call Dashboard访问的一些可视化用例:

既然我们已经介绍了所有这些特性，那么让我们来看看如何应用On-Call Dashboard来改善Schemaless团队的随叫随到工程师的体验。

从数据到行动:无模式用例

无模式是Uber Engineering的可扩展的、mysql驱动的数据存储，它使我们能够大规模地发展我们的基础设施。考虑到Schemaless的巨大范围，随叫随到的工程师对于确保使用该数据存储的其他人获得无缝的用户体验至关重要。

通过On-Call Dashboard访问易于解释、可操作的指标是该团队的第一个重大胜利。在下面的图14的左侧，我们描述了他们对我们一体化随叫随到监测和报告系统的初步收获:测量警报:

Schemaless团队的第二个主要好处是能够注释这些警报。如图14所示，一旦带注释的警报数量接近100%，警报总数就开始稳步下降，这表明一旦确定了警报(或警报组)的根本原因，就可以解决它。注释有助于每周的统计数据更新，因为团队现在可以访问有关原因的详细信息以及响应警报所采取的相应操作。

Schemaless团队可以与其他可能在随叫随到时收到类似警报的团队分享这些见解。此外，on - call Dashboard分析可视化还使团队能够识别比其他警报发生得更频繁的警报，以便他们能够集中精力处理它们。

为了充分利用此解决方案，团队在工作日期间所有团队成员都可以看到的大型监视器上显示了on - call Dashboard，从而可以轻松地随时协作监视服务的运行状况。即使在非工作时间，通过在仪表板上保持标签，团队成员也可以在一天的所有时间内意识到他们的系统正在发生什么，从而促进更大的协作和团队范围内的随叫随到过程的所有权。这种协作感增加了团队成员之间的同理心，他们现在完全理解在非工作时间随叫随到的需求。

为每个人提供更无缝的随叫随到体验

目前，Uber的数百个团队都在使用随叫随到的仪表盘，为我们随叫随到的工程师提供更无缝的体验。随着Uber的服务规模不断扩大，这个新工具和其他SRE解决方案将确保这些服务在一天中的任何时候都能正常运行。如果构建系统以提高工程师的生产力和改善随叫随到的体验对你有吸引力，可以考虑申请一个角色在我们队!

Vytautas Saltenis和Marijonas petraeus是软件工程师，Edvinas Vyzas是工程经理。这三家公司都位于优步位于立陶宛维尔纽斯的办公室。