在 Netflix，我们反向运用了康威定律
作者：Juan Ignacio Vimberg
2020 年左右，当我刚加入 Netflix 平台团队时，我们提供的“可观测性 (Observability)”工具集由一系列用途各异的工具组成。有用于指标监控的 Atlas，用于分布式追踪的 Edgar，用于日志和警报的 Radar，用于仪表盘的 Lumen，用于应用健康的 Telltale 等等。整个产品矩阵大概有 20 个不同的应用。这些应用大小不一，从分析播放会话的专用业务工具，到用于 CPU 性能分析的底层工具，应有尽有。
当时，整个可观测性部门由三个不同的团队组成。每个团队里都有前端、后端和全栈工程师。我们还有一位设计师和一位产品经理 (PM)，由这三个团队共享。而每个团队又被进一步划分成若干个子团队，每个子团队由两到四名工程师组成，专注于某个特定的子领域。
这样的组织架构最终产出一系列相互独立的应用程序，这绝非偶然。这正是康威定律 (Conway’s Law) 预言的那种架构：
任何设计系统的组织（广义上），其最终产生的设计方案，在结构上都与该组织的沟通结构保持一致。
—— 马尔文·康威 (Melvin E. Conway)
简单来说，系统的架构会跟创造它的组织架构长得一样。这是因为，要构建一个复杂的系统，人们必须通过沟通来确保各个部分能够严丝合缝地协作。因此，最终诞生的系统设计，其实就是一张组织内部沟通路径的地图。
Netflix 打造软件的方式，更是加剧了这种效应。Netflix 推崇“全周期开发” (Full Cycle Development) 的理念；这意味着每个团队要对软件的整个生命周期负全责，从设计、开发，一直到运维和支持。
我们的团队被组织成“高度一致，松散耦合” (highly aligned, loosely coupled) 的形式，享有高度的独立性。每个工程师都完全掌控自己工作的方方面面，从技术栈的选择，到用哪个工单平台来追踪 bug。Netflix 会提供一套推荐的工具（被称为“铺好的路” (paved path)），但并不强制大家使用。每个团队都可以自由选择最适合自己的工具和实践。
Netflix 有一套由中央团队正式支持的“铺好的路”工具和实践。我们不强制要求大家采纳，但会通过确保使用这些技术的开发和运维体验远胜于其他方式来鼓励大家使用。
摘自 “全周期开发”博客文章
这一切共同导致了一个结果：为了满足公司的可观测性需求，我们开发出了一堆五花八门的应用程序。每个团队都专注于自己的子领域和独立产品，力求提供最好的体验。在一段时间里，用户们对结果也还算满意……
但到了 2020 年，我们开始听到一种新的抱怨。用户们对于我们在故障排查方面提供的割裂体验，渐渐感到沮丧。要调试一个特定的问题，他们不得不在多个工具里重复输入相同的查询条件，然后在不同浏览器标签页之间来回切换，才能把零散的信息拼凑起来。 为了高效地排查故障，用户必须对每个工具都了如指掌，并且清楚在什么情况下该用哪个。更糟糕的是，不同应用的文档散落在各个 wiki 页面，我们也没能很好地向用户介绍那些新工具和新功能。雪上加霜的是，每个应用都有自己的一套基础组件（比如日期选择器或查询构建器），彼此之间还有着细微的差别。用户需要的功能其实都在，但只有那些“高阶玩家”才能玩得转，即便如此，想要全面地掌握一个问题，也得费上九牛二虎之力。
面对这些反馈，我们的第一反应是在各个应用之间添加深层链接 (deep links)，这样用户在跳转到另一个工具时，可以把查询的上下文信息也带过去。这能让用户在不同工具间的切换流程更顺畅一些。为了实现这个功能，我们几个团队不得不坐下来开会，讨论并统一一个标准，用来通过链接发送和接收上下文信息。可就是这么一件看似微不足道的小事，我们都开了好几次会，才最终敲定一个能满足所有应用需求的标准。
我们很快意识到，光靠链接是解决不了问题的。跨团队协调这些改动所耗费的漫长时间，也让我们自己感到很沮丧。这些链接反而让一个事实变得更加显而易见：我们的工具之间存在功能重叠。举个例子，你可以在 Edgar（分布式追踪工具）里查到某个请求的所有日志，但你只能在 Edgar 自带的日志查看器里看，而这个查看器远没有 Radar（日志工具）的强大。有了深层链接后，用户可以点击日志跳转到 Radar 里查看，但代价是会丢失请求的上下文信息，而这些信息只在 Edgar 里才有意义。
我们终于恍然大悟：如果我们想提供一个连贯统一的可观测性体验，我们就需要一个单一的应用程序，让用户可以一次性查询多个数据集。一个能让他们从不同角度观察系统，而不用在各种工具之间疲于奔命的地方。
我们清楚自己想要什么样的系统架构，而根据康威定律，我们也明白，以当前的组织架构很难实现这个目标。因此，在我们讨论如何实现任何功能之前，甚至在我们想好是开发一个新工具、一个全新平台，还是直接采购现成的解决方案之前，管理层做出了一个决定。他们进行了一次“逆康威操作 (Inverse Conway Maneuver)”，对团队进行了重组。他们重塑了组织架构，让它与我们期望的设计方案相匹配，从而建立起必要的沟通路径（并切断不再需要的路径），为接下来的工作铺平道路。 就这样，“探索 (Explore)” 团队诞生了。
在这个新架构下，团队的沟通方式被优化，目标是打造一个统一的体验，整合现有的日志、指标、追踪、警报和仪表盘等所有功能。当然，凡事皆有取舍。重组的代价是，现在负责某个垂直领域功能的后端开发被分到了另一个团队。这意味着前端和后端工程师之间的沟通变少了，导致那些需要前后端紧密协作的功能，开发速度会变慢。 管理层在重组前就考虑到了这一点，并认为这个代价是可以接受的，因为在我们的路线图上，实现平台的统一是更重要的任务。
这件事给我们的启示是：
组织架构会限制一个组织能为特定系统架构设计出的解决方案。这就是康威定律。
如果你清楚自己想要达成什么样的架构，你就可以调整组织架构，让它更容易帮你实现目标。这就是所谓的“逆康威操作”。
在一个系统的生命周期中，你可能需要根据不同阶段的目标，采用不同的组织形式。
选择任何一种组织架构时，重要的是要考虑其利弊得失，理解它优化了哪些沟通路径，又弱化了哪些，以及这会对工作流程产生怎样的影响。
如果你对这个话题感兴趣，可以读一读 Matthew Skelton 和 Manuel Pais 合著的《团队拓扑学 (Team Topologies)》这本书。
原文链接： https://jivimberg.io/blog/2023/09/04/the-inverse-conway-maneuver/