湖南知青网2017锦绶堂_我在Uber运营大型分布式系统三年经验谈

知青文化 09-04 阅读:26 评论:0
湖南知青网2017锦绶堂_我在Uber运营大型分布式系统三年经验谈,

本文来自微信民众号:InfoQ(ID:infoqchina),作者:Gergely Orosz,译者:足下,谋划:蔡芳芳,题图:Photo by Dan Gold on Unsplash


Gergely 在 Uber 公司内担任付出体系的运营。他在这篇文章里分享了许多通用的履历,对运营大型分布式体系的要领给出了指点。


在过去的几年中,我一向在构建和运营大型分布式体系:Uber 的付出体系。在这段时候里,我学到了许多分布式架构的看法,也亲眼看到了高负荷高可用体系的构建和运营是何等富有应战性。就构建体系这件事来讲,它自身黑白常风趣的。要想象好当流量增添 10 倍 /100 倍时体系该如何处置惩罚,纵然硬件出毛病数据也要能耐久化保留等等,处理这些题目都能够让人有极大的收成。不过关于我个人来讲,运营一套大型分布式体系却更是使人大开眼界的阅历。


体系越大,墨菲定律“能够失足的事终将失足”就越实用。关于频仍举行体系布置、许多开辟者协同提交代码、数据疏散在多个数据中心、体系由环球海量用户配合运用如许的场景来讲,就更显著。在过去的几年中,我阅历过很屡次差别的体系毛病,许多都大大出乎我意料之外。从可预感的题目——如硬件毛病或不小心把有缺点的代码宣布到临盆体系,到衔接数据中心的网络光纤被铲断或多个级联毛病同时发作,很屡次毛病都让部份体系没法平常事变,因而致使了停服,终究形成了极大的营业影响。


这篇文章是我在 Uber 事变时期,关于如何牢靠地运营一套大型分布式体系的履历总结。我的履历会很具有普遍性,运营类似范围体系的人也会有类似的履历。我曾与谷歌、Facebook、Netflix 等公司的工程师们谈过,他们的履历和处理计划都很类似。不管体系是运转在自建数据中心(Uber 大多数状况下是如许的),照样运转在云端(Uber 的体系有时候会扩大到云端),只需体系范围类似,文章中的主意和流程就会实用。不过假如要把履历照搬到小型体系或非中心体系时就请三思而后行,由于极能够会矫枉过正。


详细来讲,我会谈到以下话题:


  • 监控


  • 值班、异常检测与告警


  • 停服与事宜治理流程


  • 预先总结、事宜回忆与延续革新的文明


  • 毛病切换演习、有想象的停机、容量想象与黑盒测试


  • SLO、SLA 及相应的报告


  • 自力的 SRE 团队


  • 对牢靠性做延续投入


  • 深切浏览提议


1.监控


要晓得体系是不是康健,我们就要回覆题目:“我的体系在平常事变吗?”要给出答案,起首就要网络关于体系症结部份的数据。关于运转在差别数据中心多台效劳器上,由多个差别效劳构成的分布式体系来讲,决议哪些症结目的须要被监控,这事原本就不轻易。


基本设施康健监控:假如一或多台效劳器、虚拟机负载太高,那分布式体系就会发作部份降级。效劳要运转在效劳器上,所以像 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 的可观察性手艺栈为基本,努力地为自身定制这类监控。


2.值班、异常检测与告警


监控能够让人们检察体系的当前状况,是个异常有用的东西。然则,要在体系发作毛病时自动检测而且发出告警,让人们能够采用相应地行为,监控只是第一步。


值班就是一个更广的话题了:Increment 杂志在这方面做得很棒,对值班题目举行了许多方面的议论。我迥殊倾向于把值班做为“谁构建,谁担任”思绪的一个扩大。哪一个团队构建了效劳,那就由哪一个团队担任值班。我们团队就担任自身构建的付出效劳的值班。因而不管什么时候发作了告警,值班工程师都邑相应并对题目举行处置惩罚。我们该如何从监控得出正告呢?


从监控数据中发明异常,这是一个庞大的应战,也是机械进修的用武之地。有许多第三方效劳能够供应异常检测功用。而且关于我们团队来讲很荣幸,我们公司就有机械进修团队能够为我们供应支持,他们特地想象了合适 Uber 用例的处理计划。位于纽约的可观察性团队还就 Uber 如何做异常检测这个主题写过一篇很不错的文章。从我们团队的角度看,我们会把我们的监控数据推送到他们的管道中,并收到差别信托水平的告警,然后我们再决议要不要自动呼唤某位工程师。


什么时候发出告警也是个很值得议论的题目。告警太少能够意味着错过处置惩罚某些严重毛病的机遇,告警太多的话值班工程师就无觉可睡了,毕竟人的精神是有限的。因而对告警举行跟踪并分类,并丈量信噪比,这对调治告警体系异常主要。对告警信息举行搜检,并标记是不是须要采用相应的行动,不停削减不须要的告警,这就迈出了异常好的一步,让可延续性的值班行为处于良性循环了。


Uber 内部运用的值班仪表盘例子,由位于维尔纽斯的 Uber 开辟者体验团队构建


Uber 位于维尔纽斯的开辟者东西团队开辟了特地的值班东西,用于对告警举行注解,并对轮班举行可视化。我们团队每周都邑对上一周的值班状况举行回忆,剖析痛点,并花时候进步值班体验。这件事每周都邑做。


3.停服与事宜治理流程


想象一下,这周由你值班。半夜里来了个电话告警,你就要观察一下是不是发作了停服,是不是会影响临盆。效果看到体系真的有一部份失效了,谢天谢地,监控和告警确实回响反映了体系的真实状况。


关于小型体系来讲,停服不算什么大贫苦,值班工程师能够推断动身作了什么,以及为何发作。平常来讲他们都能够很快推断题目,并举行处理。而关于运用了多种效劳或微效劳的庞杂体系来讲,许多工程师都在向临盆提交着代码,因而推断动身作毛病的根本缘由,这就有相当大的难度了。在这类状况下,假如有些规范的处置惩罚流程,事变就会轻易很多。


把运转手册附加到告警信息中,形貌一下简朴的处置惩罚步骤,这就是第一层防地。假如团队的手册写得异常好,那末纵然值班工程师对体系明白得并不深切,这平常也不会是什么题目。手册要不停更新,当涌现新的毛病范例时要尽快举行订正。


当效劳由多个部门配合构建时,在部门之间沟通毛病也很主要。在我们公司里,几千个工程师配合事变,他们会自身遴选自以为适宜的机遇将效劳布置到临盆环境,因而现实上每一个小时都邑发作几百次布置。对一个效劳的布置能够会影响另一个看起来压根不相干的效劳。因而,是不是有清楚规范的毛病播送和沟通渠道就成了毛病顺遂处理的症结。曾发作过好几个案例,告警看起来与我之前见过的好像一点关联都没有,幸亏我想起来别的团队中有些同事曾见过类似的离奇题目。在一个大的毛病处置惩罚群中,我们一同很快就定位出了根本缘由并处理掉了。做为一个团队来处置惩罚题目,总会比单个履历丰富的员工快很多。


马上恢复临盆,预先观察缘由。在处置惩罚毛病的历程当中,我也经常会“肾上腺素激增”,想要直接把题目就地处理掉。平常来讲毛病都是由某次新布置的代码致使的,变动的代码中会有某些很显著的毛病。在之前我平常不会回滚代码,而是直接去修正代码并宣布新版本。但现实上一边临盆的毛病没有处理,另一边却去修正代码中的缺点,这着实不是个好主意,这么做收益很小,丧失却很大。由于新的修复代码必需尽快完成,那就只能在临盆环境举行测试,这么做反而越发轻易引入新的缺点,以至旧的毛病还没处理,新的题目又涌现了。我也曾见过类似缘由致使的一连串的毛病。因而请一定记着,要先恢复临盆,反抗住马上修复或观察根本缘由的引诱。现实上第二天返来上班再仔细观察根本缘由也未尝不可。


4.预先总结、事宜回忆与延续革新的文明


这里讲的是一个团队如何举行毛病的后续处置惩罚。他们会继承做观察吗?他们会不会停下手头一切与临盆有关的事变,消费惊人的价值来做一次体系级的修复?


预先总结是构建硬朗体系的基石。好的预先总结黑白常仔细和无可抉剔的。Uber 的预先总结模板已跟着时候的推移而演进好多个版本了,内容包含许多小节,有事宜总结、也许影响、事宜发作历程的症结时候点、根本缘由剖析、履历总结及一系列的后续跟进内容。


一个与我在 Uber 运用的预先总结模板类似的例子


好的预先总结会对毛病根本缘由举行深切发掘,取得革新步伐来防止类似的毛病发作,或许鄙人一次涌现类似毛病时能够疾速检测和恢复。我说的深切发掘,不是说浅尝辄止地晓得“此次毛病的缘由是近来提交的代码引入的缺点,在代码检察时没能发明出来”就可以够了,而是要用“五个为何”的思索技能去深切发掘,终究得出一个更有意义的结论。比方下面的例子:


  • 为何会发作如许的题目?——> 缺点是由某次提交的有缺点的代码致使的。


  • 为何其他人没能发明这个题目?——> 代码检察者没注意到如许修正代码会致使这类题目。

    哪里有过度的鸡娃,哪里就没有娃


  • 为何我们完整依托代码检察者来发明如许的题目?——> 由于我们没有对这类用例的自动化测试。


  • 为何这类用例没做自动化测试?——> 由于没有测试账号的话,很难做测试。


  • 为何我们没有测试账号?——> 由于如今的体系不支持。


  • 结论:如今我们晓得了本来毛病的根本缘由在于没有测试账号,因而会提议让体系支持增加测试账号。做为进一步的跟进步伐,要为未来一切类似的代码修改编写自动化测试用例。


事宜回忆是预先总结的一个很主要的辅助东西。当许多团队都对预先总结做了很仔细的事变时,其他团队就会多了许多能够参考的内容并从中受益,并会想法完成一些防备性革新。一个团队要让他人觉得很牢靠,他们提出的体系级革新步伐要能得以履行,这一点很主要。


关于迥殊关注牢靠性的公司来讲,迥殊严重的事宜回忆都邑由有履历的工程师们举行检察,并对个中的症结点提出看法。公司级的手艺治理层也要对革新步伐加以推进,尤其是对耗时长、能够障碍其他事变举行的题目。硬朗的体系不是一天就可以构建出来的,一定是经由延续革新逐步迭代出来的。迭代来源于公司级的延续革新文明,要处置宜中学到履历。


5.毛病切换演习、有想象的停机、容量想象与黑盒测试


有许多一样平常运动都须要庞大的投入,但要想保证大型分布式体系的在线稳固运转,如许的投入又是至关主要的。我到场 Uber 公司以后才第一次遇到了如许的事变,由于我就任的上一家公司不管从范围照样基本设施来讲,都不须要我们做如许的事。


我一向以为数据中心的毛病切换演习是件异常没意义的事,但亲身阅历了频频以后我的看法逐步发作了变化。我一向以为,想象硬朗的分布式体系只需数据中心在失效时能疾速恢复就好了。既然想象好了,理论上也行得通,那还为何要不停地按期尝试呢?实际上答案与范围有关,而且也要测试在新的数据中心流量急剧增涨时,效劳是不是仍能高效地举行处置惩罚。


当切换发作时,我视察到的最常见的场景就是新数据中心的效劳没有充足的资本来处置惩罚一切新涌入的流量。假设在两个数据中心里离别运转着 ServiceA 和 ServiceB,每一个数据中心运转着几十上百个虚拟机,资本利用率是 60%,告警的阈值是 70%。如今我们做一次切换,把数据中心 A 的流量全都切到数据中心 B 去。在这类状况下假如不布置新的效劳器,数据中心 B 一定处置惩罚不了这些流量。布置新效劳器能够会须要很长时候,因而请求很快就会最先聚集,并被扬弃。如许的梗塞也会最先影响别的效劳,致使其他体系的接连失效,而这些原本与此次切换并不相干。


数据中心毛病切换失利的能够示意图


别的能够的失利场景包含路由题目、网络容量题目、后端压力瓶颈等。一切牢靠的分布式体系都须要具有在不对用户体验形成任何影响的状况下举行数据中心切换的才能,因而也应当能够举行演习。在这里我要强调“应当”,由于如许的演习是磨练分布式体系网络牢靠性最有用的要领之一。


有想象的效劳宕机演习是磨练体系团体牢靠性的异常棒的要领,也是发明隐蔽依托和对特定体系的不合理、非预期运用的好要领。关于面向用户、已知依托比较少的效劳来讲,做如许的演习相对简朴。但症结中心体系请求高在线时候,或许被许多其他体系所依托,做如许的演习就没那末直观了。但假如某天这个中心体系真的就失效了,又会如何呢?因而最好是用一次可控的演习来考证答案,一切的团队都要晓得会有不可知的毛病发作,而且准备就绪。


黑盒测试用于磨练体系的准确性,与终端用户的运用体式格局最为靠近。这类测试与端到端的测试很邻近。除此之外,关于大多数产物来讲适当的黑盒测试能够确保他们的投入取得报答。症结的用户流程和最常见的用户界面测试用例,都是很好的遴选,能够让黑盒测试得以举行:用一种在任何时候都能够被触发的体式格局来做黑盒测试,磨练体系是不是能够平常运转。


以 Uber 为例,一个很显著的黑盒测试用例就是在都市的范围内检测搭车者与司机的婚配是不是平常。即在某个特定的都市里,搭车者经由过程 Uber 提议的请求是不是能取得司机的相应,并完成一笔载客买卖。当这个场景自动化以后,这个测试就可以够在差别的都市按期模仿运转了。有了硬朗的黑盒测试体系就可以够很轻易地考证体系是不是能够平常事变,最少是部份体系。黑盒测试关于毛病切换演习也很有用,是猎取毛病切换状况的最快体式格局。


在一次毛病切换演习中举行黑盒测试的例子,毛病确认后手动举行回滚。横座标为时候,纵座标为运转失利的用例数


对大型分布式体系来讲,容量想象也差不多一致主要。我对大型分布式体系的定义是指那些每月要付出几万以至几十万美元的盘算与存储体系。关于如许范围的体系来讲,比拟构建在云上的自动扩大计划,自建体系并举行牢固数目的布置成本会更低些。但自建体系最少要斟酌当峰值流量到来时的自动扩大题目,保证对营业流量举行平常安稳的处置惩罚。另一个题目是,下个月最少应当运转多少个实例呢?下个季度呢?下一年呢?


关于成熟并经心保留了历史数据的体系来讲,对未来的流量举行展望并不是难事。别的一件主要的事就是预算,要遴选供应商并锁住云效劳供应商的优惠折扣。假如你的效劳付出很大,而你又疏忽了容量想象,那你就错失了一个异常简朴的削减并掌握付出的要领。


6.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 举行自动化的丈量和报告,这是个庞杂的目的,会与工程和营业团队的优先级相冲突。工程团队不会感兴趣,由于他们已有了种种差别级别的监控,能够及时地检测毛病。营业团队也不会感兴趣,他们更愿望把精神用于提交功用,而不是用在一个不会很快发生营业影响的庞杂项目上。


这就谈到了另一个话题:已或行将运营大型分布式体系的公司要为体系的牢靠性投入特地的团队。我们谈谈站点牢靠性工程团队。


7.自力的 SRE 团队


站点牢靠性这个词也许在 2003 年出自谷歌,谷歌公司如今已有了凌驾 1500 名 SRE 工程师。由于运营临盆环境的使命愈来愈庞杂,愈来愈自动化,所以很快这就成了个全职事变。工程师们会逐步地全职举行临盆自动化:体系越症结,毛病也就越多,这件事就会越早发作。


疾速生长的手艺公司平常会比较早建立 SRE 团队,他们会有自身的演进线路。Uber 的 SRE 团队建立于 2015 年,使命是对体系庞杂度举行延续治理。别的公司在建立特地的 SRE 团队同时,也能够建立特地的基本设施团队。当一个公司的跨团队牢靠性事变须要占用多个工程师的时候时,就可以够斟酌建立特地的团队做这件事了。


有了 SRE 团队,他们就会从运营的角度斟酌,让运营大型分布式体系的事变变得更轻松。SRE 团队能够会有规范的监控和告警东西。他们能够会购置或自身构建值班相干东西,能够为值班的最好实践供应提议。他们会为毛病回忆供应协助,会构建体系来让人人更轻易地检测、恢复和防备毛病。他们也会主导毛病切换演习,推进黑盒测试,并介入容量想象。他们会驱动遴选、定制和构建规范东西,来定义和丈量 SLO,并举行上报。


差别的公司须要 SRE 团队处理差别的痛点,所以差别公司的 SRE 团队之间也极能够并不相同。它们的称号也经常会差别:能够会叫运营团队、平台工程团队或基本设施团队。关于站点牢靠性,谷歌免费宣布了两本必念书,想深切相识 SRE 的话能够读一下。


8.把牢靠性做为延续投入


不管构建什么产物,完成初版只是个最先。在初版以后,新功用会经由过程后面的迭代不停到场。假如产物很胜利,能够带来贸易上的报答,迭代事变就会不停继承。


分布式体系也有类似的生命周期,而且须要不停地举行投入。不只是开辟新功用,还要满足扩大的需求。当体系要负担更大的负载、存储更多数据、处置相干事变的工程师愈来愈多时,就须要延续关注,才能让它一向安稳地运转。许多第一次构建分布式体系的人都邑把它想像成一辆车:投入运用后,只须要隔几个月做一次按期保养就可以够了。从体系运转的角度来讲这个对照行不通。


我更情愿把运营一个分布式体系所要消费的工夫类比成运营一个大型构造,比方一家病院。要让一家病院运营优越,就要不停地做考证和搜检(监控、告警、黑盒测试等)。新员工和新装备会不停投入进来:对病院来讲就是大夫和护士等员工,以及新型医疗仪器之类的装备;对分布式体系来讲就是到场新员工,上线新效劳。跟着人和效劳的数目不停增进,旧的干事体式格局最先变得不够高效:能够想像,乡镇内里的小诊所和都市里的大病院运营体式格局一定是差别的。由于要用更高效的体式格局干事,所以发生了全职事变,对效力的丈量和报告也变得很主要。因而大型病院就会有更多的支持型员工,比方财务、人力资本和安保;运营大型分布式体系也要依托基本设施、SRE 等支持团队。


要让一个团队能够运营好一个牢靠的分布式体系,公司要对运营做延续投入,不只是这些体系自身,另有构建它们的平台。


9.深切浏览提议


只管这篇文章的内容已够长了,但它依然只谈到了外相罢了。要想深切明白如何运营分布式体系,我引荐下面这些内容:



《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/


本文来自微信民众号:InfoQ(ID:infoqchina),作者:Gergely Orosz,译者:足下,谋划:蔡芳芳

版权声明

本文仅代表作者观点,不代表百度立场。
本文系作者授权百度百家发表,未经许可,不得转载。