构建大规模自治体系

去中心化的决策并非什么新范式；几个世纪以来，它塑造了自然界、经济学和人类社会的各种系统。一个经典的例子是红收获蚁群——这个系统展现出了复杂而高效的行为，但没有任何一只蚂蚁，甚至蚁后，指导日常活动。

每只蚂蚁都依赖有限的局部信息进行操作：触角接触的频率、信息素的强度和环境信号。从这些简单的输入中诞生了复杂的模式。

任务分配、信息共享和任务切换从局部互动中自然形成。当食物来源丰富时，蚂蚁会用额外的信息素加强路径，形成一个正反馈循环，吸引更多的蚂蚁——没有任何“管理者”分配工作。结果是形成了一个高度适应性的蚁群，能够实时响应条件的变化。

如果蚁群可以在没有中心指挥官的情况下协调成千上万的行为主体，那么大型工程组织能否做到同样的事情呢？还是我们注定只能依赖架构“象牙塔”来抵御混乱？

多年来，架构的构建一直是围绕集中式控制——一个必要的权威通过自上而下的决策来强加秩序。

在早期，这个模型还行得通。但随着组织规模的不断扩大，这种曾经可以提供清晰度的东西往往变成了阻碍。原本旨在防止混乱的机制变成了阻碍进步的瓶颈。

本文提出了一个用于架构去中心化的实用框架，通过采用清晰的决策边界、共同原则以及“护栏”（而非“门禁”）来对齐局部决策，实现大规模一致性。

架构瓶颈

集中化的架构决策就像分布式系统中的集中式锁：在规模小时有效，但会随着复杂性的增长而变成瓶颈。这在小型组织中可能是有效的，比如在工程初期阶段，或是需要在有限的时间内证明价值并设定方向的时候。

在成熟的环境下，集中式决策可能会引入新的问题：

• 推迟上市时间：当每个重要决策都必须通过中心权威时，交付管道变成了队列。

• 上下文盲目性：中心架构师可能没有各个团队所拥有的深入的、快速演变的领域知识，导致了次优或不一致的决策。

• 象牙塔效应：当团队感知到架构决策与实际约束脱节时，信任被侵蚀，摩擦增加。

随着领域复杂性的增长，集中式决策变得越来越难以维持。例如，保险、索赔、计费、政策管理和承保等行业有着不同的约束和工作流。没有哪个中心团队能够拥有所有领域的深厚专业知识。

去中心化并不意味着无拘无束。这是一个进步的过程：从依赖中心团队批准，到在共享原则和平台上相互独立，再到最终的相互依赖，中心团队和领域团队作为同行开展合作，共同确立架构方向。

父母的隐喻：成长框架

将架构师视为父母是一个有用的思考角度。有效的育儿不是控制每一个动作，而是设定边界，培养判断力，创造学习的安全空间，并逐渐转移责任。

成长不仅适用于团队，也适用于组织，以及架构师自己。随着组织规模的不断扩大，系统和建筑角色都要经历不同的演变阶段：

• 婴儿期（初创公司/早期产品）：在强有力的中心指导下构建模式、标准，并防止早期混乱。

• 青春期（扩展团队和领域）：团队在清晰的护栏内获得独立。架构师从决策者转变为教练员——挑战假设并实现安全的自治。

• 成年期（成熟企业）：自治变得至关重要。架构专注于设计使能系统——共享原则、平台和反馈循环——而不是指导个别决策。

下图突出了随着组织演变，架构自治的不同演进阶段。

图 1：架构治理演进：从集中化的“婴儿期”到去中心化的“成年期”

随着组织的不断成熟，架构师也需要不断地发展方法论。下图通过一个成长框架，展示了这种演变过程，并说明了随着组织成熟，架构自主性如何随之提升。

图 2：架构治理演变：从控制到使能[点击此处放大上图至全尺寸]

真正的风险不是去中心化，而是在系统已经超越这种模式之后仍然停留在控制思维中。

本文提出了一个旨在推动负责任的去中心化进程的结构化框架。该框架围绕以下几个核心要素构建：

• 清晰定义护栏

• 明确决策范围与边界

• 清晰阐述架构原则与指南

• 严格遵循架构决策历史保存规范

• 架构对齐论坛

• 平台部门负责提供规模与速度保证

• 基于成果的 KPI 和适应度函数

• 在企业文化中确立架构师的角色

在本文中，我们将详细探讨这些核心组件，以及人工智能作为赋能型“超级力量”所发挥的作用。

护栏的实际应用：实现负责任的自治

在集中式模型中，架构往往扮演着“守门人”的角色。明确的架构标准能够避免分析瘫痪，并消除代价高昂的干扰，对于资源有限且面临紧迫交付压力的初创企业，这一点尤为重要。在实验空间有限且失败可能危及企业存亡的情况下，集中式指导能提供明确的方向指引，使团队能够围绕统一的目标协同努力。这种有条不紊的专注，在至关重要的早期阶段显著提高了项目的成功率。

当那扇门变得迟缓、遥远或控制过度时，团队的反应往往可以预见：在交付压力下，他们会绕过流程，为了减少依赖而重复开发解决方案，引入未记录的模式，并积累隐性技术债务。

正因如此，架构师的角色必须从强制执行转向消除阻力。在一个健康的去中心化模型中，团队被允许“在后院跌倒”——即在明确的安全边界内进行实验。其目的并非消除失败，而是防止灾难性失败。信任的建立并非依赖于控制，而是通过明确的防护措施、透明度以及可靠的反馈机制来实现。

架构师必须专注于沟通，消除摩擦，并确保所有参与者对系统的目的和设计达成一致的理解——而不是充当把关者或执法者。——Pascal Euhus

只有当防护措施明确、轻量化且可扩展时，去中心化架构才能取得成功。让我们来探讨下去中心化方法的几个方面。

决策边界：每个架构层的自治

一种负责任地实现去中心化的实用方法，是将架构权限与抽象层次相匹配：在 C4 模型中，可能是像下图这样：

这反映了一个简单的事实：本地团队往往最了解底层的复杂细节，而项目组合架构师则更擅长处理跨领域集成、战略规划和企业层面的限制。

架构原则与指南：自治而非无政府状态

架构原则与指南在工程组织内充当大家需要共同遵守的社会契约，从而促成分布式决策。它们阐明价值观、权衡取舍和边界——使团队能够自主运作而不需要不断地获取中心团队的批准。如果没有共享原则，分布式决策可能会逐渐偏离轨道。而当标准过于僵化时，团队又会默认退回到集中式审批。明确定义的原则搭配适应性指南，有助于在允许团队独立运作的同时保持一致性。

请思考以下原则：

数据是组织的战略性资产，必须进行相应地管理、保护和治理。

由此得出以下实践指南：

• 每个数据集必须有一个明确的所有者

• 所有者对质量、生命周期和访问控制负责

• 关键数据元素必须定义可衡量的质量指标

• Schema 变更必须遵循版本控制规则

• 诸如此类

指南将意图转化为行为。它们回答了一个实际的问题：如果数据是战略性的，负责任的行动应该是什么样的？在明确期望并将责任转移到团队之后，架构一致性将不再依赖于集中式决策。如果没有原则和指南，不同的团队可能对好的数据有自己的定义，导致整个组织不一致。

架构决策记录（ADR）：保留意图

架构决策通常呈现多条可行路径，每条都有各自的权衡。在选择其中一条路径时，我们不仅依赖分析，还依赖累积的经验。架构决策记录（ADR）提供了一种结构化的方式来记录当时的选择。

ADR 是轻量级文档，记录决策及其上下文、理由、备选方案和后果。其目的是保留意图：明确说明为什么在特定的时刻选择了特定的路径。

随着系统的演进，决策会被重新审视、完善或取代。ADR 保留了这些选择的动态记录，既支持当时的开发，又便于长期维护。它们帮助回答反复出现的问题："为什么要这样构建？"如果没有它们，上下文会逐渐消失，架构推理就会变成部落知识。

在团队或领域层面维护的 ADR 提供了可追溯性，有助于确保实验安全和基于充分信息的自主决策。征求意见稿（RFC）等补充性实践则通过在决策最终确定之前征集去中心化反馈扩展了这个模型，在不集中权力的同时加强了一致性。

去中心化决策仍然必须可追溯

ADR 的核心价值在于防止将来有团队在继承代码时没有上下文信息。即使在去中心化组织中，决策也不应该变得不可见。ADR 可以确保自治不会以牺牲可追溯性为代价。架构在保持分布式的同时也要保持连贯性。

ADR 协作审查

ADR 最有价值的地方不是作为审批检查点，而是作为可以进行充分讨论的论坛。如果处理得当，审查过程更像是一次家庭会议而非合规性演练——有人指导而无权威引领。其目的不是授予许可，而是加强架构判断力。

需要审查的问题可能包括：考虑了哪些权衡？在规模大或出现故障的情况下该决策会有何表现？它会给相邻领域带来什么风险？它的可逆性如何？

这种对话培养决策能力。工程师学会了将架构推理内化，而不是服从中央权威。随着团队在独立评估复杂性方面越来越有信心，对资深架构师的依赖会随着时间推移而减少。因此，ADR 审查不是固定的治理程序，而是学习机制——培养分布式判断能力而非集中式控制能力。

架构治理论坛：升级和对齐，而非审批

架构治理论坛将 IT、数据和业务利益相关者聚集在一起，协调战略和执行。它充当战略意图与技术交付之间的桥梁。虽然看起来是集中式的，但设计良好的论坛可以实现去中心化。它不是控制决策，而是在需要跨领域权衡时提供对齐、护栏和明确的升级路径。

当运作有效时，论坛能够帮助团队更快、更自信地前进。它为建设性挑战创造了空间，可以及早暴露风险，并确保决策与企业原则和长期方向保持一致。此外，它还有助于就重大架构决策争取各利益相关方的支持。

重要的是，论坛不应该充当审批关卡或象牙塔。其作用是澄清约束、上下文和充当组织的北极星——赋权团队创新，同时保持与共享标准和战略方向的一致性。

构建平台，扩大自治

去中心化自治不能仅凭意图扩展。它需要对共享能力进行有意的投资。没有强大的平台，自治会导致重复、碎片化和隐藏的风险。设计良好的平台将约束转化为可重用的构建块，将护栏转化为嵌入工作流的默认规则。

运营模式很简单：

• 集中化跨领域能力——安全、数据隐私、共享基础设施、开发工具和治理自动化。

• 去中心化领域决策——服务设计、既定约束条件下的集成和本地交付。

平台团队创建技术基础——可重用的基础设施、CI/CD 管道、可观测性和身份控制。当团队承受着比较大的交付压力时，他们自然而然地就会选择看起来最快、阻力最少的路径。如果平台设计良好，那条路也将是最安全的。

这种逻辑不局限于工程。数据治理等功能可以作为共享平台运营，提供数据质量、元数据和管理工具，而领域团队在遵循企业标准的同时保留其数据的所有权。

设计良好的平台将一致性嵌入系统而非会议。它们通过减少摩擦使去中心化具有可持续性，同时保持连贯性。

基于结果的 KPI 和适应度函数

在去中心化模式中，转变微妙而重要：不是控制团队如何工作，而是专注于验证他们产出的东西。随着决策权向团队转移，系统仍然需要某种东西来保持一致性。明确的边界承担了这一角色，在本地自主运作的同时保护整体的完整性。这些边界——护栏——必须清晰描述、客观可验证，并嵌入平台，以便跨团队时也能一致地应用

这就是适应度函数变得必不可少的地方。适应度函数是一种自动检查机制，持续验证系统属性，确保架构特征在系统演进时保持完整无损。适应度函数不是仅在设计时审查架构，而是在构建、部署和运行时进行评估。

示例包括：

• 当安全漏洞超过预先定义的阈值时部署失败

• 对关键数据集强制执行可衡量的数据质量目标

• 监控 SLO 和可用性承诺符合情况

• 验证数据分类或加密策略合规性

KPI 定义了意图，而适应度函数可以在实践中持续地验证意图。当护栏通过编码的方式嵌入到管道、平台工具和可观测性系统中时，一致性便从定期审查转变为持续验证。只有在约束实现结构化、可观测且由系统本身持续执行时，去中心化才是可持续的。

总而言之，在成长框架的背景下，上面讨论的一些核心组件在早期阶段可能不存在或以某种形式存在。但随着组织的不断成熟，这些流程可能会进一步发展，从而赋权团队并实现架构自治。

去中心化不仅会对团队的工作方式产生深远的影响，还可以提升运营效率。

下表总结了去中心化成功运营的影响，在这个过程中，组织从成长框架的婴儿期过渡到成熟期。

连接仪式：从指挥官到教练

当团队陷入各自为政的孤岛时，去中心化模式会失败；而当共同的仪式能维系上下文和信任时，这种模式便能成功。如前所述，ADR 评审和架构论坛与其说是审批关卡，不如说是协作仪式。但这些论坛仅仅是更广泛的文化变革的一部分——这种变革正在重塑架构师的角色以及组织本身。

苏格拉底式架构师

在去中心化组织中，架构师的角色从审批者转变为教练——引导团队考虑权衡、约束和长期后果。架构师不是坐在决策层顶端，而是与团队并肩工作，帮助他们提高推理能力。目的不是集中决策，而是提升判断力。

苏格拉底式架构师不是给出解决方案，而是提出问题：正在优化哪些权衡？当前哪些假设能支撑这个设计？在出现故障或规模变大时，它会有怎样的表现？它的可逆性如何？谁承担运营负担？这样的问题可能令人不舒服——不是因为它们限制自主性，而是因为它们暴露隐藏的假设。这些问题能增强决策能力，帮助团队将架构纪律内化，而非依赖中央权威。随着时间的推移，当判断力变得分散时，依赖性便随之降低。控制让位于探究；权威让位于能力建设。

村落效应

去中心化并没有消除连接，而是加强了连接。随着权威分散，共享记忆对于保持连贯性变得至关重要。实践社区、跨领域论坛和经常性交流使得模式和经验得以在团队间流通。虽然 ADR 记录了决策，但社区保留了决策背后的经验。

随着知识的传播，重新发明轮子的情况减少，自治有了上下文信息的支撑。团队独立运作，但也了解更广泛的系统。在规模比较大时，这种协调节奏变得更为关键。有节奏的规划和利益相关者同步机制有助于及早揭示依赖关系，减少意外和不必要的升级。

在指挥官模式中，协调取决于权威。在村落模式中，协调依赖于共同的理解。自治不是孤立，而是在一个有意识地相互连接的系统中保持独立。

利用 AI 实现去中心化架构

AI 通常与代码生成相关，但其更深层的价值在于加强架构自治。在有明确的护栏和负责任的治理时，使用 AI 可以帮助团队做出明智的局部决策，并与组织保持一致。它不是集中式的权威，而是可见性和判断力的放大器。

设计与决策支持

AI 可以充当设计审查助手，根据既定原则和模式发现安全、弹性、隐私和合规方面的不足。它可以提出替代方案建议，梳理权衡关系，并评估与内部标准的一致性。

它还能加速常见的架构比较——提炼供应商文档，总结内部运行手册，生成结构化输入或 ADR 草稿以供完善。这减少了探究时间，同时保留了人类监督。

组织记忆和依赖感知

通过分析 ADR、存储库、路线图和发布说明，AI 可以发现影响相邻团队的决策，并明确跨领域依赖关系。上下文中包含了以前分散在各个工件中的内容，这有助于减少意外并改善协调机制。

护栏和漂移检测

AI 可以持续地扫描代码、基础设施和运行时信号，检测偏离商定原则的情况——不安全的模式、数据血缘的缺失、监管数据的不当处理或未经批准的集成。通过关联平台标准、ADR 和配置变更，与定期审查相比，它可以更早地发现不符合要求的情况。

目标不是更严格的控制，而是更早的感知。团队保持自治，而 AI 可以帮助团队在偏差成为系统性风险之前发现它们。

培养分布式判断能力

综合来看，这些能力改变了自主决策扩展的方式。AI 不会取代架构师或集中式决策；它增强了决策环境。通过链接原则、平台和实时反馈，它有助于将架构决策的判断力更广泛地分布于整个组织之中。自主决策依然在局部进行，但运作于一个信息日益丰富、透明且有韧性的系统之中。

平易近人的架构师

去中心化架构并不意味着移除架构，而是将其演变为一个可扩展的运营模式——用护栏、平台、原则和反馈循环替代集中式瓶颈。最优秀的架构师，是那些能逐渐让自己不再需要参与日常决策的人——不是因为不需要做架构设计了，而是因为它已经融入团队的工作方式之中。团队在清晰的原则、共享的模式、标准化的平台和他们信任的治理模式之下运作。

不过，可持续的去中心化不仅仅取决于结构设计。它最终会转变为组织转型，而不仅仅是技术转型。它需要领导层的持续承诺和跨组织各层级的协调一致。高管层必须积极倡导从基于审批的治理模式向基于信任的治理模式转变，不仅要投资技术平台，还要投资能力建设、实践社区和文化演进。

这一转型需要务实的态度。自治伴随着“智能失败”。随着团队承担起运营责任，在稳定下来之前，事件发生率可能会暂时上升。各团队的成熟度各不相同——有些尚处在初级阶段，有些处于成长阶段，少数已臻成熟——治理机制必须据此作出调整。如果在团队尚未建立起运营纪律的情况下过早地赋予其自主权，将招致混乱；如果对成熟的团队施加的控制过度，则会导致影子系统和未记录的变通方案的出现。技术提供了工具，但组织能否持续地保持一致，最终决定了这些工具能否带来有意义且持久的结果。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/articles/architecting-autonomy-scale/