从迪卡侬的架构流程看如何管理大规模软件架构

迪卡侬资深工程师 Raphaël Tahar 最近分享了他在大规模架构流程中进行协同领导的洞见。在四篇系列博文中，Tahar 描述了如何通过结合架构委员会、C4 模型和系统思维等方法，以及强调 ADR 和集中文档的重要性，来确保迪卡侬的团队能够做出明智且具有战略性的决策。

他所在的团队为超过 120 名工程师提供支持，这些工程师分布在 23 个团队中，是迪卡侬全球 1500 多名工程师的一部分。为这种规模的开发者提供支持并非易事，涉及为设计新系统、优化现有系统以及确保与全球战略对齐提供专业支持。为此，迪卡侬成立了一个架构委员会，该委员会在引导团队评审复杂决策过程方面发挥着至关重要的作用。

Tahar 利用垃圾桶模型来阐释架构委员会的重要性。这个在 20 世纪 70 年代发展起来的模型将组织决策描绘为一个混乱的流程，其中问题、解决方案和决策者分散在不同的流程中。这些流程以不可预测的方式相互交织，就像垃圾桶中的杂物一样，而决策的机会就是在这种动态中孕育出来的。

然而，根据 Tahar 的说法，这种“垃圾桶流”缺乏三个要素：决策替代方案、后果以及后果与目标的对比。

组织必须确保充分考虑了这三个要素，如果忽视了这些，项目延期、否决和反弹（例如不可靠的服务招致的罚款）的风险将大幅上升，进而可能导致巨大的预算浪费。

垃圾桶模型及其缺失的要素（source）

架构委员会介入正是为了填补这一空白。它的职责不在于代替软件工程师做出架构决策，而是提供必要的支持和指导，类似于一个建议流程。委员会帮助工程师明确和深化他们的问题理解与背景分析。它确保涉及正确的利益相关者，识别可能的解决方案，并筛选出最合适的替代方案。委员会成员深入理解每种解决方案的潜在后果，确保这些决策与迪卡侬的技术战略和指导原则保持一致，并借助 C4 模型，通过架构决策记录（ADR）和图表即代码（Code as Diagram）的方式记录下所有的决策。

迪卡侬利用一系列关键绩效指标（KPI）来评估架构委员会的成效。其中一项核心指标是工程师的满意度，这通过净推荐值（NPS）调查来衡量，反映团队在知识共享和识别潜在盲点方面的信心水平。

此外，委员会还密切关注对服务等级目标（SLO）的影响，特别关注与组织优先事项一致的关键指标，如高峰时段的系统可靠性。此外，委员会还评估其对 DORA 指标的影响，包括部署频率、变更前置时间、变更失败率和服务恢复时间。这些 KPI 有助于衡量委员会在提升部署效率和降低运营问题方面的贡献。。

迪卡侬采用 C4 模型 来明确界定软件架构的范围和边界，有效管理架构的复杂性。根据问题的不同规模采取相应的方法来简化复杂度。还原论方法将问题分解为更小、更易于管理的任务，而整体论方法则强调理解系统内部的相互依赖性，这两种方法对于做出有效决策都至关重要。通过结合系统思维和这些方法来梳理相互交织的问题和解决方案之间的层次结构。

最后，架构决策记录（ADR）提供了一种结构化的方式来记录决策的背景、考虑到的可选项、决策结果及其潜在影响。这种文档确保决策是可追溯的，促进了知识的传递，并有助于避免重复过去的错误，因为记录架构决策对于维护大型组织的一致性和连续性起到了关键作用。迪卡侬使用 Structurizr 来存储 ADR，该工具支持“图表即代码”，并将文档集中管理，从而促进团队协作和保持一致性。

Structurizr 自动生成的页面示例 (source)

InfoQ 与 Tahar 就迪卡侬的架构流程、相关挑战和组织影响进行了交谈。

Raphaël Tahar: 在运营架构委员会的过程中，我们面临两个主要的挑战。第一个挑战是确保一个庞大且多样化的组织，尽管涉及不同的职业角色并经历着人员的更替，仍然能够与我们的过程保持一致。

第二个挑战确保在关键时刻通知资深工程师，让他们知情参与，以协助在项目的功能性和技术探索阶段做出调整。鉴于我们有大量的倡议，但只有五名 Staff Engineer，所以并不总是能够让他们都参与每个倡议。

此外，我们资深工程师的专业特长以及在新倡议中不均衡的工作负载分配进一步增加了复杂性。为了解决这个问题，我们让工程副总裁、总监、集团产品经理、工程经理和技术领导也参与委员会的工作。

Tahar: 量化架构委员会的影响力确实具有挑战性，这主要是因为它的作用是间接的。委员会的任务是影响团队，然后团队再影响他们的产品，最终影响业务。为了有效评估委员会初期影响，对每个步骤进行细致的监督至关重要。

通过从工程团队那里收集反馈，我们能够做出必要的调整，并澄清一些细节。例如，我们发现委员会需要关注的具体变化缺乏明确的定义，因此经过多次迭代才得出了准确的界定。这个过程还帮助我们识别并解决了一些虽小但至关重要的考虑因素，例如确定审查、研讨会和接触点的最相关时间段和最佳节奏。在委员会的最初几个月内收集这些反馈至关重要，之后应每季度进行一次。

最后，我们通常可以在决策后的六个月到一年内评估业务影响。决策必须被实施和部署，产品必须在生产环境中运行一段时间，才能看到对业务的影响。

Tahar: C4 模型本质上是一种声明性方法。它要求团队成员明确并协调他们对代码、组件、容器乃至整个应用上下文的认知模型。这个过程激发了富有成效的讨论，促进了知识的共享和对固有信念的重新审视。

它还有助于领导层深入理解团队与外部系统之间的相互依存关系。换句话说，它有助于识别潜在风险，并为组织优化提供了清晰的视角。

最后，正如俗话说的，“一张图胜过千言万语。” C4 模型通过标准化的方式捕捉和分享上下文信息，极大地促进了跨团队和跨领域的沟通，使得讨论更加流畅和高效。

Tahar: ADR 通过在文档中详细记录决策背景，减少了模糊性和误解。它还有助于揭示在书面表达过程中可能存在的思考上的漏洞或偏见。

考虑到我们有 23 个团队，可能产生大量 ADR，所以我们希望避免不必要的信息过载。因此，C4 仓库仅记录 C1 和 C2 级别的变更，而 C3 和 C4 级别的决策则应整合到相关的代码库中。这种策略限制了 ADR 的数量，集中关注最关键的决策，有助于理解背景和产品演变背后的深层次原因。

查看英文原文：

https://www.infoq.com/news/2024/07/decathlon-architecture-process/

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