Get best of the week

操作大型分布式系统：我学到的知识



在阅读各种渠道和新闻通讯时，我经常碰到有关特定“痛苦”的文章，以及当公司发展，可靠性和可扩展性脱颖而出时出现的问题。这篇文章是不同的。没有对特定体系结构解决方案的详细分析，也没有有关更改工程文化的逐步指南。相反，它是操作分布式系统时出现的挑战的俯视图，并且是一个可以帮助您导航术语，缩写和技术流程的起点。

我提请您注意由Uber工程师撰写的文章的翻译。

* * *

在过去的几年中，我在Uber创建并维护了一个大型的分布式支付系统。在这段时间里，我学到了很多有关分布式体系结构的概念。从我自己的经验中，我发现创建和维护具有高可用性的高负载系统是多么困难。构建这样的系统是一件有趣的工作。我喜欢计划系统如何处理10-100倍的流量增长，以确保无论硬件故障如何数据的可靠性。但是，使用大型分布式系统给我带来了意想不到的经验。

系统越大，您越有可能会遇到墨菲定律的表现形式：“ 所有可能出错的事物都会出错。”对于频繁发布的版本，当许多开发人员推出代码，使用多个数据中心并在世界范围内拥有大量用户时，这种可能性特别高。在过去的几年中，我遇到了各种系统崩溃，其中许多使我感到惊讶：从可预测的问题（例如硬件崩溃或无辜的错误）到电缆断裂，这些断裂将数据中心连接到同时发生的许多级联崩溃。我经历了数十次故障，这些故障中系统的某些部分无法正常工作，从而极大地影响了业务。

本文总结了通过在Uber中运行大型系统而受益的技术。我的经验并不独特：其他人使用相同大小的系统并经历相同的冒险。我与来自Google，Facebook和Netflix的工程师进行了交谈，他们面临类似的情况并提出了类似的解决方案。无论它们是在公司拥有的数据中心（在Uber中通常是这种情况）还是在云（Uber 有时在其中进行扩展）中工作，这里描述的许多想法和过程都可以应用于相同规模的系统。但是，对于公司而言，这些技巧对于不是那么大或重要的系统可能是多余的。

我们将讨论以下主题：

  • 监控方式
  • 值班（通话中），异常检测和通知。
  • 故障和事件管理。
  • 发布事态，事件分析和持续改进的文化。
  • 故障转移，资源计划和黑盒测试。
  • SLO，SLA及其报告。
  • SRE作为独立团队。
  • 作为永久性投资的可靠性。
  • 有用的材料。

监控方式


要了解系统是否正常运行，我们需要回答以下问题：“ 它是否正常工作？”。为此，至关重要的是收集有关系统关键部分的信息。而且，当您在众多服务器和不同数据中心中拥有由各种服务组成的分布式系统时，可能很难确定您真正需要跟踪哪些关键点。

监视基础结构的状态。如果一台或多台计算机/虚拟机超载，则分布式系统的某些部分可能会降低性能。运行服务的计算机的状态指标-处理器资源和内存的消耗-这些是需要监视的基本参数。有些平台最初会跟踪这些指标并自动扩展实例。 Uber拥有一支强大的核心基础架构团队，默认情况下会提供监视和警报。无论采用哪种实现方法，都必须了解实例，基础结构或单个服务存在问题的信息。

服务状态监视：流量，错误，延迟。通常，您需要回答以下问题：后端工作正常吗？ ”。监视诸如传入流量的数量，错误的比例和响应延迟之类的指标可提供有关服务状态的有价值的信息。我更喜欢为所有这些指标创建仪表板。创建新服务时，使用正确的HTTP响应并监视相应的代码可以告诉您很多有关系统状态的信息。如果您确定为客户端错误返回了4xx代码，而对于服务器错误则返回了5xx代码，那么创建和解释这种监视将很容易。

关于监视响应延迟还有其他事情要说。生产服务的目标是让大多数最终用户享受使用它们的乐趣。测量平均延迟并不是最佳解决方案，因为平均值可以隐藏少量具有较大延迟的请求。最好测量p95，p99或p999-请求的第95、99或99.9％的延迟。这些数字有助于回答诸如“ 99％的访问者的请求速度有多快？”之类的问题。 “（P99）或” 每1000个访客中的一个访客的请求速度有多慢？ “（P999）。如果您对这些细节感兴趣，则可以阅读本文。


p95和p99的图表。请注意，此端点的平均延迟小于1秒，并且1％的请求需要2秒。还有更多-在测量平均值时看不到。

监视和可观察性的主题更加深入。我建议阅读Google SRE书和有关监视分布式系统的四个黄金信号部分。如果对于与用户进行交互的系统，您只能获得四个指标，则将重点放在流量，错误，延迟和饱和度上。很少有资料-电子书Distributed Systems Observability，它描述了日志等有用的工具以及使用度量和跟踪的最佳实践。

监视业务指标。监视服务告诉我们它们的整体状况。但是，仅从监视数据来看，我们不能说这些服务是否正常运行，或者从业务角度来看一切是否得到正确处理。对于支付系统，主要问题是：“ 人们可以使用特定的支付方式出行吗？ ”。监视中最重要的步骤之一就是识别和跟踪由该服务创建和处理的业务事件。

在我们无法以其他方式检测到的故障之后，我的团队创建了对业务指标的监视。一切看起来好像服务在正常运行，但是实际上关键功能无法正常工作。对于我们公司和活动领域而言，这种监视非常罕见。因此，我们必须付出很多努力来为自己配置此监视，以创建我们自己的系统。

值班，异常检测和警报


监视是检查系统当前状态的好工具。但这只是自动检测故障并警告那些在这种情况下应该采取措施的人的一步。

观看是一个广泛的话题。 Increment Magazine出色地完成了On-Call问题中的许多问题。我认为，职责是“您创建的-您自己的”方法的逻辑延续。这些服务归制作它们的团队所有，他们还拥有警报和事件响应系统。我的团队拥有这样一个我们创建的支付服务系统。当警报到达时，值班工程师必须做出响应并找出正在发生的情况。但是，我们如何从监视变为警报？

根据监视数据确定异常是一项艰巨的任务，机器学习应该在这里充分体现出来。有许多第三方服务可用于检测异常。对于我的团队而言，幸运的是，我们公司拥有自己的机器学习小组来解决Uber面临的问题。纽约团队撰写了一篇关于Uber如何检测异常的有用文章。从我的团队的角度来看，我们仅将监视数据传输到该管道，并以不同的置信度接收警报。然后，我们决定是否通知工程师。

我什么时候需要发送警报？这个问题很有趣。如果警报太少，那么我们可能会错过一个重要的故障。如果过多，那么人们将在晚上无法入睡。跟踪和分类警报以及测量信噪比在建立警报系统中起着重要作用。值班工程师稳定轮换的一个好步骤是分析警报，将事件分类为“需要采取行动”和“不需要”，然后减少不需要采取行动的警报数量。


由维尔纽斯的Uber开发者体验团队创建的“ 呼叫职责”面板的示例。

由维尔纽斯（Vilnius）创建开发工具的Uber团队创建了一个小工具，我们可以用它来对警报发表评论并可视化值班。我们的团队每周都会报告上次值班的工作情况，分析不足之处并改进值班方法。

故障和事件管理


想象一下：你是一个星期的值班工程师。在深夜，您在寻呼机上唤醒一条消息。您正在检查是否发生生产故障。该死的，好像系统的一部分崩溃了。怎么办？监视和警报才起作用。

当值班工程师可以了解发生的情况和原因时，对于小型系统而言，故障可能并不是特别严重的问题。通常在这样的系统中，您可以快速找出原因并消除它们。但是，在包含许多（微）服务的复杂系统的情况下，当许多工程师将代码发送给操作人员时，失败的原因非常困难。遵守几个标准程序可能会很有帮助。

第一道防线是标准响应程序的操作手册描述简单的故障排除步骤。如果公司有这样的清单并得到积极支持，那么对值班工程师对该系统的肤浅想法就不会成为问题。列表需要保持最新，更新和处理以解决问题的新方法。

通知其他员工的失败如果几个团队参与推出一项服务，这将变得非常重要。在我工作的环境中，成千上万的工程师根据需要部署了服务，每小时发布数百次。一项服务看似无害的部署可能会影响另一项服务。在这种情况下，故障报告和通信通道的标准化将发挥重要作用。在很多情况下，警报与其他警报都不一样，我意识到对于其他团队来说，这看起来也很奇怪。在关于故障的一般交谈中进行交流，我们确定了导致故障的服务并迅速消除了后果。我们共同努力做到这一点要比我们任何一个人都要快得多。

立即消除后果，明天再解决。在一次事故中，由于渴望纠正错误，我经常被一连串的肾上腺素淹没。问题的原因通常是推出带有明显错误的错误代码。以前，我会退出所有程序并开始更正错误，发送修复程序并回滚失败的代码。但是在事故中确定原因是一个糟糕的主意。快速修复后，您将收效甚微，却损失很多。由于需要快速完成修复，因此必须在战斗中进行测试。这是在现有错误之上获得新错误或新失败的途径。我看到了这是如何导致许多失败的。只专注于解决后果，不要试图解决代码或找到原因。调查将等到明天。

岗位事态，事件分析和持续改进的文化


事故报告是团队应对故障后果的重要特征。这种情况会使人担心吗？他们是做一点研究还是在观察上花费大量精力，停产并进行纠正？

正确编写的验尸报告是构建可持续发展系统的主要要素之一。它不谴责任何人，也不寻找罪魁祸首，这是对事件的深入研究和分析。随着时间的流逝，我们针对此类报告的模板不断发展，最终结论，影响评估，事件发生的时间顺序，主要原因分析，汲取的经验教训以及需要进一步观察的要素的详细列表都将出现。


我在Uber中使用了这种错误处理模式。

在一个好的验尸报告中，对故障原因进行了彻底调查，并提出了预防，发现或迅速消除类似故障后果的措施。当我说“深入”时，我的意思是作者并不会因为这样的事实而停下来，即原因是代码滚动以及审阅者没有注意到的错误。作者应该运用“为什么五”方法得出更有用的结论。例如：

  • 为什么有问题？->该错误已作为代码的一部分上传。
  • 为什么没有人发现错误？->进行审核的人员没有注意到更改代码可能会导致此类问题。
  • , ? --> .
  • ? --> .
  • ? --> .
  • : . , .

事件分析是处理错误的重要辅助工具。尽管有些团队在错误方面进行了认真的工作，但其他团队可能会从附加数据中受益并进行预防性改进。团队认为自己负责并有能力在系统级别提出建议的改进也很重要。

在重视可靠性的组织中，最有经验的工程师会分析并消除最严重的事件。还必须在公司一级进行工程管理，以确保可以进行更正，尤其是在这些耗时或干扰其他工作的情况下。不能在一夜之间创建可靠的系统：需要不断的迭代。基于从事件中汲取的教训不断改进的公司文化所产生的迭代。

故障转移，资源计划和黑盒测试


有几种常规程序需要大量投资，但对于维护大型分布式系统至关重要。我最初是在Uber遇到这些想法的，由于基础设施规模较小且不可用，因此不需要将其应用于其他公司。

在我自己遇到这个问题之前，我曾考虑过在数据中心进行愚蠢的故障转移（故障转移）。最初，我认为，一个稳定的分布式系统的设计就是数据中心的稳定性下降。如果在理论上一切正常，为什么要定期进行测试？答案取决于扩展和测试服务以有效处理新数据中心流量意外增长的能力。

我遇到的最常见的故障情况是，在发生故障转移时，该服务在新数据中心中没有足够的资源来处理全局流量。假设服务A在一个数据中心中工作而服务B在另一个数据中心中工作，则将资源消耗设为60％-每个数据中心中有数十个或数百个虚拟机旋转，并且在达到70％的阈值时触发警报。从数据中心A到数据中心B的所有流量都失败了，第二个数据中心在不部署新机器的情况下无法应对如此大的负载。但是，这可能会花费很多时间，因此请求开始堆积和下降。阻塞开始影响其他服务，从而导致与主要故障转移无关的其他系统的级联故障。


故障转移可能会导致问题的可能情况。

另一种流行的故障场景涉及路由级别的问题，网络带宽或背压问题。数据中心的故障转移是任何可靠的分布式系统都必须执行的开发，而不会对用户造成任何影响。我强调- 应该，此开发是检查分布式Web系统可靠性的最有用的练习之一。

计划的服务停机练习一种测试整个系统稳定性的好方法。它也是检测特定系统的隐藏依赖性或不适当/意外使用的好工具。计划内的停机时间练习可以相对容易地与客户端交互的服务执行，并且具有很少的依赖性。但是，如果我们谈论的是允许停机时间非常短或许多其他系统所依赖的关键系统，那么将很难进行此类练习。但是，如果有一天这种系统不可用怎么办？最好在受控实验中回答此问题，以便所有团队都得到警告并准备就绪。

黑盒测试（“黑匣子”方法）是一种在尽可能接近与最终用户进行交互的情况下评估系统正确性的方法。这类似于端到端测试，不同的是，对于大多数产品而言，正确的黑盒测试需要您自己进行投资。进行此类测试的合适人选是涉及用户交互的关键用户流程和场景：要测试系统，请确保可以随时启动它们。

以Uber为例，一个明显的黑匣子测试正在检查城市级别的驾驶员与乘客的互动：乘客是否可以找到驾驶员并根据特定要求出行？在自动完成此方案后，可以定期运行测试，以模拟不同的城市。可靠的黑匣子测试系统可轻松验证系统或其零件的正确运行。它还对故障转移测试有很大帮助：获得切换反馈的最快方法是运行黑盒测试。


故障转移故障转移和手动回滚期间的黑盒测试示例。

资源规划在大型分布式系统中起着特别重要的作用。总的来说，我的意思是那些计算和存储成本以每月数万或数十万美元计算的公司。在这种规模下，拥有固定数量的部署可能比使用自扩展云解决方案便宜。在极端情况下，固定部署应处理“正常业务”所特有的流量，并仅在高峰负载时自动扩展。但是下个月要申请的最少实例数是多少？在接下来的三个月中？明年？

为具有大量统计信息的成熟系统预测未来的流量模式并不难。这对于预算，供应商的选择或确定云提供商的折扣非常重要。如果您的服务产生大量帐户，而您还没有考虑过资源计划，那么您将缺少一种降低成本并进行管理的简便方法。

SLO，SLA及其报告


SLO代表服务水平目标，它是系统可用性的度量。优良作法是在服务级别设置SLO，以提高性能，响应时间，正确性和可用性。然后，这些SLO可以用作警报阈值。例：

SLO指标子类别服务价值
性能最小带宽每秒500个请求
2 500
50-90
p99500-800
0,5 %
99,9 %

业务层面的SLO。或功能性SLO，这是对服务的抽象。它们涵盖自定义或业务指标。例如，业务级别的SLO可能是这样的：预计99.99％的收据将在完成旅行后1分钟内寄出。该SLO可以在服务级别上与SLO进行比较（例如，随着付款系统的延迟或发送邮件支票的系统的延迟），并且可以单独进行测量。

SLA-服务水平协议。这是服务提供商与其使用者之间的更一般性协议。通常，多个SLO组成一个SLA。例如，支付系统的可用性为99.99％可以是SLA，它被划分为每个对应系统的特定SLO。

确定SLO之后，您需要对其进行度量并做出报告。关于SLA和SLO的自动监视和报告通常是一个复杂的项目，工程师和企业都不希望优先考虑。工程师将不会感兴趣，因为他们已经具有不同级别的监视以实时识别故障。企业最好优先考虑交付功能，而不是投资不会立即带来收益的复杂项目。

这就引出了另一个话题：运行大型分布式系统的组织早晚需要分配人员来确保这些系统的可靠性。让我们谈谈SRE团队-站点可靠性工程。

SRE作为独立团队


“ 网站可靠性工程”一词是Google于2003年左右提出的，如今有1500多名SRE工程师。随着生产环境的操作变得越来越复杂，需要更多的自动化，它将很快成为一项成熟的工作。当公司意识到工程师几乎全天致力于生产环境的自动化时，就会发生这种情况：系统越重要，发生的故障越多，SRE越早成为独立的职位。

成长迅速的技术公司通常会在早期建立一支SRE团队，他们会自行计划。在Uber，于2015年成立了这样的团队。其目标是管理系统的复杂性。在其他公司中，SRE团队的分配可以与创建单独的基础架构团队相关联。当公司发展到确保服务可靠性需要大量工程师关注的程度时，就该创建一个单独的团队了。

SRE团队为所有工程师大大简化了大型分布式系统的维护。 SRE团队可能拥有标准的监视和警报工具。他们可能正在购买或创建通话工具，并愿意分享他们的经验。它们可以促进对事件的分析，并创建可以更轻松地检测故障，减少故障后果并防止将来发生故障的系统。 SRE命令肯定有助于故障转移操作。它通常用于测试黑匣子和计划性能。 SRE工程师管理标准工具的选择，定制或创建，以确定和衡量SLO并报告相关标准。

鉴于所有公司都有其自身的问题，因此他们招募SRE的解决方案是不同公司中的此类团队具有不同的结构。甚至名称也可能有所不同：它可以是运营服务，平台工程或基础架构服务。Google已出版了两本关于确保服务可靠性的强制性阅读书。它们是免费提供的，并且是深入研究SRE主题的绝佳信息来源。

作为永久性投资的可靠性


在创建任何产品时，组装第一个版本只是开始。之后，将出现具有新功能的新迭代。如果产品成功且有利可图，则工作将继续。

分布式系统具有相同的生命周期，除了它们不仅需要在新功能上而且在跟上扩展方面需要更多的投资。当系统的负载增加时，您必须存储更多的数据，需要更多的工程师在系统上工作，因此，您必须不断维护其正常运行。许多初次创建分布式系统的人认为它们就像一台机器：一旦完成，就足以每隔几个月进行一次维护。很难提出与现实相去甚远的比较。

, , 。为了使医院运转良好，需要不断进行检查（监视，警报，黑匣子测试）。始终需要使用新的员工和设备：对于医院来说，这些是护士，医生和医疗设备，对于分布式系统来说，则是新的工程师和服务。随着员工人数和服务数量的增加，旧的工作方法变得无效：农村的小型诊所与大都市的大型医院的工作方式有所不同。实现更有效的运行方式将成为一项成熟的工作，并且测量和警报变得越来越重要。大型医院需要更多人员，例如会计，人力资源和安全部门，大型分布式系统的运行依赖于基础架构和SRE等服务团队。

为了使团队能够维护可靠的分布式系统，组织必须不断投资于其功能以及构建该系统的平台的工作。

有用的材料


尽管文章篇幅很长，但仅显示了最肤浅的时刻。要了解有关分布式操作系统的功能的更多信息，我建议以下来源：

书籍


网站


请参阅Hacker News上有关本文的评论。

More articles:


All Articles