去中心化架构需要的不仅仅是自治

引言：超越自治的幻想

去中心化架构通常被认为是一种技术设计选择——服务边界、团队 API、基础设施独立性。但纸上谈兵的的自治并不能保证实践中的一致性。

当架构变成分布式时，挑战不仅仅是系统如何设计——而是如何在团队之间做出、共享和信任决策。

在我的组织中，随着我们迅速发展并整合了多家新收购的公司，这一现实变得越来越清晰。

团队在理论上得到了授权，但在实践中仍然举步维艰。架构师成为了瓶颈。开发人员要么等待许可，要么单独做决定。自治存在，但信心并不存在。

Andrew Harmel-Law 的《促进软件架构》为我提供了解决这一差距的语言和途径。

这本书提供了轻量级、基于信任的实践，如架构建议流程（Architecture Advice Process）、架构决策记录（Architectural Decision Records，ADR）和建议论坛（Advice Forums），这些实践可以帮助组织在不依赖集中控制的情况下构建技术一致性。

本文反映了我对 Andrew Harmel-Law 的《促进软件架构》（2023）的个人解读，以及在现实世界中，它在收购后的工程环境中的应用。

本文分享了我们如何在一个真实的多团队工程环境中开始应用这些想法。这不是一个成功的故事——而是对从控制转向信任、从审批转向建议、从孤立转向可见性时发生的事情的反思。

接下来是一系列的经验教训、工具和文化转变，它们帮助我们向更有弹性的、去中心化的架构演进——在这样的架构中，自治是通过共享理解赢得的，而不仅仅是由组织架构图授予的。 

真正的问题：大规模决策制定

去中心化架构不仅仅是系统设计的问题——它是一个关于决策如何制定、由谁制定以及在什么条件下制定的问题。理论上，去中心化赋予了团队权力。实际上，它经常暴露出一个隐藏的弱点：决策不容易规模化。

随着我们的团队迅速扩张，组织结构变得更加复杂时，我们会开始感受到裂痕。随着团队的增加，架构一致性开始受到影响——不是因为人们不在乎，而是因为他们不知道如何或何时参与架构决策。架构师成为了瓶颈，开发人员要么等待方向，要么做出引入长期摩擦的孤立决定。

这个问题比许多人意识到的要早。每个架构决策都经历了三个阶段，使用我们发现的一个有用的简单三阶段模型：

• 需要做出决策——认识到需要做出选择

• 决策发生——评估选项并选择一个

• 决策执行——将决策付诸实践

第一阶段——识别决策点——经常被忽略。通常情况下，只有一条“明显”的路径，而完全跳过了生成或比较替代方案的机会。这使得架构感觉不透明和无力，特别是当选项是闭门决定的时候。

即使团队确实意识到了决策点，在不同团队之间扩展决策过程也会增加复杂性。没有放之四海而皆准的方法。我们意识到去中心化并不是我们的目标，而是限制。真正的目标是在合适的人参与的情况下快速做出好的决策。这意味着要有意地：

• 谁可以启动、制定和实施决策

• 我们如何提出和比较选项

• 何时介入——从谁那里介入

没有这种结构，自治就变成了一种负担。

这一洞见成为了我们的转折点。认识到我们的决策模型——而不是我们的技术栈——限制了我们的速度，促使我们采用新的实践，在不失去一致性的情况下支持分布式决策。第一步是将寻求许可替换为寻求建议，我将在下文探讨。

信任胜于控制：重新定义治理

大多数工程组织都在谈论授权，但他们的架构流程仍然依赖于隐性控制——谁可以决策，谁需要批准，以及如何紧密地跟踪一切。要使去中心化发挥作用，这种模式必须改变。

一个有助于阐明这种转变的模型是架构建议流程：一个基于信任而不是权威的决策模型。

该流程遵循一条规则：

任何人都可以做出并接受架构决策，只要他们：

1. 向所有受到决定影响的人寻求建议

2. 向有相关经验的专家咨询

这不是请求许可的问题。这是关于寻求知识，并快速做出明智的、负责任的决策。

这种转变很重要。我们不再问“谁批准这个？”而是开始问“在我们这样做之前我应该和谁谈谈？”

这种从许可到建议的重构成为了一种文化解锁。

我们意识到我们真正需要的不是更多的认可，而是更清晰、更一致和更多的合作。

这种模式并不意味着无拘无束。它依赖于专业性和相互问责，而不是等级制度。当决策者公开寻求建议时——而建议者以深思熟虑、基于经验的意见作为回应——团队就会建立信任。

通过强调透明性而非控制，我们为更好的对话、更清晰的所有权和更快的进展创造了空间。

付诸实践：架构建议流程

从控制到信任的转变需要的不仅仅是思维方式——它需要实践。我们采用了一套轻量但强大的工具集，使分散决策在真实团队中发挥作用。其中最重要的是架构决策记录（ADR）。

ADR 常被误解为文档工件。但在实践中，它们是建立信心的工具。它们使架构思考变得可见，加强问责，并帮助团队做出明智、可信的决策——而不依赖中央权威。

为什么 ADR 重要

分散的团队经常面临三个主要的信心差距：

• 对自己和他人做出合理架构决策的信心

• 对建议流程的信心——即征求和考虑了反馈意见

• 随着时间的推移，理解决策的信心，特别是当上下文逐渐淡去时

一个精心制作的 ADR 有助于填补所有这三个差距。它为未来的读者提供了一个清晰的视角，了解为什么做出决策，考虑了哪些选项，以及咨询了哪些人——当决策在许多团队中分发和演进时，这是至关重要的。

ADR 是什么

ADR 捕获了一个单一的架构决策及其周围的上下文。一旦最终确定，它是不可变的（尽管可以被取代）。它是为未来的团队成员编写的，而不仅仅是为当前的利益干系人。它应该容易浏览以查找相关性或深入挖掘以获取详细信息。

关键组成部分包括：

• 标题和 ID ——清晰且唯一可识别

• 状态和日期——指示做出决定的时间

• 上下文——解释问题或触发因素

• 选项——列出 3-5 个真实、深思熟虑的替代方案——不仅仅是稻草人

• 决策结果——列出选择的选项及其原因

• 收到的建议——捕获从被咨询者那里得到的原始建议

不要排除被拒绝的选项——“不采取行动”也算——拒绝仍然是一个决策

这种结构不仅仅是为了记录保存。它通过将决策直接与影响它的建议联系起来，加强了架构建议流程。

使 ADR 在实践中发挥作用

在我的组织中，架构决策通常存在于 Slack 线程或走廊对话中——容易丢失，难以重新访问。我们非正式地应用了部分建议流程，但没有结构或可见性。即使引入的是一个轻量级的基于标记的 ADR 流程也能立即使问题变得清晰。

一些对我们有帮助的实践：

• 从问题开始。在列出解决方案之前，先进行上下文的头脑风暴。

• 尽早寻求建议。特别是在框架和范围上——不仅仅是选项。

• 使其可见。分享咨询了谁以及学到了什么。

• 做临时决策。这些都可以在不阻碍进度的情况下获得反馈。

将 ADR 存储在工作附近——在 GitHub 存储库、内部维基或项目文档中——使它们易于访问。我们将它们视为架构思考的活档案，而不仅仅是决策。

不仅仅是文档

对我来说，最突出的是，ADR 不仅仅是关于记录保存——它们是关于信任的。它们帮助弥合设计系统的人和生活在决策后果中的人之间的差距。它们为新团队成员提供了一条进入先前决策的路径，并有助于避免重复相同的对话。

最重要的是，ADR 反映了建议驱动架构背后的文化转变。它们向团队展示了决策不是在孤立地或通过命令做出的，而是通过透明、包容和有意识的流程做出的。

通过建议论坛创建共享上下文

当决策不是孤立发生时，分散架构的效果最好。即使有良好的个人实践——如 ADR 和寻求建议——团队仍然需要共享空间来建立信任和组织范围内的上下文。这就是架构建议论坛的用武之地。

我们实施了一种称为建议论坛的做法，它提供了一个轻量级的结构，支持分散决策而不重新引入控制。它们不是治理检查点。而是是学习、对齐和定期公开建议的机会。

建议论坛是什么（以及不是什么）

一个建议论坛是：

• 一个定期讨论进行中的架构决策的会议

• 一个寻求建议的讨论，而不是审批或达成共识

• 一个团队展示、专家建议和观察者学习的地方

这不是关于把关或减慢团队的速度。相反，它提供了透明度和对架构思考的分布式可见性——在具有多个团队或领域的组织中特别有用。

论坛的核心宗旨

建议论坛有三个主要目标：

• 提高对正在进行中的决策的可见性

• 通过透明、实时的讨论建立信任

• 为参与者和观察者创造学习时刻

当这些对话公开进行时，它们促进了心理安全，提高了思考的敏锐度，并减少了重复劳动的风险。这也加强了责任感——知道他们将分享工作的团队会更有意识地思考他们如何构建和证明决策。

它是如何工作的

论坛是有组织但非正式的：

• 提前分享议程，并附上草稿 ADR 的链接

• 团队简要介绍决策、背景和他们寻求输入的领域

• 建议在现场或之后提出——总是记录在 ADR 中

• 沉默被视为有意不参与，而不是被动的认可

至关重要的是，论坛本身并没有做出任何决定。决策的责任仍然由最接近工作的团队承担。但论坛扩大了支持，挑战了盲点，并揭示了值得更广泛探索的模式。

为什么这样做有效

使这种实践有效的不是会议，而是思维方式：

• 它规范了开放的架构思维，而不是幕后的审批

• 它可以在不强制一致性的情况下实现跨团队对齐

• 它培养了一个好奇的社区，而不是控制

像“联合论证”（coalescent argumentation）这样的概念——在探索分歧之前，团队承认共享的理解——有助于保持对话富有成效。团队不仅了解其他人正在做出什么决策，还了解他们是如何思考的，他们考虑了哪些权衡，以及为什么他们最终做出了这样的决策。

在我自己的反思中，我发现这种做法特别引人注目。在许多组织中，伟大的技术工作是在孤岛中进行的。建议论坛有助于打破这些孤岛，而无需施加重量级的流程。它为那些想要接触架构但还没有能力这样做的开发人员和团队创建了一个可见的入口。

实施技巧

一开始，你不需要从整个公司入手。从小处做起：

• 创建一个共享的 ADR 模板和存储库

• 清晰地定义论坛的范围和期望——例如，一页的参考条款

• 强调学习和交付，而不是仪式

• 可选但要有价值

如果做得好，建议论坛将成为架构意识的中心。它们帮助组织从孤立的团队做出孤立的决策，演变为一种开放、共享和持续改进的架构文化。

从审批到对齐：观察到的文化转变

寻求建议的转变改变了我们的流程——也改变了人们的行为。

在采用架构建议流程之前，我们的架构功能已经成为瓶颈。团队等待。架构师感到不知所措。我们做出决定的时候往往太迟，或者所处的上下文太少。每个人都等待别人做出决策。架构师越是集中，他们之间的联系就越少。

我们抓得太多，也抓得太紧。这表现出来了，就是团队被困住了。架构师对那些他们做得不够好的决策负有责任。

我们以责任分担制度取代审批瓶颈。团队开始主动解释他们的决策，让正确的人参与进来，并在流程中建立更多的信心。不是所有的事情一夜之间都能变化的，但随着时间的推移，这些模式出现了：

• 更多的开发人员编写 ADR，即使是小的或内部的决策

• 架构师不再默认拥有所有权，而是开始专注于支持

• 对话变得更加深思熟虑，不再那么政治化

这不仅仅是一个流程上的改变。这是一种行为重置——从允许到存在，从控制到指导。它为更具包容性、透明度和弹性的架构实践创造了空间。

结论：一个有凝聚力的自治文化

分散的架构只有在有意识的实践基础上才能发挥作用。像架构建议流程、ADR 和建议论坛这样的工具不仅帮助我们更快地前进——它们帮助我们共同行动。

从我的经验以及 Harmel-Law 的书中学到的最清晰的教训之一是：

“分布式架构更具社会性，而不是技术性。”

仅仅分配系统责任是不够的——你还必须分配信任。这意味着用指导和透明度取代命令和控制。这意味着将架构师的角色从审批权威转变为值得信赖的同行和可见的合作者。

“架构师不需要更多的权力。他们需要更多的存在感。”

如果你在一个成长型或分布式的组织中工作，考虑试行一下这些实践中的一个。从小处开始。尝试一个轻量级的 ADR 模板。建立一个非正式的建议论坛。将决策从审批转变为建议。

去中心化不仅仅是一个架构模式——它是一个文化承诺。它始于我们选择如何做出决策。

原文链接：

https://www.infoq.com/articles/decentralized-architecture-advice-process/