工程师们（还有他们的老板）在过去四十年里花了很多时间学习（有时候是反复学习……）分布式系统的各种影响和含义。作为一个工程经理，我发现分布式系统的设计和工程团队的组织设计之间有很多相似的地方。
大多数工程经理如果对“组织设计”有所了解，要么是通过康威定律（“软件架构会反映出生产它的组织的结构”），要么是从《团队拓扑》这本书里学到的。（顺便说一下，如果你想知道康威定律是不是真的，可以看看《哈佛商业评论》的这篇论文；简单来说，它确实有道理。）除此之外……
虽然这有点超出这篇文章的范围，但可以说，组织设计是一个完整的研究领域，很多研究都和分布式系统设计一样严谨和深入。也就是说，有些人（尤其是学者）用非常严谨的方式研究它，而我们其他人则等着别人总结他们的发现，然后我们可能会完全忽略这些发现，转而追求一些新的热门工具或技术。我承认我不是组织系统方面的专家，但在过去十年里，随着我从管理的角度看到（观察和领导）更多的组织，我开始意识到两者之间有很多相似之处。
如果我们做一个基本假设，把组织结构图中的“团队”比作分布式系统图中的“服务器”或“计算节点”，而“团队成员”比作计算过程，那么我们就会发现一些非常有趣的相似之处。
个人（“流程”）完成任务的速度比委员会（“流程集群”）快得多。分布式系统中的进程会“进行 API 调用”或“传递数据”或“发送消息”，而人们则会“协作”或“交接”或“发送消息”。对于个人来说，记住（缓存）数据比从书或其他外部存储（数据库）中查找数据要快得多。改变个人当前记忆的数据需要花费大量时间重新记忆新信息，从通知他们变化（缓存更新和传播）开始。传递信息的成本会随着接收者距离的增加而呈指数级增长，无论是在隔壁、另一个房间、另一栋楼还是另一个大陆。……等等。
而且很难不注意到，分布式系统拓扑（一组节点，部分或全部通过链接连接）与流程流程图（一组节点（团队），部分或全部通过链接（通信或流程交接）连接）非常相似。我们把“工作流”称为涵盖人类行为和/或交互以及计算机行为和/或交互的术语，这似乎并非偶然。
在分布式系统领域，把分布式计算的八个谬误作为思考分布式系统的框架是非常有帮助的。利用这些谬误作为路标，或者更可能是警告信号，我们通常可以设计出合理的分布式系统，而不必过于学术化或条理化。因此，本着分布式计算的八个谬误的精神，我们可以得出分布式团队的八个谬误：
- 组织是可靠的。 我们都知道网络中的节点可能会定期掉线。当然，随着现代计算趋势和安全措施的实施，这种情况很少见，但仍然会发生。同样，即使我们知道大多数人大多数日子都会上班，但仍有某些人不会上班的可能性。他们会生病、会分心、会被管理层重新安排工作等等。如果这还不够，我们当然不能忽视他们上班、随时准备执行您的请求的可能性，只要他们收到了您的电子邮件/短信/办公室内备忘录/语音邮件，因为您的消息在通信路径的某个地方完全丢失了。（谁说 ACK 仅适用于低级网络协议？）
- 延迟为零。 两个人之间进行交流所需的时间显然不为零。事实上，将我脑海中的想法传达到你的脑海中可能需要相当长的时间。有时这是因为沟通媒介（办公室备忘录）需要时间，但……
- 带宽是无限的。 对于人类来说，我们担心的不是通信带宽，而是个人的思维带宽。大多数人无法同时处理一两件以上的事情。即使是患有注意力缺陷障碍的人，我们也发现我们能够集中注意力的事情数量是有限的，而且我们比大多数人更擅长多任务处理。人类最终需要对他们正在处理的事情进行优先排序和序列化，这意味着有些工作会被放到最底层。
- 网络是安全的。 当然，人力资源部不会在一张纸上写下一份绩效管理报告，找到办公室外的第一个人，把那张纸交给他，然后让他把信息亲自交给隔壁大楼的销售副总裁——这种做法完全不专业、极其违法、极其不人性化、极其不道德。我们明白这一点。但是，如果人力资源部正在与销售副总裁交谈，那么当人力资源代表坐在开放式办公室中间时，还有谁在听他们的谈话呢？更重要的是，当两个贷款官员正在讨论抵押贷款客户的财务状况时，谁在听呢？ （很久很久以前，英特尔发现自己陷入了一个有趣的困境，他们发现科技新闻记者只是乘坐往返于圣何塞和萨克拉门托（英特尔在福尔瑟姆设有制造工厂）之间的航班，只是听着英特尔员工之间的座位聊天，而这些员工很容易通过他们自豪地佩戴的英特尔工作徽章辨认出来。）如果您的组织结构图中的节点必须相互通信，那么他们是怎样做到的？
- 拓扑结构不变。 众所周知，组织结构图是不稳定的，甚至可能比计算机网络拓扑更不稳定。如果团队 A 需要依靠团队 B 来完成其需要完成的部分工作，那么当团队 B 被重新组织到一个完全不同的部门时会发生什么？
- 只有一个管理员。 好吧，从技术上讲，如果每个人都在同一家公司工作，那么就有 CEO，但这里更大的问题是，团队经常需要“跨”组织结构图进行协作，而两个团队唯一由同一个经理管理的地方就是组织结构图的上方——例如，当产品和工程团队一起工作时，工程团队最终将向工程副总裁汇报，产品团队向产品副总裁汇报，而产品副总裁又分别向 CEO 汇报。这意味着没有一个与团队关系密切的人可以解决任何个人冲突或“地盘之争”——团队必须自己解决问题。双方都无法有效地向权威机构求助以寻求解决方案。这意味着团队必须感受到一些压力才能让事情顺利进行，即使他们在合作的某些部分存在智力或道德分歧。
- 传输成本为零。 在原始谬论中，这一谬论通常被视为与“延迟为零”谬论有关——前者侧重于实际传输数据所需的时间，而这一谬论则更侧重于准备传输数据以及在接收时解释数据所需的工作。（例如，在 RPC 术语中，我们谈论的是“序列化和反序列化”通过线路传输的对象。）在组织场景中，这种传输成本通常是耗时最大的，因为有时团队必须创建定制的演示文稿或文档，仅用于向其合作者传达一个或多个复杂的想法（更不用说在我们等待所有必须参加会议的人在日历上找到空闲时间以便能够讨论手头的话题时引入的延迟！）。
- 网络是同质的。 在分布式系统谬论中，詹姆斯·高斯林 (James Gosling) 引入了这一谬论，指出 (几乎) 没有计算机网络实际上是由同一种硬件/操作系统组合组成的 (它从来都不是全英特尔/Windows，从来都不是全 ARM/macOS，从来都不是全任何东西)。因此，他的论点是建议“这就是为什么一切都应该用 Java 编写！”，因为这将使谬论变得毫无意义。当然，我们很快就用 Java、C#、Ruby、Smalltalk、Go、Dart、一些 C++、一点 COBOL 编写了所有内容……从组织的角度来看，重要的是要意识到，不仅每个团队的建立目的各不相同，团队中的每个人通常都拥有不同的技能和观点。这具有积极的一面，即能够充分利用其成员优势的团队通常能够超出预期地完成任务，但这也意味着，如果团队没有认识到“并非每个人都擅长会计”，那么在尝试更换一个人而不考虑他们的个人技能时就会遇到问题。（我正直视着你们，“全栈工程师”猎头……）
请注意，这些并没有完全涵盖组织设计的所有应该做的和不应该做的事情（十分之一都没有），但它确实为一个有趣的思想项目建立了一个有趣的开端，那就是，如果我们以思考分布式系统设计和架构的相同方式来思考以人为本的过程和工作流程会怎样？
它将为我们提供一些熟悉的工具来记录和/或分析流程，就像某些流程教练喜欢进行的“工作流”工作一样。（我称他们为“流程”教练，因为他们中的一些人这样做是为了服务于敏捷工作，而其他人这样做是为了服务于不受敏捷宣言指导的工作。）
当工作离开个人、团队或组织时，它有助于设定一些期望。（换句话说，如果你把它交给另一个团队，与你自己做的事情相比，最好预计在得到回复之前会花费更长的时间。）
我们可能希望避免个人之间的“闲聊”交流，并且如果我们需要快速处理某些事情，我们绝对希望仔细考虑团队之间的这种交流。
最重要的是，我们有必要寻找方法将所有从事某一特定大型任务的人员聚集在组织结构图上相对靠近的位置，以最大限度地减少团队之间的延迟（#2）和传输成本（#6）。