编者按：本文来自微信大众号“InfoQ”（ID：infoqchina），作者Gergely Orosz，译者 足下，策划 蔡芳芳，36氪经授权发布。
在曩昔的几年中，我一向在构建和运营大型分布式体系：Uber 的付出体系。在这段时刻里，我学到了许多分布式架构的概念，也亲眼看到了高负荷高可用体系的构建和运营是多么赋有应战性。就构建体系这件事来说，它自身对错常风趣的。
要规划好当流量增加 10 倍 /100 倍时体系该怎样处理，即便硬件出毛病数据也要能耐久化保存等等，处理这些问题都能够让人有极大的收成。不过关于我个人来说，运营一套大型分布式体系却更是令人大开眼界的阅历。
体系越大，墨菲规律“或许犯错的事终将犯错”就越适用。关于频频进行体系布置、许多开发者协同提交代码、数据涣散在多个数据中心、体系由全球海量用户一同运用这样的场景来说，就更显着。在曩昔的几年中，我阅历过许屡次不同的体系毛病，许多都大大出乎我意料之外。
从可预见的问题——如硬件毛病或不小心把有缺点的代码发布到出产体系，到衔接数据中心的网络光纤被铲断或多个级联毛病一起发作，许屡次毛病都让部分体系无法正常作业，因而导致了停服，终究形成了极大的事务影响。
这篇文章是我在 Uber 作业期间，关于怎样牢靠地运营一套大型分布式体系的阅历总结。我的阅历会很具有普遍性，运营相似规划体系的人也会有相似的阅历。
我从前与谷歌、Facebook、Netflix 等公司的工程师们谈过，他们的阅历和处理计划都很相似。不管体系是运转在自建数据中心（Uber 大多数状况下是这样的），仍是运转在云端（Uber 的体系有时候会扩展到云端），只需体系规划相似，文章中的主意和流程就会适用。不过假如要把阅历照搬到小型体系或非中心体系时就请三思而后行，由于很或许会过为己甚。
详细来说，我会谈到以下论题：
监控
值勤、反常检测与告警
停服与作业办理流程
往后总结、作业回忆与继续改善的文明
毛病切换演习、有计划的停机、容量规划与黑盒测验
SLO、SLA 及相应的陈述
独立的 SRE 团队
对牢靠性做继续投入
深化阅览主张
01 监控
要知道体系是否健康，咱们就要答复问题：“我的体系在正常作业吗？”要给出答案，首要就要搜集关于体系要害部分的数据。关于运转在不同数据中心多台服务器上，由多个不同服务组成的分布式体系来说，决议哪些要害方针需求被监控，这事原本就不简略。
根底设施健康监控：假如一或多台服务器、虚拟机负载过高，那分布式体系就会发作部分降级。服务要运转在服务器上，所以像 CPU 运用率、内存运用率之类的服务器根本健康信息就很值得监控。
有些途径便是专门做这样的监控的，并且支撑主动扩展。Uber 有个很大的中心根底设施团队，专门为咱们供给底层的监控和告警。不管详细的完结计划怎样，当服务的某些实例或根底设施有问题时你都要被告诉到，这些信息有必要把握。
服务健康监控：流量、过错、推迟。“后端服务健康吗”？这个问题真实太泛了。查询终端在处理的流量、过错率、终端推迟等，这些都对服务健康供给着有价值的信息。
我喜爱为它们各自设置专门的仪表盘。构建新服务时，运用适宜的 HTTP 呼应映射，并监控相应的编码，这些都会供给许多关于体系状况的信息。比方在客户端犯错时回来 4XX 编码，在服务端犯错时回来 5XX 编码，这类监控很简略构建，也很简略解读。
对体系推迟的监控值得多考虑一下。关于产品来说，方针便是让大多数的终端用户都有杰出的体会。但只监测均匀推迟这项方针远远不行，由于均匀推迟会掩盖一小部分高推迟的恳求。因而就阅历来说，监测 P95、P99 或 P999（即 95%、99% 或 99.9% 的恳求）的推迟方针会更好。
监测这些方针得到的数字能够答复这样的问题：99% 的人宣布的恳求会有多快得到呼应（P99）？1000 个人宣布恳求，最慢能怎样（P999）？假如有读者对这个论题感兴趣，能够进一步阅览文章《 latencies primer 》。
上图展现的是均匀、P95 和 P99 的推迟方针。请注意，虽然均匀推迟是低于 1 秒的，但有 1% 的恳求花费了两秒或更多时刻才完结，这样的现实被均匀推迟掩盖了。
关于监控和可观测性的论题能够继续深化发掘。有两份资料值得细读，一是谷歌的书《SRE：Google 运维解密》，其他是分布式体系监控的“四个黄金信号”。
从中能够知道，假如你的面向用户的体系只想监测四个方针的话，那么关怀流量、过错、推迟和饱和度就好了。喜爱吃快餐的话，能够读读 Cindy Sridharan 的电子书《分布式体系可观测性》，里边讲到了其它一些有用的东西，如与作业日志、方针和盯梢等有关的最佳实践。
事务方针监控。监控服务能够让咱们了解服务的行为看上去是否正确，但咱们无法得知服务的行为是否契合预期，使得“事务能够照常进行”。以付出体系为例，一个要害问题便是：“人们用某种特其他付出办法买单，是不是现已满意能够完结一次游览？”辨别出服务使能的事务作业，并对这些事务作业进行监控，这是最重要的监控进程之一。
咱们的体系从前阅历了若干次停服，咱们深受其害，在发现这样的停服作业没有其它办法能够监控之后，咱们团队构建了事务方针监控体系。当停服作业发作时，一切的服务都看起来一切正常，但某些跨服务的中心功用便是失效了。该监控是专门针对咱们公司和事务范畴而构建的。因而，咱们就得花许多心思，以 Uber 的可观测性技能栈为根底，努力地为自己定制这类监控。
02 值勤、反常检测与告警
监控能够让人们查看体系的当时状况，是个十分有用的东西。可是，要在体系发作毛病时主动检测并且宣布告警，让人们能够采纳相应地举动，监控仅仅第一步。
值勤便是一个更广的论题了：Increment 杂志在这方面做得很棒，对值勤问题进行了许多方面的评论。我特别倾向于把值勤做为“谁构建，谁担任”思路的一个扩展。哪个团队构建了服务，那就由哪个团队担任值勤。咱们团队就担任自己构建的付出服务的值勤。因而不管什么时候发作了告警，值勤工程师都会呼应并对问题进行处理。咱们该怎样从监控得出正告呢？
从监控数据中发现反常，这是一个巨大的应战，也是机器学习的用武之地。有许多第三方服务能够供给反常检测功用。并且关于咱们团队来说很走运，咱们公司就有机器学习团队能够为咱们供给支撑，他们专门规划了适宜 Uber 用例的处理计划。
坐落纽约的可观测性团队还就 Uber 怎样做反常检测这个主题写过一篇很不错的文章。从咱们团队的视点看，咱们会把咱们的监控数据推送到他们的管道中，并收到不同信赖程度的告警，然后咱们再决议要不要主动呼叫某位工程师。
什么时候宣布告警也是个很值得评论的问题。告警太少或许意味着失去处理某些严重毛病的机遇，告警太多的话值勤工程师就无觉可睡了，究竟人的精力是有限的。因而对告警进行盯梢并分类，并丈量信噪比，这对调理告警体系十分重要。对告警信息进行查看，并符号是否需求采纳相应的动作，不断削减不需求的告警，这就迈出了十分好的一步，让可继续性的值勤行为处于良性循环了。
Uber 内部运用的值勤仪表盘比方，由坐落维尔纽斯的 Uber 开发者体会团队构建
Uber 坐落维尔纽斯的开发者东西团队开发了专门的值勤东西，用于对告警进行注解，并对轮班进行可视化。咱们团队每周都会对上一周的值勤状况进行回忆，剖析痛点，并花时刻进步值勤体会。这件事每周都会做。
03 停服与作业办理流程
想象一下，这周由你值勤。半夜里来了个电话告警，你就要查询一下是否发作了停服，是否会影响出产。成果看到体系真的有一部分失效了，谢天谢地，监控和告警确实反响了体系的真实状况。
关于小型体系来说，停服不算什么大费事，值勤工程师能够判别动身作了什么，以及为什么发作。一般来说他们都能够很快判别问题，并进行处理。而关于运用了多种服务或微服务的杂乱体系来说，许多工程师都在向出产提交着代码，因而判别动身作过错的根本原因，这就有相当大的难度了。在这种状况下，假如有些规范的处理流程，作业就会简略得多。
把运转手册附加到告警信息中，描绘一下简略的处理进程，这便是第一层防地。假如团队的手册写得十分好，那么即便值勤工程师对体系了解得并不深化，这一般也不会是什么问题。手册要不断更新，当呈现新的毛病类型时要赶快进行修订。
当服务由多个部分一同构建时，在部分之间交流毛病也很重要。在咱们公司里，几千个工程师一同作业，他们会自己挑选自认为适宜的机遇将服务布置到出产环境，因而现实上每个小时都会发作几百次布置。对一个服务的布置或许会影响另一个看起来压根不相关的服务。
因而，是否有明晰规范的毛病播送和交流途径就成了毛病顺畅处理的要害。从前发作过好几个事例，告警看起来与我之前见过的好像一点相关都没有，幸亏我想起来其他团队中有些搭档从前见过相似的乖僻问题。在一个大的毛病处理群中，咱们一同很快就定位出了根本原因并处理掉了。做为一个团队来处理问题，总会比单个阅历丰富的职工快得多。
马上康复出产，往后查询原因。在处理毛病的进程中，我也经常会“肾上腺素激增”，想要直接把问题当场处理掉。一般来说毛病都是由某次新布置的代码导致的，改变的代码中会有某些很显着的过错。在从前我一般不会回滚代码，而是直接去修正代码并发布新版别。
但现实上一边出产的毛病没有处理，另一边却去修正代码中的缺点，这真实不是个好主意，这么做收益很小，丢失却很大。由于新的修正代码有必要赶快完结，那就只能在出产环境进行测验，这么做反而愈加简略引进新的缺点，乃至旧的毛病还没处理，新的问题又呈现了。
我也从前见过相似原因导致的一连串的毛病。因而请必定记住，要先康复出产，反抗住马上修正或查询根本原因的引诱。现实上第二天回来上班再细心查询根本原因也未尝不可。
04 往后总结、作业回忆与继续改善的文明
这儿讲的是一个团队怎样进行毛病的后续处理。他们会继续做查询吗？他们会不会停下手头一切与出产有关的作业，花费惊人的价值来做一次体系级的修正？
往后总结是构建强健体系的柱石。好的往后总结对错常详尽和无可挑剔的。Uber 的往后总结模板现已跟着时刻的推移而演进好多个版别了，内容包含许多末节，有作业总结、大约影响、作业发作进程的要害时刻点、根本原因剖析、阅历总结及一系列的后续跟进内容。
一个与我在 Uber 运用的往后总结模板相似的比方
好的往后总结会对毛病根本原因进行深化发掘，得到改善办法来防止相似的毛病发作，或许鄙人一次呈现相似毛病时能够快速检测和康复。我说的深化发掘，不是说浅尝辄止地知道“这次毛病的原因是最近提交的代码引进的缺点，在代码查看时没能发现出来”就能够了，而是要用“五个为什么”的考虑技巧去深化发掘，终究得出一个更有含义的定论。比方下面的比方：
为什么会发作这样的问题？——> 缺点是由某次提交的有缺点的代码导致的。
为什么其他人没能发现这个问题？——> 代码查看者没注意到这样修正代码会导致这种问题。
为什么咱们彻底依托代码查看者来发现这样的问题？——> 由于咱们没有对这类用例的主动化测验。
为什么这类用例没做主动化测验？——> 由于没有测验账号的话，很难做测验。
为什么咱们没有测验账号？——> 由于现在的体系不支撑。
定论：现在咱们知道了原本过错的根本原因在于没有测验账号，因而会主张让体系支撑增加测验账号。做为进一步的跟进办法，要为将来一切相似的代码改动编写主动化测验用例。
作业回忆是往后总结的一个很重要的辅助东西。当许多团队都对往后总结做了很详尽的作业时，其他团队就会多了许多能够参阅的内容并从中获益，并会设法完结一些防备性改善。一个团队要让他人觉得很牢靠，他们提出的体系级改善办法要能得以推广，这一点很重要。
关于特别重视牢靠性的公司来说，特别严重的作业回忆都会由有阅历的工程师们进行查看，并对其间的要害点提出定见。公司级的技能办理层也要对改善办法加以推进，尤其是对耗时长、或许阻止其他作业进行的问题。强健的体系不是一天就能构建出来的，必定是经过继续改善渐渐迭代出来的。迭代来源于公司级的继续改善文明，要从作业中学到阅历。
05 毛病切换演习、有计划的停机、容量规划与黑盒测验
有许多日常活动都需求巨大的投入，但要想确保大型分布式体系的在线安稳运转，这样的投入又是至关重要的。我参加 Uber 公司之后才第一次遇到了这样的作业，由于我上任的上一家公司不管从规划仍是根底设施来说，都不需求咱们做这样的事。
我一向认为数据中心的毛病切换演习是件十分没含义的事，但亲身阅历了几回之后我的观念渐渐发作了改变。我一向认为，规划强健的分布式体系只需数据中心在失效时能快速康复就好了。已然规划好了，理论上也行得通，那还为什么要不断地定时测验呢？实际上答案与规划有关，并且也要测验在新的数据中心流量急剧增涨时，服务是否仍能高效地进行处理。
当切换发作时，我查询到的最常见的场景便是新数据中心的服务没有满意的资源来处理一切新涌入的流量。假设在两个数据中心里别离运转着 ServiceA 和 ServiceB，每个数据中心运转着几十上百个虚拟机，资源利用率是 60%，告警的阈值是 70%。
现在咱们做一次切换，把数据中心 A 的流量全都切到数据中心 B 去。在这种状况下假如不布置新的服务器，数据中心 B 必定处理不了这些流量。布置新服务器或许会需求很长时刻，因而恳求很快就会开端堆积，并被扔掉。这样的阻塞也会开端影响其他服务，导致其他体系的连续失效，而这些原本与这次切换并不相关。
数据中心毛病切换失利的或许示意图
其它或许的失利场景包含路由问题、网络容量问题、后端压力瓶颈等。一切牢靠的分布式体系都需求具有在不对用户体会形成任何影响的状况下进行数据中心切换的才能，因而也应该能够进行演习。在这儿我要着重“应该”，由于这样的演习是查验分布式体系网络牢靠性最有用的办法之一。
有计划的服务宕机演习是查验体系全体牢靠性的十分棒的办法，也是发现躲藏依托和对特定体系的不合理、非预期运用的好办法。关于面向用户、已知依托比较少的服务来说，做这样的操练相对简略。
但要害中心体系要求高在线时刻，或许被许多其他体系所依托，做这样的操练就没那么直观了。但假如某天这个中心体系真的就失效了，又会怎样呢？因而最好是用一次可控的演习来验证答案，一切的团队都要知道会有不可知的毛病发作，并且准备就绪。
黑盒测验用于查验体系的正确性，与终端用户的运用办法最为挨近。这种测验与端到端的测验很附近。除此之外，关于大多数产品来说恰当的黑盒测验能够确保他们的投入得到报答。要害的用户流程和最常见的用户界面测验用例，都是很好的挑选，能够让黑盒测验得以进行：用一种在任何时刻都或许被触发的办法来做黑盒测验，查验体系是否能够正常运转。
以 Uber 为例，一个很显着的黑盒测验用例便是在城市的范围内检测搭车者与司机的匹配是否正常。即在某个特定的城市里，搭车者经过 Uber 主张的恳求是否能得到司机的呼应，并完结一笔载客生意。当这个场景主动化之后，这个测验就能够在不同的城市定时模仿运转了。有了强健的黑盒测验体系就能够很简略地验证体系是否能够正常作业，最少是部分体系。黑盒测验关于毛病切换演习也很有用，是获取毛病切换状况的最快办法。
在一次毛病切换演习中进行黑盒测验的比方，毛病承认后手动进行回滚。横座标为时刻，纵座标为运转失利的用例数
对大型分布式体系来说，容量规划也差不多平等重要。我对大型分布式体系的界说是指那些每个月要开销几万乃至几十万美元的核算与存储体系。关于这样规划的体系来说，比较构建在云上的主动扩展计划，自建体系并进行固定数量的布置成本会更低些。
但自建体系至少要考虑当峰值流量到来时的主动扩展问题，确保对事务流量进行正常平稳的处理。另一个问题是，下个月至少应该运转多少个实例呢？下个季度呢？下一年呢？
关于老练并精心保存了历史数据的体系来说，对将来的流量进行猜测并非难事。其他一件重要的事便是预算，要挑选供货商并锁住云服务供给商的优惠扣头。假如你的服务开销很大，而你又疏忽了容量规划，那你就失去了一个十分简略的削减并操控开销的办法。
06 SLO、SLA 及相应的陈述
SLO 意味着服务等级方针（ Service Level Objective ），是体系可用性的一个数字化方针。好的实践是为每个独立的服务都界说服务等级方针 SLO，比方容量方针、推迟、准确度、可用性等。这些 SLO 能够用于触发告警。下面是一些服务等级方针的比方：
事务级 SLO 或功用级 SLO 是对上面这些服务的笼统。它们会包含直接影响用户或事务的方针。比方一个事务级方针能够这么界说：期望 99.99% 的邮件能够在一分钟之内承认发送成功。这个 SLO 也能够与服务级 SLO 相对应（比方付出体系和邮件接纳体系的推迟），也有或许会用其他办法去进行丈量。
服务等级协议（SLA，Service Level Agreement）是服务供给者与服务运用者之间更广泛的约好。一般来说，一个 SLA 会由多个 SLO 组成。比方，“付出体系 99.99% 可用”能够做为一个 SLA，它能够继续分解为各个支撑体系的特定 SLO。
界说了 SLO 之后，下一步便是对它们进行丈量并陈述。对 SLA 和 SLO 进行主动化的丈量和陈述，这是个杂乱的方针，会与工程和事务团队的优先级相冲突。工程团队不会感兴趣，由于他们现已有了各种不同级其他监控，能够实时地检测毛病。事务团队也不会感兴趣，他们更期望把精力用于提交功用，而不是用在一个不会很快发作事务影响的杂乱项目上。
这就谈到了另一个论题：现已或行将运营大型分布式体系的公司要为体系的牢靠性投入专门的团队。咱们谈谈站点牢靠性工程团队。
07 独立的 SRE 团队
站点牢靠性这个词大约在 2003 年出自谷歌，谷歌公司现在现已有了超越 1500 名 SRE 工程师。由于运营出产环境的使命越来越杂乱，越来越主动化，所以很快这就成了个全职作业。工程师们会渐渐地全职进行出产主动化：体系越要害，毛病也就越多，这件事就会越早发作。
快速生长的技能公司一般会比较早建立 SRE 团队，他们会有自己的演进道路。Uber 的 SRE 团队建立于 2015 年，使命是对体系杂乱度进行继续办理。其他公司在建立专门的 SRE 团队一起，也或许建立专门的根底设施团队。当一个公司的跨团队牢靠性作业需求占用多个工程师的时刻时，就能够考虑建立专门的团队做这件事了。
有了 SRE 团队，他们就会从运营的视点考虑，让运营大型分布式体系的作业变得更轻松。SRE 团队或许会有规范的监控和告警东西。他们或许会购买或自己构建值勤相关东西，能够为值勤的最佳实践供给主张。他们会为毛病回忆供给协助，会构建体系来让咱们更简略地检测、康复和防备毛病。他们也会主导毛病切换演习，推进黑盒测验，并参加容量规划。他们会驱动挑选、定制和构建规范东西，来界说和丈量 SLO，并进行上报。
不同的公司需求 SRE 团队处理不同的痛点，所以不同公司的 SRE 团队之间也很或许并不相同。它们的称号也经常会不同：或许会叫运营团队、途径工程团队或根底设施团队。关于站点牢靠性，谷歌免费发布了两本必读书，想深化了解 SRE 的话能够读一下。
08 把牢靠性做为继续投入
不管构建什么产品，完结第一版仅仅个开端。在第一版之后，新功用会经往后面的迭代不断参加。假如产品很成功，能够带来商业上的报答，迭代作业就会不断继续。
分布式体系也有相似的生命周期，并且需求不断地进行投入。不仅仅开发新功用，还要满意扩展的需求。当体系要承当更大的负载、存储更多数据、从事相关作业的工程师越来越多时，就需求继续重视，才能让它一向平稳地运转。许多第一次构建分布式体系的人都会把它想像成一辆车：投入运用后，只需求隔几个月做一次定时保养就能够了。从体系运转的视点来说这个比照行不通。
我更乐意把运营一个分布式体系所要花费的功夫类比成运营一个大型安排，比方一家医院。要让一家医院运营杰出，就要不断地做验证和查看（监控、告警、黑盒测验等）。
新职工和新设备会不断投入进来：对医院来说便是医师和护理等职工，以及新式医疗仪器之类的设备；对分布式体系来说便是参加新职工，上线新服务。跟着人和服务的数量不断增加，旧的干事办法开端变得不行高效：能够想像，城镇里边的小诊所和城市里的大医院运营办法必定是不同的。
由于要用更高效的办法干事，所以发作了全职作业，对功率的丈量和陈述也变得很重要。因而大型医院就会有更多的支撑型职工，比方财政、人力资源和安保；运营大型分布式体系也要依托根底设施、SRE 等支撑团队。
要让一个团队能够运营好一个牢靠的分布式体系，公司要对运营做继续投入，不仅仅这些体系自身，还有构建它们的途径。
09 深化阅览主张
虽然这篇文章的内容现已够长了，但它依然只谈到了皮裘罢了。要想深化了解怎样运营分布式体系，我引荐下面这些内容：
书
《SRE：Google 运维解密》：来自谷歌的十分棒而又免费的书。其间“监控分布式体系”一章的内容与本文密切相关。Cindy Sridharan 写的《分布式体系可观测性》：这是另一本十分棒的免费书，就监控分布式体系提出了许多十分好的观念。
Martin Kleppmann 博士写的《规划数据密集型使用》：这是迄今为止我所找到的讲分布式体系概念讲得最好的一本书。不过，关于本文内所评论的运营方面的内容，这本书评论得不多。
在线资源
Increment 杂志的值勤论题：这是一系列的文章，内容聚集于亚马逊、Dropbox、Facebook、谷歌和 Netflix 等公司的作业呼应流程。
学习构建分布式体系：这是亚马逊工程师 Marc Brooker 写的贴子，答复了“我该怎样学着构建大型分布式体系”的问题。
本文翻译自“ Operating a Large, Distributed System in a Reliable Way: Practices I Learned ”，翻译已取得原作者 Gergely Orosz 授权。原文链接：
https://blog.pragmaticengineer.com/operating-a-high-scale-distributed-system/
