Uber的SRE实践
极客时间编辑部
讲述：丁婵大小：2.02M时长：04:25
近几年，Uber 成为硅谷的一颗耀眼之星，它的全球业务呈现了爆发式增长，现在已经覆盖超过 570 个城市。在高速发展的同时，如何保障全球服务的稳定性成了 Uber 需要攻克的难题，而这其中 SRE 部门起着举足轻重的作用，他们是守护系统稳定的最后一道防线。
为了解 Uber 内部的 SRE 实践体系，近日，InfoQ 记者采访了 Uber SRE 存储部门高级工程师孟飞。
提到对 SRE 的理解，孟飞认为 SRE 是一种特殊的软件工程师，专注于开发和测试软件稳定性、运行性能、容量、有效性、可维护性以及可扩展性等。通常来说，SRE 会负责系统里面所有非功能性特性的部分，并且要把软件开发技术运用到这些部分。
SRE 和 DevOps 的相同点是他们都专注于提高系统的稳定性，最大的不同在于 SRE 是软件工程师的一个分支，而 DevOps 则更多的专注在运维。
具体到 Uber 的 SRE 实践，孟飞表示，Uber 的 SRE 负责保证全公司所有服务和业务的连续性和扩展性，SRE 团队需要实时创建、维护、诊断和修复系统中的应用和服务。同时，SRE 会参与到研发运营具体的开发部署系统中，比如 Uber 内部的部署系统 uDeploy 中就有很多 SRE 的参与。SRE 在 Uber 的业务中起到了至关重要的作用。
在 Uber 的整个开发周期中，SRE 同时扮演着很多种角色。首先，SRE 会帮助开发和测试系统架构，自动发布软件到线上系统。之后，SRE 会帮助实时监控和测量系统运行状态，来帮助开发人员了解自己软件的运行状态。最后，当系统出现问题时，SRE 会和开发人员一起处理异常、总结事故原因、撰写总结报告，还会根据事故原因对开发流程或者软件提出建议，来提高稳定性、扩展性、性能和有效性。SRE 是端到端的产品的维护者和守护者，对整个服务负责。
对于 SRE 理念的实践，孟飞总结了他们踩过的三个坑。
首先，SRE 不是 DevOps。这一点非常容易被忽略，尤其是当有新产品发布的压力下，SRE 很多时候会被错误的当作 DevOps 使用。这对于 SRE 部门的健康有机发展是非常不利的。
SRE 部门应该像其他所有工程部门一样做季度、半年或者年度的计划。在 Uber 内部，SRE 会分配 30% 的时间给计划外的工作，比如 oncall，或其他不同部门的运维任务等。剩下的 70% 时间，SRE 会专注在基于产品或基础软件上层的稳定性软件的开发。
如果 Uber 发现 SRE 花了超过 30% 的时间来做计划外的工作，就会反思是不是产品和基础软件开发出现了问题，进而进行调整。在任何情况下，Uber 都认为不应该使用超过 SRE 30% 的时间来运维。
其次，SRE 部门应该和其他所有工程部门一样有机增长和发展。在 Uber 的不同阶段，Uber 可能需要不同形式规模的 SRE 团队来负责产品的稳定。比如说当服务增长到几千个的时候，Uber 就开始把产品 SRE 团队整合成为不同的几个大类来减少重复工作。
最后，由于 SRE 要求工程师同时具有软件开发和系统背景，比起直接从公司外招聘，很多时候，从内部软件工程师队伍中发展会更为自然和容易一些。Uber 也是如此，内部有很多 SRE 工程师是从软件开发部门转过来，然后在 SRE 部门接受更多的训练。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
limix感觉SRE这个岗位的职责解决的场景需求比较明确, 对软件的可靠稳定性负责
收起评论