DevOps @ Spotify

本文是“ DevOps 每月实战故事”系列的一部分。每个月我们都会听听来自不同团队的 DevOps 故事，了解哪些对我们有用，哪那些没有用，并且描绘出 DevOps 实施过程中所面对的挑战。

将 DevOps 的经验用于管理

互联网上有许多关于 DevOps 的博客帖子、文章和微博。有些讨论他们好与坏，有些则是讨论引入 DevOps 后带来了那些影响，还有一些则是在讨论如何实施。

尽管这篇文章提到了一些 DevOps 的通用性的方面，但其主要侧重点是将 DevOps 做事的原则应用到另一个领域：工程领导力。

文中我会时不时用到“我们”这个词，为避免混淆，在这里做一个快速介绍：

• Ingrid Franck：工程师团队的敏捷教练
• Ramon van Alteren：工程师团队的产品负责人（产品经理）
• Mattias Jansson（也就是我）：工程师团队的部门领导，即在这篇文章中提到的团队领导

截止本文成文时，文中所涉及的 Spotify 工程师团队有九个成员。

Spotify 的 DevOps 文化

在 Spotify 创立之初，DevOps 文化的许多方面就在部门快速弥漫着。

Spotif 创业初期雇佣了 6 名员工，他们都是工程师，其中一名还担任过操作员角色。那个时候 Spotify 团队刚刚在一间公寓成立，这些人支撑着整个公司。在这样的背景下，Spotify 初期团队对业务重要性的认知深刻影响了运维和开发之间的关系。

我们在经历漫长的道路之后，Spotify 现在发展到数百名工程师，分布在全国三个时区的四个城市当中。尽管 DevOps 的思想无法渗透到工程师团队每个工程师的心灵和灵魂当中，实际上我们也没有在任何地方提及过，但你会在日复一日工作中发现它无处不在，甚至包括你的茶歇时的闲聊时光。

创业公司大多由开发者和商业怪人组合而成。在这些公司里，一般都是开发者写完了代码，需要有人部署维护这些代码的时候，才会招聘一个运维去支持工程师。在 Spotify 开发和运维这两个阵营是高度重合的，他们在职责、技能和兴趣上是非常相近的。我们有一些运维能力超强的开发者，也有很多运维工程师具有很强的开发背景。拥有这些优秀的工程师所带来的巨大优势在于解决日复一日的，在问题还早在萌芽阶段时就将期摘除。

后端开发工程师自已在生产环境中部署他们的代码，不是所有的时候都需要去给工程师帮忙才能完成部署。当后端开发工程师被赋予这样的权限时，开发者反而会更加认真的思考那些传统上由运维承担的工作，包括监控、日志、包管理和可用性。

由于我们生产环境的服务器已经有数千规模，运维工程师更多的时候已经不用关心单机，而是集群。工程师会避免在单台服务器进行一次手工部署，而是尽可能在我们的配置管理系统（基于 Puppet）的支撑下，通过修改后端模块的数据状态将变更应用至线上服务器。

后端服务通常有所谓的两个系统拥有者：一个是开发 (Dev)，一个是运维 (Ops)。他们的核心职责都位于各自擅长的领域。开发工程师掌管代码、设计和架构；运维工程师掌管着服务——他们将服务部署上线，引入流量，向服务注入生命。然而，这两个系统又有着极大的重叠，因此这两个系统的拥有者——开发和运维，会定期讨论架构的可扩展性，后台拓扑架构的改变，即将上线的新产品将会怎样影响服务行为等等。

我们有一个专门专注于自动化工具和服务的团队，有时开发和运维会花几个星期的时间聚集在一起工作来解决具体的问题，Ops 自已提出并优先解决这些问题。

尽管做了上述这么多事情，我们团队仍然还有很长的路要走。客户、服务器、数据中心、服务、办公室、工作人员的人数都在不断增长，因此，曾经的解决方案不一定适应现在的发展，并且过去的解决方案制约了现在对可扩展性的需求。在此基础上，Dev 之于 Ops 职员比例的变化，在一定程度上的冲淡了 DevOps 在某此方面的心态。

从 DevOps 当中学到的

DevOps 教会了我们很多东西，但是其中最重要的是教会了我们如何协调开发和运维的目标。让他们共同协作，给他们提供互相学习的空间。通过两组定期沟通，开发者将有机会理解并思考为什么有时运维需要扮演阻碍者（绊脚石）的角色，学习如何提前计划在生产环境改变时调整操作环境所必备的要求。同时，一旦运维开始意识到他们的硬件和服务并非一成不变，而是一个可以用代码重塑的数据结构，那么开发者也会以不同的方式对待系统：他关心的不再仅仅是软件包中的代码，还关心将软件包部署到生产环境的过程是否足够灵活。

同样地，将这种操作思想注入到开发过程中可以有效地降低运维工程师在被打断和清理工作时间上的频率，保证他们有更多的时间投入长期的项目中。

总的来说，DevOps 的工作方式已经改变了团队中的开发和运维双方对整个系统的看法，以及价值观的认可，而不仅仅是传统意义上的对各自的职位负责。

管理上的问题

在很多现代高科技公司，人们可以发现这些公司都具有三个不同职责的工程师团队。在一些规模较小——以及部分规模较大的公司中，这些职责通常都集中在一个或两个角色上。在 Spotify，我们尝试将他们分开，让三种不同的角色拥有不同的职责。那么，什么样的角色应该对应什么职责呢？

• 产品经理负责及时将产品交付给一个或多个利益相关者。(PO= Product owner)
• 团队领导的使命是维护团队，使其成员达到胜任预期的挑战水平，并负责产品内部架构的合理性。(TL= Team lead)
• 敏捷教练致力于培育一个环境。在这个环境中，保持团队成员身心健康并且参与到持续提高团队成员自身能力中，推动成员协同工作并完成产品交付。(AC= Agile coach)

以上三种角色有时会相互争执，在大部分团队中，这三个不同的角色有着不同的任务，因此会带领团队往不同的方向发展。

想必你也经历过一场产品经理、团队领导、敏捷教练之间的争执。产品经理积极地推动一个重要的新功能？而团队领导则更关心这个团队在现存的代码库中已经欠下了堆积如山的技术债所带来的挫败感？而敏捷教练认为团队需要停下来更加频繁地去思考，去反思如何提高自己的价值？但是产品经理会顾虑到团队的节奏会被打乱？又或是当团队领导认为团队足够敏捷了，并积极阻止敏捷教练越来越激动地尝试去帮助团队更加敏捷？

我们上文中所提及的很多介于 Dev 和 Ops 之间的类似问题同样存在于许多典型的公司中。

在一些开始尝试 DevOps 的公司，经常会受到来自内部（结构、社会、文化、等等）的阻扰，这就直接导致引入 DevOps 时异常困难。即使在 DevOps 盛行的公司也会发现很多不一致的时候。通常情况下，这些问题类似于两个人睡在一张单人床上盖一个毯子，由于毯子太小了无法盖住两个人的全身，于是两个人不断地拉扯着这张毯子，以尝试盖住自己暴露的部位。

我们时不时会看到那些老派运维工程师拒绝把基础设施看做是代码，他们更愿意手动修改目标机器的配置文件。那些看不起运维工作的开发者们，通常觉得他们的工作就是一旦开发完成，那么无论发生什么样的事情——哪怕是因为代码漏洞而导致服务器遭受攻击——那也是别人的问题。开发和运维的领导者会因此彼此的任务不同而产生争执。（衡量开发的指标是新功能开发的数量特征，相比之下运维的目标是保持最短的宕机时间。）

DevOps 的诱人之处就在于它能够促进开发和运维之间的沟通和互相学习，说来说去还是一个沟通的问题，一个目标一致性的问题。一旦我们开始学会倾听彼此的心声，我们就已经在 DevOps 的路上了。

如果你能够跟工程团队的领导者亲密无间的并肩作战，结果会如何？

如果我们让 PO、TL、AC 定期讨论他们所关心的东西——包括短期和长期的团队目标，并彼此教导对方所处的实际情况，又会怎么样？我们是不是会在那三类角色中发现跟 DevOps 类似的协同效应？我们是否能够消除他们之间的冲突，甚至还会发现更多的东西？

Potlac

那就是我们六个月以前所做的事情。在此之前，我们三个从来没有以这种特殊的方式在一起协同工作过，我们愿意一起来尝试做这个试验。我们的目标是调解不同部门之间的误解，并且尽可能地获得某种协同效应。

我们做了什么？我们用了什么方法将 DevOps 运用到我们的工作中？

每周同步会议

我们每周花半小时从各自的视角出发来讨论当前的状态。每次会议我们每人至少准备一个话题用来讨论并消化，这些话题可能涉及到利益相关者的参与程度，或者即将举行的会议，或者下一个反思会的主题。

重要会议前快速交流并同步信息

我们任何一个人在召开一个重要会议之前，都需要和其他几人进行一个简短的快速交谈，以便在会议开始前获得最后的反馈信息。召开此次会议的人将会重申此次会议的目的，如目标是否现实，或者怎么做才能真正得到会议参与者的参与。

定期一对一

我们每个人每周都会相互进行一对一交流，在办公室，或者是午餐时间，又或是晚上简短的电话沟通。每次交谈都围绕着我们共同的目标，而减少谈话成员的数量则可以营造更加私人的气氛，交流的问题也能够具体到个人。

模拟会议

如果是一个特殊的会议，或者实验性的议程，我们相互之间会开一些模拟会议，尝试着用推理的方式检查一下棘手的部分或者发现潜在的问题。

以上四点就是我们最主要的协同方式。这个三人团队的突发性改变在于我们开始关注彼此的鞋子是否合脚，并且在某种意义上我们每个人突然有了一致的目标，就好像一个人同时戴三顶帽子——当然了，跟我们职责相关的那顶帽子是最大的。团队协作的方式让我们成为一个更加强大的团队，并且随着讨论越加深刻，也越依赖彼此之间合作。

之前所描述的组织之所以能成功的一个很大的原因在于我们坚信团队的力量并始终作为一个团队在工作，而非个人。在我们看来，这种团队导向的思维才是 DevOps 能行之有效的主要原因。大家都相信整体大于个体之和。

在我们按照这个方式工作了一段时间之后，很偶然地想为团队起一个名字。我曾经在某个时刻，把团队的人的照片放在了一块板子上，并且这些照片下面用简称标注着各自的角色—— “PO”（Product Owner）, “TL”（Team Lead）, “AC”（Agile Coach）。 它看起来像是可以被拼读出来的，当 Ingrid 意识到 Potlac 可以被读作 Potluck 的时候，这个名字就这么定下来了（potluck 的含义是：每个人各自带着自己的食物，然后大家进餐的时候一起分享这些食物。 一次成功的分享食物需要一些协调者，否者就会出现一个人吃光所有食物的情况）。

Potlac 带来的收益

你可能会问：“那很好，听起来也不错，但是究竟能得到什么呢？”。嗯，这取决于你对什么负责。接下来我们将会列举我们这样工作之后所收获的好处——那些我们预料之外的好处。

Mattias：团队领导

管理是一件很孤独的工作。工程师们经常可以一起解决问题，而我却不能——我可以让他们帮我做很多事情，但是有一些事情是难以被简单地指派或者分享的（我考虑的因素有工作目标，个人自信程度，工资等等）。尽管我也不能同我的 Potlac 同事们一起分享这些事情，但是我可以分享其他的一些事情。比如用新的方法解决传统的问题，或者讨论如何可持续地扩大团队的规模。通常我都是通过这些讨论而获得了很多灵感，以此帮助我解决一些我所正面临的问题。

自从我们在 Potlac 进行了持续的对话，我们已经知道了彼此的愿景、各自的观点和团队的状态、历史。通过这些，还有不同的交际圈（公司内部和外部），相比之前我有了用更长远的视野观察事物的优势。我能够提前准备并且在这些问题变成更大的问题之前解决掉它们。

Ingrid：敏捷教练

Potlac 给我提供了一个围绕敏捷话题开展讨论和机会和平台，一个探讨服务型领导力的舞台，一个寻找这到底意味着什么而达成共识的论坛。它逐渐成为管理团队专注结果并为彼此负责的接口。它也很快就成为一个清除障碍和争吵的沙箱。它同样也是一间为我们提供如何组织与主题相关人员参与的会议、策划会议、反思、一对一交谈的教室。它还发展成为我们讨论自己的错误和我们学到了什么的平台。我们成为了一个团队，一个有着共同目标以支持我们所有工程工作为统一使命的领导团队，而不是之前的三个人朝着自己的目标奋进。

Ramon：产品经理

跟进产品交付的过程就像管理团队一样的非常孤独。与团队领导和敏捷顾问一起密切的工作让我受益良多。其中最重要的一个便是专注度，因为我知道其他两个同样重要的方面已经被我的两个同事所涵盖了，所以我可以完全把注意力放在我所负责的产品上。之前那些让人困惑的现象，比如有时候某个工程师会突然没有任务的情况，现在变得更加清晰明了，Mattias 给每个工程师都添加了一个个人状态的信息。Ingrid 团队开创了全新的方法解决典型的问题，这也帮了我很大的忙。

第二个重要的好处是避免了那些典型的很难处理的技术债务问题。召集涉及该问题的不同利益的成员进行公开的讨论，能够更容易地解决这个问题。如果没有这样的讨论，解决技术债务这件事儿往往只能停留在个人头脑的纠结当中。

我们已经看到了 Potlac 的初步实验给我们日常工作带来活跃的、难以预见的、甚至是超出预期的新见解。这种共同工作的方式开拓了我们的眼界，并且让我们在思考问题的时候能有更多的想法。

在一天结束的时候，它的真正意义在于回顾当天所发生的事。比如为什么某个产品现在必须上线而不是将来的某个时刻。比如团队中某个争论的背景。比如如何为特定的团队在特定的时间选择正确的紧急情况处理方案。

DevOps 帮助工程师们更好地换位思考，展示彼此的所需与被需。Potlac 用同样的方式帮助了我们三个去关注更重要的事情。

那么，现在应该如何呢？

虽然这是一个了不起的尝试，但我们所工作的环境正在发生变化。随之，我们需要在某些方面调整我们的做事方法。这个由 9 个人（包括我们）所组成的团队在来年很有可能增加一倍规模，公司也一直在扩大规模，焦点也在不断转变。Ingrid 做为 Agile 顾问已经被指派到其他地方工作，Ramon 则兼顾了更多的的 PO 职责。Mattias 所管理的团队将会新来一批工程师。我们每一个人都需要在全新的环境中成立全新的 Potlac 小组。

我们问过自己一个问题，Potlac 要如何随着工程师团队的发展而扩展呢？随着更多的人加入这个团队，我们将会开发和维护更多的产品。这也就意味着我们会有更多的产品经理。这个团队的领导将再难以管理如此多的人——有一些团队一分为二也是因为这个原因。如果团队扩大到这样的一个规模，最后我们可能需要两个 Agile 顾问。但是当人数从三个增加到六个的时候，Potlac 是否还会起到应有的作用呢？

另一个我们所考虑到的重要的问题是复制这个领导模型的难度有多大。在软件世界中，如果一个 hack 能解决问题，这很好，但真正的价值取决于这个 hack 是否被记录成文档并在其他场景可复用。Potlac 是否也能够被移植到其他场景下复用？

如果我们能够开发类似 Puppet 工具将 Potlac 部署至其它团队，这该多好啊，可惜 Puppet 没有这个功能。在那个美好时刻到来之前，希望这篇文章能帮忙我们让我们所做的事得到我们上面所描述的结果。

Hack 组织有如 hack 软件，不亦乐乎？

PS：如果你想更一步了解我们是如何组织我们这个机构的，请看 Henrik Kniberg he Anders Ivarsson 的论文 Scaling Agile at Spotify 。

关于作者

Mattias Jansson 是 Spotify 工程师团队领导。他曾经担任过大学讲师，课程统计助理，软件开发工程师，网站可靠性工程师，近来他的精力都集中关注于内部管理。

Mattias 目前的激情主包括：敏捷，雇员领导，调节技术与非技术人员之间有差距。你可以通过 Twitter 联系到 Mattias。

原文英文链接： DevOps @ Spotify

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。