关于sre:Uber-SRE-实践运维大型分布式系统的一些心得

本文是 Uber 的工程师 Gergely Orosz 的文章，原文地址在：https://blog.pragmaticengineer.com/operating-a-high-scale-dis…

在过来的几年里，我始终在构建和经营一个大型分布式系统：优步的领取零碎。在此期间，我学到了很多对于分布式架构概念的常识，并亲眼目睹了高负载和高可用性零碎运行的挑战（一个零碎远远不是开发完了就完了，线上运行的挑战理论更大）。构建零碎自身是一项乏味的工作。规划系统如何解决 10x / 100x 流量的减少，确保数据长久，面对硬件故障解决等等，这些都须要智慧。不管怎样，运维大型分布式系统对我来说是一次令人大开眼界的体验。

零碎越大，墨菲的“什么可能出错，就会出错”的定律就越会体现。频繁部署、部署代码的开发人员数量很多，波及多个数据中心、零碎被大量寰球用户应用，这种出错概率越大。在过来的几年里，我经验过各种各样的系统故障，其中很多让我感到诧异。有些来自可预测的事件，比方硬件故障或一些看起来有害的 Bug，还有数据中心线缆被挖断、同时产生多个级联故障。我经验了数十次业务停摆，零碎的某些局部无奈失常工作，从而导致微小的业务影响。

这篇文章是我在 Uber 工作时总结的，能够无效运维大型零碎的实际的汇合。我的教训并不是举世无双的 – 在相似规模的零碎上工作的人也经验了相似的旅程。我与 Google，Facebook 和 Netflix 的工程师进行了交谈，他们分享了相似的教训和解决方案。这里列出的许多想法和流程应该实用于相似规模的零碎，无论是在本人的数据中心（如 Uber 大多数状况下）上运行，还是在云上运行（Uber 有时会把局部服务弹性部署到云上）。然而，对于规模较小或较少要害工作的零碎而言，这些做法可能过于刻薄。

波及的内容很多——我将探讨以下主题：

• 监控
• 值班，异样检测和警报
• 故障和事件治理流程
• 预先剖析，事件回顾和继续改良文化
• 故障演习，容量布局和黑盒测试
• SLOs、SLAs 及其报告
• SRE 作为独立团队
• 可靠性作为继续投资
• 更多举荐浏览

监控

要晓得零碎是否衰弱，咱们须要答复“我的零碎是否失常工作”的问题？为此，收集零碎要害局部的数据至关重要。对于在多台计算机和数据中心上运行多个服务的分布式系统，可能很难确定要监控的要害内容是什么。

基础设施衰弱监测 如果一个或多个计算机 / 虚拟机过载，则分布式系统的某些局部可能会降级。机器的健康状况，CPU 利用率、内存应用状况，是值得监控的根底内容。有些平台能够开箱即用地解决这种监控和主动扩大实例。在优步，咱们领有一支优良的外围基础设施团队，提供开箱即用的基础设施监控和警报。不论技术层面如何实现，实例或基础设施出问题的时候，监控平台须要提供必要的信息。

服务运行状况监控：流量，谬误，提早。咱们常常须要答复“这个后端服务是否衰弱？”这样的问题。察看拜访端点的申请流量、错误率和端点提早等事项都能够提供无关服务健康状况的有价值信息。我更喜爱将这些都显示在仪表板上。在构建新服务时，通过应用正确的 HTTP 响应映射并监督相干代码能够对系统有很多理解。因而，确保客户端谬误能返回 4XX，以及如果服务器谬误则返回 5xx，这种监控易于构建且易于解释。

监测提早值得再考虑一下。对于生产服务，指标是让大多数最终用户取得良好的体验。事实证明，测量均匀提早并不是一个很好的指标，因为这个平均值能够暗藏一小部分高提早申请。测量 p95，p99 或 p999 – 第 95 百分位，第 99 百分位或第 99.9 百分位的申请所经验的提早 – 是一个更好的指标。这些数字有助于答复诸如“99%的人的申请有多快？”之类的问题（p99）。或“1000 人中，至多有一人经验了多慢的提早？”（p999）。对于那些对这个主题更感兴趣的人，这篇提早入门文章能够进一步浏览。

从图上能够显著看出，均匀提早、p95、p99 差别还是比拟大的。所以均匀提早有可能覆盖一些问题。

围绕监控和可察看性有很多更有深度的内容。值得一读的两个资源是 Google 的 SRE 书和对于分布式系统监控的四个黄金指标的局部。他们倡议，如果您只能测量面向用户的零碎的四个指标，请关注流量，谬误，提早和饱和度。比拟简短的资料的话，举荐来自 Cindy Sridharan 的分布式系统可察看性电子书，它波及其余有用的工具，如事件日志，指标和跟踪最佳实际。

业务指标监控。监控服务模块，能够通知咱们服务模块运行的如何如何失常，但无奈告知咱们业务是否按预期工作，是否“照常营业”。在领取零碎，一个关键问题是，“人们能够应用特定的领取形式进行领取业务吗？”。辨认业务事件并对其监控，是最重要的监控步骤之一。

尽管咱们建设了各种监控，有些业务问题依然无奈探测到，这让咱们蒙受了微小的苦楚，最终建设了业务指标的监控。有时咱们所有的服务看起来都在失常运行，但要害产品性能不可用！这种监控对咱们的组织和畛域来说十分有用。因而，咱们必须在 Uber 的可察看性技术堆栈的根底上，为本人定制这种类型的监控做了大量的思考和致力。

译者注：业务指标监控这一点，咱们切实是太深有同感了，之前在滴滴有时就是发现所有服务都失常，然而业务不好使。咱们当初守业做的北极星零碎，就是专门应答这个问题的。感兴趣的敌人能够在公众号后盾给我留言，或加我好友 picobyte 交换试用。

Oncall，异样检测和警报

监控对于洞察零碎的以后状态而言，是一个很棒的工具。但这只是自动检测问题并收回警报以供人们采取行动的一个垫脚石。

Oncall 自身是一个宽泛的话题 – Increment 杂志在其“On-Call 问题”中涵盖了许多方面的内容。我的强烈认为，如果你领有了 ”you build it, you own it” 的心态，那随着而来的就是 OnCall。构建服务的团队领有这些服务，也负责值班。咱们的团队负责领取服务的值班。因而，每当呈现警报时，值班工程师都会响应并查看详细信息。然而如何从监控到警报呢？

从监控数据中检测异样是一个艰巨的挑战，也是机器学习能够发光的畛域。有很多第三方服务提供异样检测。再次侥幸的是，咱们团队有一个外部机器学习团队与之单干，他们依据 Uber 的应用状况量身定制了解决方案。位于纽约的 Observability 团队撰写了一篇有用的文章，介绍 Uber 的异样检测工作原理。从我的团队的角度来看，咱们将监控数据推送到该团队的管道，并取得具备各自置信度的警报。而后咱们决定是否应该呼叫工程师。

何时触发警报是一个乏味的问题。警报太少可能意味着错过有影响的中断。太多会导致不眠之夜并使人精疲力竭。跟踪和分类警报以及测量信噪比对于调整警报系统至关重要。查看警报并标记它们是否可操作，而后采取措施缩小不可操作的警报，这是朝着实现可继续的随叫随到轮换迈出的良好一步。

Uber 应用的外部 oncall 仪表板示例，由 Vilnius 的 Uber 开发人员体验团队构建。

位于 Vilnius 的 Uber 开发工具团队构建了整洁的呼叫工具，咱们用它来正文警报并可视化呼叫班次。咱们的团队每周对上一次值班班次进行回顾，剖析痛点并花工夫改善值班体验，一周又一周。

译者注：告警事件的聚合、降噪、排班、认领、降级、协同、灵便的推送策略、多渠道推送、和 IM 买通，是很通用的需要，能够参考 FlashDuty 这个产品，体验地址：https://console.flashcat.cloud/

故障和事件治理流程

设想一下：你是本周的值班工程师。中午，一个警报把你吵醒了。你考察是否有生产中断产生。蹩脚，仿佛零碎的某个局部呈现了故障。当初怎么办？监控和警报实在产生了。

对于小型零碎来说，中断可能不是什么大问题，值班工程师能够理解正在产生的事件以及起因。它们通常易于了解且易于缓解。对于具备多个（微）服务的简单零碎，许多工程师将代码推向生产，仅仅查明潜在问题产生的地位就曾经足够具备挑战性了。有一些规范流程来帮忙解决这个问题会产生微小的改观。

附加到警报的Runbook 手册，形容简略的缓解步骤是第一道防线。对于领有良好 Runbook 手册的团队，即便值班工程师不深刻理解零碎，也很少会成为问题。Runbook 须要放弃最新、更新，并在故障呈现时应用新型缓解措施进行解决。

译者注：Nightingale 和 Grafana 的告警规定配置中，能够反对自定义字段，然而有些附加字段是默认就会提供的，比方 RunbookUrl，外围就是想传播 SOP 手册的重要性。另外，稳定性治理体系里，告警规定是否预置了 RunbookUrl，是一个很重要的告警衰弱度的掂量指标。

一旦有超过几个部署服务的团队，跨组织进行故障交换 就变得至关重要。在我工作的环境中，成千上万的工程师会依据本人的判断将他们所开发的服务部署到生产环境中，每小时可能会有数百次部署。一个看似不相干的服务部署可能会影响另一个服务。在这种状况下，标准化的故障播送和通信渠道能够起到很大作用。我已经遇到过多种常见的警报信息 – 意识到其余团队中的人也看到了相似奇怪景象。通过退出一个集中式聊天群组来解决故障，咱们迅速确定了导致故障的服务并解决了问题。咱们做得比任何独自一人更快地实现了工作。

当初缓解，今天考察。在故障期间，我常常会感到“肾上腺素飙升”，想要修复呈现问题的中央。通常根本原因是蹩脚的代码部署，在代码更改中存在显著的谬误。过来，我会立刻跳进去修复谬误、推送修复并敞开故障，而不是回滚代码更改。然而，在故障期间修复根本原因是一个可怕的想法。采纳后退式修复收益甚微，损失却很大。因为新的修复须要迅速实现，所以必须在生产中进行测试。这就是引入第二个谬误 – 或者在现有谬误之上再呈现一个故障 – 的起因。我见过像这样的故障一直好转。只需先集中精力缓解，抵制修复或考察根本原因的激动。适当的考察能够等到下一个工作日。

译者注：这一点老司机应该也深有感触，不要在线上 Debug，呈现问题立刻回滚而不是尝试公布 hotfix 版本来修复！

预先剖析，事件回顾和继续改良文化

这是在说一个团队如何解决故障的后续。他们会持续工作吗？他们会做小规模的考察吗？他们是否会在后续工作中破费惊人的精力，进行产品工作以进行零碎级修复？

正确进行的预先剖析是构建弱小零碎的基石。一份好的预先剖析既无指摘，又非常彻底。Uber 的预先剖析模板随着工程技术的倒退而一直演变，包含事件概述、影响总览、工夫线、根本原因剖析、经验教训以及具体跟进清单等局部。

这是一个相似我在 Uber 工作中用到的复盘模板。

良好的预先剖析深刻开掘根本原因并提出改良措施，以更快地预防、检测或缓解所有相似的故障。当我说深刻开掘时，我的意思是他们不会停留在根本原因上，即谬误的代码更改和代码审查者没有发现错误。

他们应用“5why”摸索形式进行更深刻的开掘，以达到更有意义的论断。举个例子：

• 为什么会呈现这个问题？–> 因为代码里引入了 bug。
• 为什么其他人没有发现这个谬误？–> 代码审查员没有留神到代码更改可能会导致此类问题。
• 咱们为什么只依赖于代码审查员捕捉此谬误？–> 因为咱们没有针对此用例的自动化测试。
• “为什么咱们没有针对此用例的自动化测试？”–> 因为在没有测试帐户的状况下很难进行测试。
• 咱们为什么没有测试帐户？–> 因为该零碎尚不反对它们
• 论断：这个问题指向了不足测试账户的系统性问题。倡议将测试账户反对增加到零碎中。接下来，编写所有将来相似代码更改的自动化测试。

事件回顾 是预先剖析的重要配套工具。尽管许多团队在预先剖析方面做得很彻底，但其余团队能够从额定的输出和对预防性改良的挑战中受害。同样重要的是，团队要有责任感并有权执行他们提出的零碎级改良。

对于认真对待可靠性的组织，最重大的故障会由经验丰富的工程师进行审查和挑战。组织级别的工程管理人员也应该缺席，以提供受权来实现修复——尤其是当这些修复很耗时并妨碍其余工作时。强壮的零碎不是欲速不达的：它们是通过一直的迭代构建的。怎么能力继续迭代？这须要组织层面有继续改良、从故障中学习的文化。

故障演习，容量布局和黑盒测试

有一些惯例流动须要大量投资，但对于放弃大型分布式系统的失常运行至关重要。这些是我在优步第一次接触到的概念——在以前的公司，咱们不须要应用这些，因为咱们的规模和基础设施没有促使咱们这样做。

一个数据中心故障演练是我认为很无聊的事件，直到我察看了其中几个实际。我最后的想法是，设计弱小的分布式系统正是为了可能在数据中心解体时放弃弹性。如果实践上它能够失常工作，为什么要常常测试呢？答案与规模无关，并且须要测试服务是否可能无效地解决新数据中心中忽然减少的流量。

我察看到的最常见的故障场景是在产生故障转移时，新数据中心的服务没有足够的资源来解决寰球流量。假如 ServiceA 和 ServiceB 别离从两个数据中心运行。假如资源利用率为 60%，每个数据中心都有数十或数百台虚拟机在运行，并设置警报以在 70%时触发。当初让咱们进行故障转移，将所有流量从 DataCenterA 重定向到 DataCenterB。在没有提供新机器的状况下，DataCenterB 忽然无奈接受负载。提供新机器可能须要足够长的工夫，以至于申请会沉积并开始抛弃。这种阻塞可能会开始影响其余服务，导致其余零碎的级联故障，这些零碎甚至不是此故障转移的一部分。

其余常见的故障场景包含路由级别问题、网络容量问题或背压痛点。数据中心故障转移是任何牢靠分布式系统应该可能在没有任何用户影响的状况下执行的演习。我强调“应该”——这个演习是测试分布式系统可靠性最有用的练习之一。

译者注：切流量，本就是预案“三板斧”之一。出故障的时候，要保障预案是可用的，那平时就少不了演练。器重起来吧，老铁们。

打算的服务停机工夫练习 是测试整个零碎弹性的极好办法。这些也是发现特定零碎的暗藏依赖项或不适当 / 意外应用的好办法。尽管对于面向客户且依赖较少的服务，这种练习绝对容易实现，然而对于须要高可用性或被许多其余零碎所依赖的要害零碎来说，则不那么容易喽。然而，当某一天这个要害零碎不可用时会产生什么？最好通过受控演练来验证答案，所有团队都晓得并筹备好应答意外中断。

黑盒测试是一种测量零碎正确性的办法，尽可能靠近最终用户所看到的条件。这种类型的测试相似于端到端测试，但对于大多数产品来说，领有适当的黑盒测试须要独自投入。要害用户流程和最常见的面向用户的测试场景是好的黑盒可测性示例：以这种形式进行设置能够随时触发它们，以查看零碎是否失常工作。

以优步为例，一个显著的黑盒测试是查看乘客 - 司机流程是否在城市层面上失常工作。也就是说，在特定城市内的乘客是否申请优步，并与司机单干并实现行程？一旦这种状况被自动化，这个测试能够定期运行，模仿不同的城市。领有弱小的黑盒测试零碎使得验证零碎或局部零碎是否正确工作更加容易。它还对故障转移演练十分有帮忙：获取故障转移反馈最快捷的办法是运行黑盒测试。

上图是在故障转移演练失败时，应用黑盒测试的示例，在演练几分钟后手动回滚。

容量布局 对于大型分布式系统同样重要。所谓大型，是指计算和存储老本每月达到数万或数十万美元。在这个规模下，应用固定数量的部署可能比应用主动扩大的云解决方案更便宜。至多，固定部署应该解决“业务常态”流量，并在顶峰负载时进行主动扩大。然而，在接下来的一个月内、将来三个月内以及明年须要运行多少最小实例呢？

预测成熟且具备良好历史数据的零碎的将来流量模式并不艰难。这对于估算、抉择供应商或锁定云提供商的折扣都很重要。如果您的服务费用很高，而您没有思考容量布局，那么您就错过了升高和管制老本的简略办法。

SLOs, SLAs 以及相干报告

SLO 代表服务级别指标 – 零碎可用性的数字指标。对于每个独立的服务，定义服务级别 SLO（例如容量、提早、准确性和可用性的指标）是一种很好的做法。而后，这些 SLO 能够作为警报的触发器。服务级别 SLO 示例可能如下所示：

业务级 SLO 或性能 SLO 是服务之上的形象。它们将涵盖用户或面向业务的指标。例如，业务级 SLO 可能是这样的：冀望 99.99% 的电子邮件收据在旅行实现后的 1 分钟内发送。此 SLO 可能映射到服务级别 SLO（例如领取和电子邮件接管零碎的提早），或者它们可能须要以不同形式掂量。

SLA – 服务水平协定 – 是服务提供者和服务消费者之间更宽泛的协定。通常，多个 SLO 组成一个 SLA。例如，99.99% 可用的领取零碎能够是 SLA，它合成为每个支持系统的特定 SLO。

定义 SLO 后，下一步是掂量这些并报告它们。对 SLA 和 SLO 进行自动化监控和报告通常是一项简单的我的项目，工程团队和业务部门都偏向于升高其优先级。工程团队可能不太感兴趣，因为他们曾经有各种级别的监控来实时检测故障。另一方面，业务部门更违心将重点放在提供性能上，而不是投资于一个没有立刻商业影响的简单我的项目中。

这就引出了下一个话题：经营大型分布式系统的组织迟早须要为这些零碎的可靠性投入专门的人员。让咱们来谈谈网站可靠性工程团队。

SRE 作为独立团队

网站可靠性工程（Site Reliability Engineering）起源于谷歌，大概在 2003 年左右开始，当初曾经倒退成为领有超过 1,500 名 SRE 工程师的团队。随着生产环境经营变得越来越简单，并须要更多自动化操作，这项工作很快就会成为一项全职工作。公司意识到他们有工程师正在全职从事生产自动化的工夫因状况而异：这些零碎越要害、故障越多，则此类情况呈现得越早。

疾速倒退的科技公司通常会在晚期组建 SRE 团队，由他们制订本人的路线图。在优步，SRE 团队成立于 2015 年，其使命是随着工夫的推移管理系统复杂性。其余公司可能会在创立专门的基础架构团队时同时启动这样的团队。当一家公司倒退到跨团队的可靠性工作占用了很多工程师的工夫时，是时候为此设立一个专门的团队了。

有了 SRE 团队，这个团队能够让所有工程师更轻松地保护大型分布式系统的操作方面。SRE 团队可能领有规范的监控和警报工具。他们可能购买或构建 oncall 工具，并且是 oncall 最佳实际的 goto 团队。他们可能会促成故障复盘并构建零碎，以更轻松地检测、缓解和避免故障。他们当然有助于故障转移演练，常常推动黑盒测试，并参加容量布局。他们推动抉择、定制或构建规范工具来定义和掂量 SLO 并报告它们。

鉴于公司有不同的痛点，他们寻求 SRE 来解决，因而 SRE 组织在公司之间是不同的。这个团队的名称通常也会不同：可能被称为运维、平台工程或基础设施。Google 出版了两本对于站点可靠性的必读书籍，这些书籍可收费获取，是深刻理解 SRE 的绝佳读物。

可靠性作为继续投资

在构建任何产品时，构建第一个版本只是一个开始。在 v1 之后，新性能会增加到行将到来的迭代中。如果产品胜利并带来业务成绩，那么工作就会持续进行。

分布式系统具备类似的生命周期，只是它们须要更多投资，不仅仅是为了新性能，还要跟上扩大的步调。随着零碎开始接受更多负载、存储更多数据、更多工程师对其进行解决，它须要继续关注以放弃安稳运行。很多人第一次构建分布式系统时会认为这个零碎就像一辆汽车：一旦建好，只须要每几个月进行必要的保护。然而这种比拟与理论状况相去甚远。

我喜爱把操作分布式系统的致力比作经营大型组织，例如医院。为了确保医院运行良好，须要进行继续的验证和查看（监控、警报、黑盒测试）。一直有新员工和设施退出：对于医院来说，这是像护士和医生这样的员工以及新的医疗设施；对于分布式系统来说，则是招募新工程师和增加新服务。随着人数和服务数量的增长，旧有做事形式变得低效：就像农村小诊所与大都市中的大型医院不同一样。提出更有效率的办法成为全职工作，并且测量并报告效率变得重要。就像大型医院有财务、人力资源或平安等反对性质的办公室人员一样，经营较大规模分布式系统也依赖基础架构和 SRE 等反对团队。

为了让团队运行牢靠的分布式系统，组织须要继续投资于这些零碎的操作以及它们所构建的平台。

更多举荐浏览

尽管这篇文章的内容很长，但它依然只是涉及外表。要更深刻地理解操作分布式系统，我举荐以下资源：

图书

Google SRE Book – 一本来自 Google 的优良收费书籍。《监控分布式系统》章节对本文尤为相干。

Cindy Sridharan 的《把握分布式跟踪》是另一本优良的收费书籍，其中提出了对于监控分布式系统的重要观点。

Martin Kleppmann 博士的《数据密集型利用零碎设计》是我迄今为止发现的对于分布式系统概念最实用的书籍。然而，这本书并没有波及到文章中探讨的操作方面。

在线资源

《Increment》杂志的“On-Call”问题：一系列对于亚马逊、Dropbox、Facebook、Google 和 Netflix 等公司事变响应流程的文章。

学习构建分布式系统 – AWS 工程师 Marc Brooker 发表的一篇文章，答复了“我如何学习构建大型分布式系统”的问题。

One more thing

Uber 这位仁兄写的内容挺丰盛了，感觉十分有共鸣，前段时间我也写了一个《稳定性体系建设白皮书》，很多思路是相通的，各位看官能够一起查阅，查漏补缺，心愿对你有些帮忙:)