BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Uber的SRE实践

| 作者 郭蕾 关注 9 他的粉丝 发布于 2017年9月5日. 估计阅读时间: 9 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

SRE(Site Reliability Engineering)代表了一套先进的、完整的运维体系,它最早由Google提出,希望能用软件工程的方式来解决运维工作中的难题。Google从2003年开始逐步试验SRE理念,到现在已经有10多年时间,而当初的那个团队也从几个人发展壮大到了几千人,他们保障了整个Google服务的稳定性。由于Google在SRE团队探索上的成功,后来各大互联网公司争相效仿,希望能够通过增加这样的角色和相关的工程实践来保障服务的可用性。

近几年,Uber成为了硅谷的一颗耀眼之星,它的全球业务呈现了爆发式增长,现在已经覆盖超过570个城市。在高速发展的同时如何保障全球服务的稳定性成为了Uber需要攻克的难题,而这其中SRE部门起着举足轻重的作用,因为他们是守护系统稳定的最后一道防线。为了了解Uber内部的SRE实践体系,InfoQ记者采访了Uber SRE存储部门高级工程师孟飞。另外,孟飞也将会在9月10日举行的CNUTCon全球运维技术大会上分享相关话题,欢迎关注。

InfoQ:你是如何理解SRE的?

孟飞:SRE全称Site Reliability Engineer。就像字面本身意思所述,SRE是一种特殊的软件工程师,专注于开发和测试软件稳定性、运行性能、容量、有效性、可维护性以及可扩展性。通常来说,SRE负责系统里面所有非功能性特性的部分,并且要把软件开发技术运用到这些部分。

SRE和DevOps的相同点是他们都专注于提高系统的稳定性;最大的不同在于SRE是软件工程师的一个分支而DevOps则是更多专注在运维。

InfoQ:Uber是如何实践SRE的?

孟飞:Uber的SRE负责保证全公司所有服务和业务的连续性和扩展性。SRE团队实时创建、维护、诊断和修复系统中的应用和服务。同时,SRE会参与到研发和运营下层的开发部署系统,比如Uber内部的部署系统uDeploy就有很多SRE的参与。SRE在Uber的业务中起到了至关重要的作用。

在整个开发周期里面,SRE同时扮演很多种角色。首先SRE会帮助开发和测试系统架构,自动发布软件到线上系统。之后SRE会帮助实时监控和测量系统运行状态来帮助开发人员了解自己软件的运行状态。最后当系统出现问题的时候,SRE会和开发一起处理异常,异常结束后还会和开发人员一起总结事故原因,一起写总结报告。根据事故原因对开发流程或者软件提出建议来提高稳定性、扩展性、性能和有效性。SRE是端到端的产品的维护者和守护者,对整个服务负责。

InfoQ:你认为SRE应该是单一的团队还是多个团队?

孟飞:SRE的形态取决于整个业务和产品所在的状态。当公司只是一个核心产品而且比较小的时候,开发团队往往同时扮演SRE团队的角色,而且开发团队往往也运营所有的基础架构服务。当产品增长,架构开始变复杂的时候,SRE的角色和负责的工作也发生了相应的变化。

Uber的工程部门现在主要是分为两部分:基础事业部主要负责提高基础设施的提高(比如计算存储);工程产品事业部则和各个产品部门紧密工作。SRE也同样分为两部分,和基础事业部协作的基础SRE以及和产品事业部协作的产品SRE。在这两个SRE部门下面又会有小的团队专注在不同的技术或者产品上面。比如,在产品SRE部门里面,一个小组会负责同时和多个有类似技术栈的产品组一起工作。基础SRE事业部也会分成多个包括计算、存储、数据的不同小组。本质上SRE团队是负责在公司已有产品软件上层开发稳定性的部分来保证整个产品按照需求运行。

InfoQ:谈谈Uber落地SRE的技术栈以及技术架构?

孟飞Uber的SRE技术栈使用Puppet来管理服务器和最基础的服务。对于有状态需求的基础软件,Uber集成了ZooKeeper、ClustoCollins来存储相关的元数据和关系。现在Uber正在将这些基础软件管理部分迁移到集群管理软件Apache Mesos上面。Uber内部自研了自己的部署系统uDeploy来适应Uber的快速增长。在这些基础软件上层,所有的业务都是通过微服务来部署的。详细的Uber技术栈可以参考我们的博客Uber工程栈一以及Uber工程栈二

InfoQ:有人说监控是SRE眼睛的延伸,可否谈谈你对监控这件事情的理解?在处理系统监控这件事情上,你认为有哪些关键点?

孟飞:实时监控是SRE最为核心和关键的部分之一。为了满足Uber的快速增长和需求变化,Uber开发了一整套监控系统给全公司的服务器和微服务使用。所有的服务都可以调用监控系统来监控自己的各种状态,用户可以根据自己的需求设置不同的监控警报。当系统监控到异常时监控系统会及时通知工程师来处理。

根据我自己的经验,监控系统最最重要的是它的实时性。所以监控系统面临的很大问题在于要支持业务的爆发时增长,如何设计一个可以扩展的架构来保证监控的实时性。监控另外很重要的要求是可以很好的集成已有的开源监控解决方案,重用已经存在的监控,毕竟很多模块和软件本身就是开源项目。

InfoQ:实践了这么长时间的SRE理念,有什么可以和读者分享的吗?或者有哪些你认为可以绕开的坑?

孟飞:我觉得SRE理念最最重要的还是一点,SRE本身是工程师,是在用软件工程的方法来解决稳定性问题。碰到新的基础服务问题的时候, SRE会或者说要从软件工程的角度去解决而不是采用运维的角度去解决。这样的结局方案在快速增长的环境里面才是可以扩展的。

出去对于SRE理念的基本理解,我觉得最大的坑有以下几点:

  • SRE不是DevOps。在很多工程部门以及产品部门,这一点非常容易被忽略。尤其是当有新产品发布的压力下,SRE很多时候会被错误的当作DevOps使用。这对于SRE部门的健康有机发展是非常不利的。SRE部门应该像其他所有工程部门一样要做季度、半年或者一年的计划。在Uber内部,我们会分配30%的SRE时间给计划外的工作:包括oncall,其他不同部门的运维任务。剩下的70%时间SRE会专注在基于我们产品或者基础软件上层的稳定性软件的开发。如果我们发现SRE花了超过30%的时间用来做计划外的工作,我们会来检查是不是我们的产品和基础软件开发出现了问题进而进行调整。在任何情况下我们不应该使用超过SRE 30%的时间来运维。

  • SRE部门应该和其他所有工程部门一样有机增长和发展。在Uber的不同阶段,我们可能需要不同形式规模的SRE团队来负责产品的稳定。比如说当我们的服务增长到上千的时候,我们开始把产品SRE团队整合成为不同的几个大类来减少重复工作。

  • 由于SRE对工程师的要求是同时具有软件开发和系统背景,比起直接从公司外面招SRE,很多时候从内部的软件工程师队伍里面发展SRE更为自然和容易一些。我们内部也看到更多从软件开发部门转过来的工程师,然后在SRE部门做更多的训练。

InfoQ:在CNUTCon全球运维技术大会上,你将会为大家分享哪些内容?

孟飞:在这次的CNUTCon2017上面,我会分享Uber的SRE部门是如何适应我们快速增长的微服务架构。同时我还会和各位同仁讨论Uber SRE使用自动化的的监控来帮助全公司维护系统和微服务。最后我还会简单介绍我们是如何从一个数据中心到两个双活数据中心的历程,以及将来我们全球多活的计划。

从2009年成立至今,Uber全球业务爆发式增长,现在已经覆盖全球超过633座城市,业务也已经涵盖汽车共享UberX/UberPool,外卖服务Uber Eats,卡车运输协调Uber Freight,无人驾驶Uber ATG等等。前端业务对后台基础infrastructure的需求强劲而且变化快,数据中心一直处于爆发式增长。如何为超过2000个微服务以及无人车提供稳定可靠高性能的计算存储支持是整个Infrastructure部门的工作重心,而其中SRE部门又是守护系统稳定的最后一道防线。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

InfoQ需要提高一下文章门槛 by Chen Andy

"最大的不同在于SRE是软件工程师的一个分支而DevOps则是更多专注在运维" -- 后面就不用看了。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT