从 Etsy 团队看敏捷架构的设计

背景

Etsy 是我们最喜欢的一个从事手工艺品或古董在线市场的科技公司。该公司拥有稳定的技术团队，技术运维由约翰·阿尔斯帕瓦掌舵，其网站偶尔也经历网站中断。

2012 年 7 月 30 日，发生了这样一件事，员工为支持多字节字符集的语言进行了数据库升级。一切都是按照计划进行的，他们先升级了一个生产数据库。数据库升级，尤其是改变静态数据的编码，存在着数据破坏或丢失的风险。为此，该小组精心制订了一个在一段时间内把剩下的服务器缓慢升级的计划。他们只升级一台服务器，而让其他服务器的升级基本上准备就绪。

Etsy 往往有许多变更在排队进入生产环境。网站在夜间备份的时候速度缓慢，更快的备份方案正在排队等待实施的时机。为了推出解决备份问题的修复代码，Etsy 的工程师们使用了自动化的工具，以确保服务器的一致性。经过测试后，他们使用该工具将修复的应用版本发布到备份中，在不干扰网站性能的基础上，期待着稍后确认备份的成功。他们当时并不知道部署改进备份的部分也同时升级了数据库的语言。

当意识到大约 60%的 Etsy 的数据库服务器在升级字符集的同时仍然在服务用户时，他们迅速地关闭了网站，以防止数据损坏。回应这一事故的团队由多个部门的人员所组成。正如阿尔斯帕瓦说的那样，“不只是一个团队在响应事故”。在 Etsy，很多人参与了 24/7 值班小组。没有问题管理者存在的必要，因为每个团队拥有自己所研发的服务。在某些情况下，如搜索团队，由来自不同领域的员工组成的敏捷开发团队作为一级响应。搜索团队首先接到警报，在必要的时候，把问题升级到的技术运维。

团队一旦能够确认数据库是正确的而且表现正常，就恢复网站的服务。同时，他们与社区通过 EtsyStatus 网站（http://etsystatus.com/）沟通。

这个例子显示出敏捷团队（5 到 12 人的跨部门团队，由经理、工程师、QA 人员、团队和 DevOps 人员组成）如何从架构设计开始到生产支持一直拥有自己的产品或服务。

本文将通过探讨功能和系统设计，来解释敏捷组织是如何实现系统相关的设计，以及独立的敏捷团队如何遵循标准。

敏捷组织中的架构

在功能型组织里，个人是按照技能、领域或专业组织起来的。然而，几乎每个项目都需要协调整个团队，这意味着跨部门协调。对 SaaS 提供商尤其如此，因为 SaaS 的责任不仅是软件开发和测试，还要运维和支持，所以属于公司的技术团队。这导致一定程度的情感型冲突。冲突的程度取决于许多因素，但我们希望尽可能减少这些因素。回想一下，情感型冲突是“坏”的，冲突集中在角色和所有权方面，涉及的问题往往是“谁”拥有或任务应该“如何”做？

这种类型的冲突具有破坏性，会导致团队成员身心疲惫。在身体上，它可以让交感神经系统（与下丘脑激发的打架或逃跑综合征相同的系统）释放压力激素皮质醇、肾上腺素和去甲肾上腺素。在组织上，团队可能会因为争夺产品和服务的所有权，导致封闭的思路和不良的结果。相反，敏捷组织打破功能型组织的斗争，并授权于团队，消除矩阵组织结构所面临的组织边界问题。

敏捷组织是由 5 至 12 人组成，拥有设计、开发、交付和支持面向客户的产品或服务所必需的技能。这些团队是跨部门和自成一体的。他们有权做出自己的决定，而且不需要外界的认可。他们有能力处理产品或服务的全生命周期。当团队以服务为主线跨部门组织起来，同时具有自主权，就可以显著减少情感型冲突。当团队成员拥有共同的目标，并且不再需要争论谁负责什么或谁应该执行某些任务时，团队就会荣辱与共。 每个人都会负责确保所提供的服务符合业务目标。

在 SaaS 产品服务方面，创新的增加往往是通过度量更快的市场响应时间、更好的产品质量和更高的可用性来确定的。这种创新的驱动力降低了情感型冲突，提高了认知型冲突、多样性和授权管理的水平。敏捷的组织结构提供了所有这些驱动力，其结果往往是创新的显著增加。

架构的所有权

创新、更大的自主权和更少的情感型冲突听起来很棒。然而，与更大的权力伴随而来的是更大的责任。这些敏捷团队拥有服务或产品的架构。换句话说，他们不依赖独立的架构团队，而靠自己完成产品的设计和实施。在实践中这是如何实现的呢？

敏捷团队由拥有所需全部技能的人员组成，确保团队能进行产品的自主研发。典型的团队成员包括产品经理、几个软件开发人员、质量保证工程师和 DevOps 工程师。如果该公司有软件架构师，架构师也被放在敏捷团队里。这样的团队构成应该让你想到第 13 章的 JAD 过程。如果敏捷团队设计和研发高可用和可扩展的产品与服务，其成员需要任何完成同样任务的其他团队相同的技能。JAD 像一个乐队助理，在以功能为导向的团队里，创建跨领域设计是敏捷团队的内在特质。

我们知道经验、技能和关系的多样性，有助于更好地解决问题—架构功能、场景、解决方案、错误修复或提供产品。 最好的解决方案来自于包括多个领域代表的团队，他们利用各自不同的观点和经验来解决这个问题。

如果请软件工程师设计一个门，他或她会马上开始思考门的工作原理，铰链如何运作，门把手如何转动，等等。如果请产品经理设计门，他或她可能开始考虑门应达到的效益，其他竞争对手的门都有什么功能，最后一轮用户测试的结果。如果请系统管理员设计门，他或她会开始思考如何确保安全，如果插销或锁出现常见的故障应该如何恢复。当我们把这些不同的观点都集中起来，就可以设计出一个更强大、更具可扩展性以及更高可用性的产品。

关系的多样性用来衡量团队成员的个人或专业关系网络。这对创新很重要，因为几乎所有的项目都会遇到不同的阻碍。关系广泛的团队能够在项目早期更好地识别潜在的障碍或可能遇到的问题，因为他们可以咨询各种各样团队以外的人。当团队确实遇到了障碍，这种多样化的关系使他们的易于发现和取得资源并绕过障碍。

有限的资源

当一个灵活的团队有多样化的技能、广泛的人脉关系以及各种各样的经验借鉴后，团队成员设计、研发、部署和支持高度可靠和可扩展的产品的能力会更强。如果公司不能为每个团队配备一位架构师，或者六个敏捷团队只有两个 DevOps 工程师会怎么样？

这个问题的不仅出现在资金有限的初创公司，也同样存在于现金充沛的高增长型公司。在第一种情况下，公司无法雇用很多架构师、DevOps 工程师和其他想要的专业技术人员。在第二种情况下，公司可能无法如愿吸引和留住许多架构师或 DevOps 工程师。团队的成长常常是非同步的，先招聘软件开发人员、然后是产品经理、再后是质量保证工程师、DevOps 工程师，最后是架构师。填补团队的周期可能花费一年到 18 个月的时间。没有一家公司会让软件开发人员闲下来等待架构师的加入。但是在这种情况下，团队该怎么做呢？

当面对有限的人员和资源时，团队通常会试图以现有的有限资源来对付。这种方法可能会为公司带来相当大的风险。试想一下没有足够的产品经理的情景。结果可能是仓促编写的用户场景描述和调度很差的项目优先级，结果导致严重的错误。

敏捷团队的第一步是确保他们有必要的资源来完成项目。

一旦关键资源缺失，这个团队就会处于危险之中。争取必要资源的办法是使用看板来直观地显示研发过程中的资源瓶颈，说明需要资源的业务理由。另一种方法是跨团队共享资源。有限的资源，如 DevOps 工程师，可以在整个团队共享。这些人应该被分配给多个团队，但不是所有的团队。就像有多个房客但不是所有的房客。例如，如果你有两个 DevOps 工程师和六个敏捷团队，把 DevOps 工程师 1 分配给敏捷团队 A、B 和 C，把 DevOps 工程师 2 分配给敏捷团队 D、E、F。这样，团队会感到与 DevOps 工程师有某种程度的关联性。他们开始思考“DevOps 工程师 1 是和我一起配合的人”而不是“我们有两个 DevOps 工程师的资源池，要找他们帮忙就要提交请求来排队”。看到区别了吗？一方面我们打破了壁垒，另一方面可以确保他们和团队一起成长。

标准

在多个团队情况下，如何保持标准，是一个不变的主题。如果我们允许每个敏捷团队自主决定哪种模式、基础库、框架甚至技术，公司如何受益于规模的扩展？工程师如何在团队之间调动的过程中共享知识？在很多情况下，这些问题的答案是“那要看情况”。

这取决于组织、领导和团队成员。让我们看一些不同的方法。

“规模经济”一词是指企业因其经营的规模而实现的成本优势。基本的概念是，因为固定成本分散在更多的输出单位，每单位的输出成本随规模的增加而减少。这种思想可以追溯到亚当·斯密（1723～1790）和通过分工获取更大的生产效益的概念。

对于工程团队，规模经济来自于诸如有关技术或经营方式的知识共享。如果从项目的角度把软件研发服务的成本分解成固定成本的和可变成本两个部分，我们可以得到如下的结果。固定成本包括软件开发人员的知识和技能。我们在每个迭代为此付出，无论是为一个场景写代码还是为 50 个场景写代码，成本都一样。每个迭代的代码完成量越多，固定成本的分摊就越小。如果只完成一个场景的代码，这个场景就消耗固定成本的 100%，如果我们的写 20 个场景的代码，每个场景就只负担 5%的固定成本。如果每个软件开发团队（敏捷团队）必须是不同的语言、技术或过程的专家，这个知识的固定成本只由负责那些场景的单一代码团队负担。 如果所有的团队都可以利用彼此的知识，那么成本就可以由所有的团队来分担。

一些组织认为应该允许团队对所有的事情独立做决定，最好的想法就会渗透到整个团队。其他组织采取不同的方法，把团队成员集中在一起制订出大家要共同遵守的标准。我们先来看看 Spotify 的数字音乐服务是如何解决敏捷团队的架构设计问题的。然后我们将以此方法与 Wooga 作对比，Wooga 是一个社交游戏公司，其采用的方法稍有不同。

Spotify 把每个团队称为小组，类似于一个 Scrum 团队（敏捷团队）。小组类似一个微型的初创公司，包含设计、研发、测试和配置管理服务全部所需的技能和工具。2012 年 10 月，科内博和爱瓦森发表了论文，《扩展性敏捷 @ Spotify，部落、小组、章节和公会》（Scaling Agile@ Spotify with Tribes, Squads, Chapters and Guilds）。“不论什么事都有不好的一面，完全自主不好的一面是亏损的规模经济。A 小组负责测试的工程师正在想办法解决 B 小组的测试人员上周刚解决了的问题。如果所有的测试人员可以跨越小组和部落的边界聚集在一起，那么他们可以互相分享知识和研发对所有人都有益的工具。”他们继续探讨这个问题，“如果每个团队都是完全独立的，不与其他队员沟通，那么为什么要成立公司？”

正是这些原因，Spotify 开始用章节和公会的办法。

一个章节就是一小部分人，他们有相似的技能。每个章节都会定期开会讨论其专业知识和遇到的挑战。章节的领导作为一个业务线经理以及一个小组的成员，参与到日常工作中。一个公会是一个更加有机的和更加广泛的兴趣社区，一组想要分享知识、工具、代码和实践的人。章节存在于当地的部落中（小组在部落中工作），而公会通常跨越整个组织。利用章节和公会，Spotify 可以保证在整个机构共享架构标准、开发标准、图书馆、甚至是技术。章节和公会负责任协调和促进讨论、实验、并最终做出决策，所制定的标准被所有的团队所遵守。章节和公会成员参与这些过程，负责把知识和决定返回自己的团队，确保团队的同事遵守决定。这种方法在专制的自上而下的方法和民主的自下而上的方法之间取得了很好的平衡。即使如此，对大型组织中的小型和独立的敏捷团队而言，在设计服务和产品的过程中，这也并不是唯一的方式。

在李希特的文章，《用独立的团队来扩展小的公司：游戏公司 Wooga 是如何运作的》，2013 年 9 月 8 日发表在在“下一代网络”（http://thenextweb.com/）上，作者概述了他培养独立团队的方法，以及向 Spotify 挑战的想法。李希特是成立于 2009 年的社交游戏公司 Wooga 的工程负责人。Wooga 已经从第一年的大约 20 名员工，成长到 2013 年超过 250 名员工。李希特说道，“在公司的早期，大家紧密地结合在一起，不必因为等待审批而放缓。通常随着公司的增长，管理层增加，工作就变得不那么有效率了。我们是怎么坚持这种文化的？我的答案是：一切围绕着独立的游戏团队。”

类似于 Spotify 和我们的模型敏捷团队，李希特组织了小型的自治、跨部门团队负责独立的游戏。这些团队自己编写和运维游戏本身，不依赖于集中的技术运维团队或框架。“工程师不是被迫共享或复用代码”是李希特对每个团队运作的独立水平的描述。关于社团以外个人的影响，包括公司的创始人，“这完全取决于团队是否想听或无视外界的意见。

然而在 Wooga，要利用知识并取得一定的规模经济，团队要积极地分享知识。他们通过每周的工作状态更新、闪电会谈、便餐会和其他的互动来完成这个任务。这种知识共享的优势帮助团队避免重复同样的教训。正如李希特所描述的，“这样我们可以在游戏中尝试新东西，当新东西奏效时，再把知识传播到其他的团队，这个机制很有效。”应当指出的是，团队有共享的结果，如关键绩效指标（KPI），但这些不构成团队间的竞争。

Wooga 的方法与 Spotify 的方法有很大的不同，章节和公会领导人的任务是确保整个团队共享知识和标准。那么哪一个是最好的？这两种方法都是必要的，公司需要评估整个团队需要建立哪些标准，各团队可以自行建立哪些标准。这取决于组织的文化、成熟度和过程。作为一个领导，你觉得哪个方法更好？你是否有一种企业文化的组合，包括有经验的个人为了公司的最佳利益可以独立行事，或者需要更大的监督？对这些问题的回答将引导你在一个特定的时间，为组织找到最佳答案。随着组织的成熟和发展，这种方法也可能需要改变。

敏捷组织中的 ARB

如前所述，敏捷团队提供 JAD 试图实现的跨团队设计。因此，当员工被组织成真正的自治、跨部门团队时，JAD 就显得没有必要。下一个问题是，“敏捷组织是否需要 ARB？”答案还是“不一定”。许多我们曾经提供过咨询服务的公司尽管有跨部门的团队，但仍然还有 ARB。ARB 的主要好处是它为团队提供了第三方的观点，因此不会被容易传染的自治团体思维左右。然而，如果我们把 ARB 放在产品的生命周期中，那么就会影响自主性和敏捷团队产生的市场效益。在迭代后进行 ARB 审查是一个增加优点和减少缺点的潜在方法。另一个选择是召开 ARB 每日例会（也许在午餐），讨论需要审查的任何项目。这样，团队就不必花相当长的时间来等待 ARB 的召开。

在敏捷组织里使用 ARB 时，主要的目标是确保制订的架构原则得到尊重。这有助于确保团队在技术标准和架构原则上保持一致。ARB 的第二个目标就是通过互动来教导工程师和架构师。随着团队规模的快速增长，或收购具有不同标准的新公司的时候，ARB 变得越来越重要。最后，ARB 有助于评估每个团队成员如何理解和执行标准。评估团队如何实现共同设计，并帮助纠正缺陷。

结论

敏捷团队作为一种小型和自治的组织，可以独立负责服务和产品的架构和设计。在设计方面，如果团队要尽可能灵活，这种自主权就至关重要。JAD 可以有效地确保完成跨部门的设计，跨部门的敏捷团队依靠其本身的组成确保这个结果发生。

有时组织面临有限的资源，比如 DevOps 工程师的人数比其他团队要少。我们建议将每个 DevOps 工程师分给几个团队共用。理想情况下，团队应该知道和他们配合的人的名字，而不是必须提交请求到队列上。这有助于打破组织架构的壁垒。

当我们与客户讨论敏捷团队的时候，经常有人会提出的问题是，如果团队是完全自主的，如何确保标准可以跨团队共享。一种方法（Spotify 采用）涉及跨越敏捷团队的章节和公会来确定并实施这些标准。另一种不同的方法（Wooga 采用）是团队很独立而且积极通过各种论坛分享知识。最后，你可以考虑使用 ARB 来验证架构原则的采用和合规情况，通过定期召开会议来回顾最近发布的设计。

关键点

▲敏捷团队应该自主行动，这意味着他们应该拥有自己的服务和产品设计。

▲ARB 和 JAD 确保跨团队的服务设计。敏捷团队通过自身的构成确保这个结果。

▲当运维资源如 DevOps 工程师或架构师有限的时候，把他们分配给多个团队。不要恢复取票排队等候 DevOps 资源池。

▲跨团队共享标准和知识，以实现规模经济仍然可以通过敏捷团队来完成。在这种情况下，可以使用各种方法。为组织选择正确的方法取决于多种因素，包括团队的成熟度、产品的复杂性以及对分布式命令和控制的舒适度。