Uber 的 SRE 实践

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、 Clusto 和 Collins 来存储相关的元数据和关系。现在 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 部门又是守护系统稳定的最后一道防线。