第 7 章 没有 SRE 的 SRE:Spotify 案例研究
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
许多人对 Spotify 实际上没有 SRE 组织感到惊讶。我们没有中央 SRE 团队,甚至没有 SRE 专属团队,然而我们长期以来的扩展能力一直取决于我们在一切工作中应用 SRE 原则的能力。鉴于这种不寻常的设置,其他公司纷纷向我们了解我们的模式("Ops-in-Squads")是如何运作的。有些公司也采用了类似的模式。让我们向您介绍一下我们是如何采用这种模式的,以及这种模式是如何为我们工作的,以便您了解类似的想法是否适合您。
首先,我们需要介绍一下我们的工程文化:在 Spotify,我们组织成小型自治团队。我们的理念是,每个团队从头到尾都拥有某项功能或用户体验。在实践中,这意味着一个工程团队由一组跨职能的开发人员组成--从设计师到后端开发人员再到数据科学家--共同致力于 Spotify 的各种客户端、后端服务和数据管道。
为了支持我们的功能团队,我们创建了以基础设施为中心的小组。这些基础架构团队反过来也变成了小型、跨职能和自主的团队,以提供自助式基础架构产品。其中的一些例子包括持续集成、部署、监控、软件框架和指南。Spotify 的绝大多数 SRE 都在这些团队中工作,他们利用自己的技能和经验使生产环境可靠、可扩展性强,并且便于我们的功能团队使用。
然而,SRE 的某些关注点是跨领域的,只能从中央角度解决。这包括大型连环故障造成的中断、教授部署、事件管理或事后分析的最佳实践。我们的 SRE 将自己组织在全公司的工作组中,但这些工作组并不完全是拥有 SRE 头衔的工程师。例如,在我们的中央升级待命轮换(内部称为 "事件经理待命 "或 "IMOC")中,只有一半的工程师是 SRE,其余的都是担任各种角色的工程师。
我们为什么要这样组织自己?这样做的好处是什么?在下面的章节中,我们将讨论 Spotify 是如何将 SRE 组织从一家在斯德哥尔摩公寓中安装服务器的小型初创公司发展成为今天的大型全球性公司的。我们将重点介绍 Spotify 如何通过提供无摩擦的开发环境以及信任和知识共享的文化,使所有工程师都将运营视为默认工作。
Tabula Rasa:2006-2007 年
前奏
我们将谈一谈我们是如何开始在早期历史中纳入运营重点的,其中包括:
- 默认运营
从一开始就无意中引入运营重点,这影响了我们的工程文化,并在未来证明是有益的。
- 学会在失败中迭代器
虽然我们在运营方面有先见之明,但我们也不免会陷入初创公司常见的陷阱。
关于 Spotify 运营和 SRE 的故事,其中一个令人好奇的地方是,这家六人公司最初的人员配置中如何包括一名运营工程师。
许多初创公司都是在第一批客户开始使用服务后才增加一名运营人员。然后,这位不幸的运营工程师可能会发现,后端由于脚本没有记录、服务在屏幕会话中运行、缺乏备份、单点故障以及层层未完成的良好愿望而步履维艰。从这一点上看,运营工程师可能会一直处于追赶状态,既要努力灭火,又要跟上新的发展。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access