与 800 位挚友一起做架构：谈 Comcast 架构协议的演变

本文要点

• 大中型企业中的现代软件架构日渐趋向于分布式。敏捷方法、DevOps 和微服务等技术，在很大程度上使得各个团队能做出独立的技术决策。

• 在一些企业内部，沟通依然依赖于树形组织架构，这常常会形成信息孤岛（silo），导致团队间难以相互了解彼此所做出的决策。

• Comcast 形成了一种称为“架构协会”（Architecture Guild）的软件架构方式，目的是在避免干扰各团队自身的决策权的情况下，为从通用技术中获取一些有用的关键技术“牵针引线”。

• 架构协会是一个草根框架，它用于跨组织边界识别可靠的、切实可用的推荐技术，以及 IETF 等一些已经成功的非集权工作组的最佳实践。

引言：非集权式的决策制定

就在不久前，中央集权的审查委员会依然是大型技术企业中的常见软件架构。其中，由一些身着“紫色长袍”（指地位尊贵）的人员负责审查，确保所有设计与企业宏伟愿景的一致性。在 IT 被公认为企业成本中心的时代，这种架构非常有意义，因为最好的软件维护成本控制方式，就是形成标准化和一致性。

然而，当我们想要在 Comcast 采用这种架构时，却产生了“寒武纪生命大爆发”（Cambrian Explosion）问题。只要是当前流行的开源项目，就会被人用于某个生产环节中！当然，考虑到一致性的优点，企业依然需要确保愿景与设计间的一致性。

Comcast 的考量

我们的行业中一个势不可挡的发展趋势，就是敏捷团队致力于制定自己的技术决策。在《驱动力》（Driver）一书中，作者 Daniel Pink 提出，自主权（autonomy）是员工敬业度的三大主要推动力之一。敏捷宣言（The Agile Manifesto）[6]中也同样指出：

“项目需围绕那些具有积极进取心的员工建立。为这些员工提供他们所需的环境和支持，并信任他们能完成工作。”

以及

“最好的架构、需求和设计均出自于自组织团队。”

一些商业出版物也对这种授权做法的优点给予了支持。例如，华尔街日报的“推动工作场所中的决策制定”[1]，《Inc.》杂志的“为什么说自管理团队是商业的未来”[ 2]，以及哈佛商业评论出版社的“赋权：释放员工、激励客户并改进您的业务”[3]。那么其中的原因何在？

一个原因是考虑到企业本身就需要更高的敏捷性。John Boyd 通过对军方战斗机飞行员的研究发现，能够更快实现“观察-瞄准-判断-行动”（OODA，Observe-Orient-Decide-Act）决策环的飞行员，可以通过破坏他们对手的 OODA 环而赢得战斗。该理念后来同样被商业界接受。因为在竞争激烈的行业中，快速做出决策是非常有必要的。

另一个原因是考虑到企业自身的吞吐量和规模。通用扩展法则（ Universal Scalability Law）预测，系统（包括合作人员的组织系统）可实现的最大吞吐量，受限于所竞争的共享资源，以及使每位员工了解进展所需的一致性开销。随着软件“正在吞噬整个世界”，技术企业和商业对服务的需求在不断增长。自然而然，中央集权架构的审查委员会构成瓶颈，因此而遭弃用。企业发展的重点是团队规模最小化，并能够独立承担工作。

康威定律（Conway’s Law）指出，我们所见到的系统设计，反映了构建团队的交流模式。如果企业将大量时间用于让团队试图在缺少协调的情况下开展工作并做出决策，那么毫无意外，千差万别的技术就会渗透应用于企业的方方面面。

对结构化的需求

在俄勒冈州的北部，生长着一群占地达 3.5 平方英里（约 9 平方公里）的蜜环菌，据估计有 2400 年的历史。这无疑是一个成功的有机体！然而，它不能长得像灌木一样高，也不能自己迁移加利福尼亚州北部。因为这个菌群只是一个蘑菇的群体集合，虽然具有相当的规模，但并非结构化的。从生物学角度看，进化已经触及一定程度的结构，例如肌肉、骨骼或神经系统。这些结构提供了实现某些有用能力的有效方式。

在一些人工设计的大规模系统中，我们也会看到同样的理念。美国州际公路系统（The Interstate Highway System）提供了比现有地方道路系统更高效的长途汽车运输。此外，即使是 ARPANet 的最初架构，在站点间也存在传输共享链路，实现完全互联的网格代价很大。

技术企业同样可以从此类结构和共性中受益。企业不需要使用来自多个竞争供应商的多种商业产品，而是只需考虑其中一家的公司，并可协商得到很好的折扣。在面对 Heartbleed 或 Spectre 等关键安全漏洞时，如果系统在架构上具有更好的通用性，那么更易于在各处应用补丁，无需追踪大量独立选择、部署和升级不同版本服务器操作系统的“蘑菇”团队。

那么，我们如何才能在独立、授权的团队文化中形成这样的结构？怎样才能让这些团队就一系列常用技术达成一致，从而实现商业收益？

架构协会（The Architecture Guild）

我们在 Comcast 工作中意识到，该问题与一些开放标准机构的工作方式非常类似，即如何让多个自治团体就某些技术方法达成一致意见。由此，我们设计了一种企业内部的“架构协会”（Architecture Guild）。架构协会使参考了一个非常成功的标准组织建立的，即定义了大量重要 Internet 协议的互联网工程任务组（IETF，Internet Engineering Task Force）。

IETF 提供了一种定义了分布式活动的层次结构。在该层次结构的顶层，是互联网工程指导小组（IESG），主要负责决策 IETF 工作将解决哪些主题领域（topic area）的问题。进而，IESG 定义了网络、应用等主题领域，并招募区域主管（AD，Area Directors）监督这些主体领域。AD 为工作组（WG，working group）制定章程，用于定义各种标准。此后，个人而非企业加入工作组，参与标准的编写过程，最终发布 IETF 的标准文档 RFC（Requests for Comments）。

针对 Comcast 的实际情况，我们采用一个集权式战略架构团队实现 IESG 的功能。该团队负责确定具体的技术能力，确保能力实施中共性需求最大化。我们着眼于那些能够充分理解团队需求并具有多种成熟解决方案的能力。我们更希望能找到“适用于所有问题”（One size fit all）的解决方案，并期望这些解决方案是未来几年内的合理解决方案。我们并不需要 IETF 给出的区域或 AD 概念，而是由团队直接监督工作组。我们在最初建立架构协会时，团队撰写了大量工作组章程。随着架构协会的落地实施，团队的经常性工作包括审查其他团队提出的工作组章程。

Comcast 是一个分布式的技术企业，既有远程员工，也有散步各个地理位置的办公地点，我们决定强调在架构协会工作中的异步、书面方法，确保每个员工都有平等的参与机会。其中的核心构建，是我们聊天工具中的专用“#architecture”频道，以及与之相关的电子邮件分发列表。进而，我们希望每个团队至少让一名成员加入到频道和邮件列表，及时了解架构协会的活动情况。

工作组（WG）的生命周期

工作组的工作从章程着手。章程简要阐述了工作组是否要去解决的主题。考虑到技术能力与实践间相互关联紧密，我们将某些主题定义为“超出范围”，这有助于限定工作组的讨论范围好推进工作。

章程一旦定义，我们就会为它创建一个专用的聊天通道（例如’＃arch-wg-source-control’），以及一个工作组专用的源代码库。所创建的聊天通道将会在“#architecture”主频道及邮件列表上广而告之，对此感兴趣的个人可加入和参与其中。随后，我们会为工作组招募二到三位联合主席担任编辑，帮助工作组继续取得推进。经验表明，良好的工作组推进技要能比联合主席的技术专长更为重要！

工作组的职责是记录建议形成架构决策记录（ADR，Architecture Decision Records）[4]。ADR 文件记录了：

• 场景：我们在做出决策中考虑了哪些信息？

• 决策：我们的推荐是什么？

• 合理性：我们为什么要做出这样的推荐？

• 结果：存在哪些已知的缺点？

我们发现，工作组很想直接一步跳到决策步骤，由此，我们给出了一个更为结构化的流程以建立“粗略的共识”。首先，我们构建 ADR 的场景部分：

1. 允许每个人给出相关的用例，并在 ADR 中记录。

2. 通过讨论，确定推荐的解决方案所必须具备的核心要求。

3. 允许任何人提议特定的解决方案，并在 ADR 中记录提议列表。

4. 根据标准，简要评估每个提议的解决方案，即标准是否能积极提议方案。同样，在 ADR 中记录。

我们发现尽管已经提出了一些解决方案，但没有人愿意概要记录解决方案与标准的符合方式。我们认为，这表明这些解决方案并非真正的主要考虑。我们还发现，其中一些解决方案并不符合必须的标准，尽管依然需要在 ADR 中保留评估的细节，我们也可将它们从进一步的考虑中剔除。最后，我们借鉴 IETF 使用“运行代码”的座右铭，提出了一个通用规则，即我们只能建议团队立刻将解决方案用起来。这样，我们不会去考虑那些尚未拿出来的完美解决方案，以及那些我们还没有获得许可的商业解决方案。

由此，工作组的谈话范围缩小到数量更少的可行解决方案。我们调查了工作组对上述做法的态度。我们并没有采取投票的方式，例如“我们应该选择哪一个？”，而是单独要求参与者对每个解决方案给出“从一到五”（fist of five）[5]的评级：

“五”：这是目前最好的解决方案。

“四”：这是我们手头的最佳选择。

“三”：这并非我的最优选择，但是我理解其诉求，并愿意继续使用它。

“二”：该解决方案可能有效，但可能需要首先解决一些问题。

“一”：选择它将是个很糟的错误。

这样，我们的目标转变为给出一种大多数参与者评级为“三”及以上（即“可接受的”）的解决方案。如果参与者对解决方案给出了评级“二”，那么我们要求他们将自己的关注点作为问题记录在 ADR 存储库中。由此，工作组可以对问题展开进一步研究，以记录在特定解决方案中如何解决该问题（虽然有时是无法解决的）。我们发现通过上述过程，能够将一些评级“二”的解决方案改进为评级“三”。有时由于参与者并不熟悉所建议的解决方案，因此产生了一些担忧（当然这也是可理解的）。为消除此类担忧，应该让具有更丰富经验的人对此给出评论意见。

在得到解决方案后的最后也是最重要的一步，就是确保我们考虑了那些在 ADR 结论部分中但尚无法解决的已知问题。正如我们所知，每个解决方案都具有一定的权衡。我们发现，考虑工作组成员识别的合法缺陷，也是一种围绕最终决策建立支持的方式。该方式可让工作组成员看到他们的输入已得到考虑和重视，并集成到解决方案中。

优点的涌现

自架构协会运行以来，我们发现了多个预料之外的优点：

1. 浮现出了架构和设计社区；

2. 加速了决策制定；

3. 群策群力形成工作组章程。

虽然最初我们建立“#architecture”频道是用于宣布工作组形成和推进情况，但该频道很快就成为各授权团队获取所做技术决策背景的一个额外交流中心。了解企业中其他团队正使用的技术，这是各团队都非常重视的事情。该频道支持团队获取内部社区专家的帮助，有助于解决常见的问题。目前该频道已经具有 800 多名成员，他们是我们整体内部技术社区的主要代表，即本文标题中提到的“八百位 Comcast 核心员工”。

我们还发现，一旦某些领域做出了工作组决策，就会加快其他领域的决策制定。例如，我们的源代码管理工作组已对某个特定的分支管理策略给出了建议。那么持续交付工作组就能够基于该工作组决策探索持续集成工具，无需操心解决方案是否需要支持所有可能的分支管理技术。

最后一点，也是最令人鼓舞的，就是架构协会的参与者已经着手为新的工作组提出章程，而不是等待企业的指导委员会去提出这些章程。这很好地表明了企业的技术人员支持该架构协会流程，理解了在某些领域做出共同决策的必要性。

总结

虽然现代技术企业支持各个团队做出自身的技术决策，但是仍然需要形成一些通用的技术结构，以应对不时之需。对于那些大型企业尤为如此。Comcast 已经建立了一种称为“架构协会”的软件架构，并取得了巨大的成功。该架构是遵循一些成功的现有分布式标准组织构建的。其中，工作组通过建立一种具有包容性和协作性的过程，提出经全面评估、深思熟虑和广泛支持的技术建议。

参考文献

[1] Spors, K，“推动工作场所中的决策制定”（Pushing Down Decision Making in the Workplace.），华尔街日报，2008 年 10 月 27 日。

[2] Blakeman, C，“为什么说自管理团队是商业的未来”（Why Self-Managed Teams Are the Future of Business.），2014 年 11 月 25 日。

[3] Bernoff, J.和 T. Schadler，“授权：释放您的员工，激励您的客户，改变您的业务”（Empowered: Unleash Your Employees, Energize Your Customers, and Transform your Business），哈佛商业评论出版社，2010 年。

[4] Nygard, M.，“架构决策的文档化”（Documenting Architecture Decisions"），2011 年 11 月 15 日。

[5] Calabrese, Jake，“学会五级投票”（Learning with Fist of Five Voting"），2014 年 12 月 23 日。

[6] Beck 等，“敏捷软件开发宣言”（Manifesto for Agile Software Development）。2001 年 2 月 13 日。

作者简介

Jon Moore 是 Comcast Cable 的首席软件架构师，致力于为企业中各软件产品开发团队提供一套可扩展、高性能、强大的核心软件组件。Moore 擅长于“可能性艺术”（the art of the possible），需求协调复杂问题并按时交付的可用解决方案（即便是对于一些大型企业）。Moore 同样擅长团队的领导和管理，他也亲自编写一些可用于生产环境的代码。

查看英文原文： Architecture with 800 of My Closest Friends: The Evolution of Comcast’s Architecture Guild