Xapo 银行的架构实践去中心化

介绍

软件架构在构建软件系统实践中的作用一直存在争议。在大多数组织中，您都会发现某种“架构”功能，通常被称为“企业架构”。这通常是一个集中化的团队，其目标是确保所有构建的软件都符合行业和公司标准，使用适合问题的模式和技术，针对问题空间进行优化，根据需要进行扩展，并避免任何不必要的重复。事实上，在任何领域和任何有意义的规模内构建任何有价值的软件时，都需要考虑所有这些方面。

通常，此架构功能会承担所有系统更改的架构设计工作，通常（但并非总是）与最终实施解决方案的开发团队隔离。这些设计完成后，就会交给开发人员进行实施。几十年来，许多组织都是这样运作的。那么问题出在哪里呢？让我们列出一些问题

• 集中控制将知识保留在构成架构功能的人员手中，从而剥夺了实施团队的相同责任。这扼杀了创造性思维和好奇心，以及对运行中的系统做出反应的倾向。对于实际构建系统的团队来说，架构实际上是“别人的问题”；
• 因此，创建架构设计的团队可能远离实施的第一线，无法识别与特定领域相关的真正挑战。他们也没有接触到其设计在包含的生态系统中运行时产生的不可预见（和不可预见）的后果；
• 这会导致开发人员和架构师之间出现长反馈循环，导致交付延迟，并且经常导致架构和设计不足或不合适；
• 最终，架构功能成为瓶颈，因为他们必须管理架构更改，并从整个组织的无数结果中学习，从而导致排队时间过长。

当您将 2020 年的全球大流行纳入其中（以及系统现在越来越分布式，并且不断地以增量方式发展）时，这些挑战会成倍增加。越来越多的组织转向更远程、更灵活的工作方式。传统的面对面协作论坛，知识保留在少数人手中，已经崩溃。对决策背后的理由的理解消失了，集体知识中出现了差距，结果往往是糟糕的软件设计，甚至更多延迟。

当然，这些挑战在大流行之前就存在，但是，我们最近在人们工作方式上发生的全面变化，揭示了旧的关于软件架构的集中化思维方式的缺陷。

Xapo 一直以去中心化和完全远程的方式运作，但在大流行来袭时，他们加大了去中心化的力度，但目标是不损害架构质量、对变化的响应能力或概念完整性。

一些历史背景…

Xapo 成立于 2014 年，最初提供比特币服务，包括托管钱包、交易、支付和冷存储，面向零售和机构客户，成为全球最大、最值得信赖的比特币托管机构。2018 年，为了实现“保护您的毕生积蓄”的使命，Xapo 决定成为一家获得完全许可和监管的银行和 VASP（虚拟资产服务提供商），利用其在直布罗陀的 GFSC 监管下的存在。这种方法的转变使 Xapo 能够在完全监管的环境中提供传统的银行服务，包括美元借记卡，以及比特币服务。2020 年，Xapo 获得了银行和 VASP 许可证，新 Xapo 银行的建设工作开始了。

随着 Xapo 从电子货币转向完整的银行和 VASP 商业模式，其大部分现有软件资产能够被重新利用。但是，正如您所料，自 Xapo 成立以来的六年里，技术债务、紧密耦合和服务凝聚力低的负面影响对交付速度和变化速度产生了重大阻碍。更改通常会影响多个团队，并跨越多个功能和子域边界。更具挑战的是，Xapo 人员分布在 40 多个国家和 25 个以上时区！

团队围绕职能部门（产品、设计、架构、工程、QA 等）进行组织，工作以瀑布式方式流经这些部门。排队和长时间等待很常见，尤其是在需要集中化的架构团队参与、审查和批准所有设计时。

经验丰富、才华横溢的工程师正在创建新颖且高质量的软件 - 很明显，这里的挑战与他们的技能或努力无关。流程和组织已经发展，试图做正确的事情并确保持续的质量，但是，无意中，该系统和相关的控制现在正在减缓进度。Xapo 如何创建一个组织和系统，让个人贡献者充分发挥他们的潜力，提高流动性，减少摩擦，同时维护甚至改进我们的软件和架构？

最后，值得注意的是，之前曾努力定期召集 Xapo 的集体智慧，以做出架构决策。名为“雅典娜”，它允许工程师提出、讨论和决定架构和设计问题。虽然最初参与度很高，但它已经失败了。讨论变得越来越冗长，无法达成结论，因此，取得进展所需的决策很少做出，或者如果做出了，也会在随后的几周讨论后被撤回。

打下基础

很明显，需要采取措施来减少开发工作流程中的摩擦。此外，为了减少排队和交接，团队能够尽可能独立自主地行动的能力成为关键的成功因素。

Xapo 做的第一件事是从业务领域的视角来思考我们的软件，而不是从技术功能的视角来思考。Noush 和她的团队知道，领域驱动设计 才是最终的解决方案，但她首先粗略地评估了软件如何适应广泛的业务子域（支付、卡、银行业务运营、合规等），并且我们严重依赖于 Matthew Skelton 和 Manuel Pais 的 团队拓扑结构 工作来创建真正的跨职能团队。在几个月的时间里，Noush 和她的团队与产品和运营部门的同事合作，将整个交付组织迁移到业务对齐的流对齐团队 (SAT)。

与此同时，Noush 致力于极大地改善我们的开发人员体验；以前集中化的运营和严格的控制使得创建或更改服务、更改配置或进行任何操作变得令人沮丧且困难，而无需申请工单。为了快速发展，Xapo 工程需要优化我们的流程和工具，以实现团队自治，并在整个生命周期内完全拥有服务。Xapo 改变了平台团队的使命，使其与之保持一致，并开始认真地重构基础设施和工具以支持它。

正是在这个阶段，Noush 聘请了 Thoughtworks。拥有在整个组织中进行这种转型变革的经验丰富的专业人员，其目的是加速这种变革，同时支持我们的工程和产品人员，并帮助他们在安全的环境中学习这些新原则。

我们共同为工程奠定了基础，定义了我们的核心工程原则 - 主要重点是构建针对团队自治和减少交接进行优化的软件 - 并将 DDD 作为关键的组织概念进行推广。在此过程中，我们继续进行向 SAT 的迁移工作，更详细地思考我们的边界上下文，并将它们越来越紧密地与团队对齐，为我们的路线图提供信息，并逐步改进我们的底层架构。

这些基础意味着我们知道我们想要去哪里，以及大致如何到达那里，但如何作为一个完全远程的、快速增长的、以增量方式变化的组织来做到这一点，是下一个挑战。

作为一个组织，Xapo 需要在更异步地工作方面做得更好。作为一家全球性的、完全远程的企业，它面临着一些在集中在少数几个办公地点的组织中不存在的挑战。我们如何确保所有团队成员都拥有相同的总体目标和理解？我们如何管理时间，以便工程师能够以最适合他们的方式优化他们的工作日？我们应该如何支持新团队成员的入职，并帮助他们了解我们做出的架构决策的背景、推理和约束？与 Thoughtworks 技术主管 Andrew Harmel-Law 合作，并借鉴他的博客文章，我们旨在实施一种去中心化、对话式和咨询式的架构方法，使团队能够独立做出决策，同时确保从关键利益相关者和专家那里寻求建议。Xapo 的架构咨询论坛 (AAF) 诞生了。一家围绕去中心化金融准则建立的公司选择以这种方式管理架构，完全去中心化，无需中央审批机构，这似乎是合乎逻辑的。

它是如何工作的

我们遵循的方法在 Andrew 的博客文章中概述：“以对话方式扩展架构实践”。与所有这种方法的实例一样，Xapo 组织的具体情况、我们的人员、我们的软件、我们业务的目标以及我们文化的性质都在最终运作方式中发挥了关键作用。

值得注意的是三个关键因素：首先，Xapo 是一家已经转型，并且 处于全球性重大扩展的早期阶段 的公司。其次，Xapiens 遍布全球。Xapo 真正是一家全球性公司，因此，默认的通信模式是异步的和书面的。第三，这个全球人才库意味着 Xapiens 都是聪明人，拥有丰富的经验，以及许多意见/建议要提供。有些人注意到，这在过去阻碍了快速决策。

我们最初将推广重点放在三个关键领域：架构建议流程、ADR（架构决策记录）和AAF。我们同时启动了所有这些核心元素，并通过一个介绍架构建议流程的会议来实施AAF。我们预先用一些回顾性的ADR来启动会议。这些ADR内容丰富，涵盖了最近做出的一个重大决定，即将某些关键服务迁移到第三方供应商。这至少是所有与会者都感兴趣的事情。

我们精心策划了AAF的邀请名单：来自所有团队的声音都出现了，包括架构、信息安全、基础设施、产品、交付、监管、运营、财务，甚至高管。制定了重点的议程也是关键。除了查看尖峰后跟进的ADR的标准AAF活动外，我们还添加了以下时段

• 团队耦合问题（产品和交付在这里尤其重要 - 如上所述，Xapo已经启动了以团队拓扑为驱动的重组，以配合Thoughtworks的参与，以实现流程对齐），
• 四个关键指标（如DORA DevOps现状报告和“加速”[1]中所述），
• 云支出

在几次AAF迭代之后，我们添加了另一个时段，讨论ADR的进展情况。我们不仅想知道决策的制定速度，还想了解这些决策被转化为代码并发布到生产环境的速度。因此，我们在标准状态集中添加了另一个ADR状态：“已采用”，表示ADR已实施并在生产环境中运行。我们将在下面详细讨论这一点。

这里有一些关于Xapo AAF一般方面的说明。作为一家“异步优先”的公司，Noush不断挑战Andrew最大限度地提高实施的异步性。Andrew最初对此表示反对，因为他看到了对话对所有人的价值，而不仅仅是对那些直接参与对话的人。他本不必担心。面对面的元素 - 每周的AAF会议规模从通常的一个小时缩减了一半，但保持了相同的节奏。AAF的出席率一直很高，对话集中且有价值。预先工作（分享正在进行的尖峰和拟议的ADR以获得早期建议）和后期工作（在AAF中添加面对面激烈对话中提出的建议）都非常认真，ADR的书面记录，包括非常宝贵的建议部分，迅速成为一个很好的资源。Xapo的架构师在Andrew离开后接手了流程的运行，他拥有技术写作的背景，组织能力很强，并且对细节非常关注，这也有助于此。

为什么我们在开始时没有包含架构原则或技术雷达（甚至CFR）？简而言之，它们“并不紧急”。Xapo的工程团队已经制定了书面原则，但更重要的是，这些原则已经存在于Xapien开发团队的脑海中。然而，这并不意味着我们在提供建议的过程中忽略了这些隐含原则的挑战和潜在改进。

雷达也是后来引入的，因为随着越来越多的团队开始进行自我管理，并且团队之间越来越松散，潜在的有价值的分歧和“有限购买”变得越来越明显。在此之前，技术领域一直非常集中（尤其是对于一家前初创公司）：当意识到某件事有用时，Xapiens就会接受它，评估它，并开始使用它。

ADR也经历了有趣的演变。利用上面提到的Xapien架构师中的一位强大的信息管理技能，我们迅速从基于维基的ADR存储库（Confluence）迁移到基于票证系统的存储库（Jira）。为什么？我们已经提到了强烈希望提高决策的吞吐量，从决策到实施和部署的整个过程。将Jira作为我们的ADR中心，使我们能够将“状态”字段及其各种值的转换变成一个数据点。每当打开一个新的ADR票证时，我们都会有一个自动生成的日期戳，并将状态设置为“草稿”。当进入AAF时，唯一的要求是将状态设置为“已提出”，并将添加另一个日期戳。（制作议程也变得更容易 - 我们在页面模板中有一个常设的“所有已提出”查询）。后来迁移到“已接受”也具有其日期戳，当我们添加上面提到的“已采用”状态以指示决策何时被编码并在生产环境中运行时。通过迁移到这个工具，我们没有从团队中拿走任何东西 - 我们仍然有一个票证模板，它使关键的ADR部分一目了然，而不会丢失任何富文本元素。我们还消除了在状态更改时记住更新日期戳的需要。最重要的是，我们仍然驻留在开发人员每天使用的工具中。最重要的是，我们赋予自己运行各种查询并绘制各种图表的能力，这些图表可以洞察事物的进展情况。

我们在这些额外数据中寻找什么？创建的ADR数量是一个有趣的数据点，但关键是从“草稿”到“已采用”所需的时间，无论是总计还是各个步骤。与DORA四个关键指标一样，“决策的提前期”被证明是流程和系统健康状况的可靠指标。所有这些数据点都与团队共享，以便他们能够逐步改进和自我纠正，提出诸如“为什么这个东西在草稿/已提出/已接受状态下停留了这么长时间？”之类的问题。

迁移到Jira还有另一个好处：它与Slack等通信系统的简单集成更加丰富，并且以一种与Xapo的异步文化相匹配的方式集中。新的ADR可以由一个Slack机器人自动宣布。状态更改可以通过相同的方式处理。所有这些都是自动化的，我们免费获得了透明度。不仅如此，通过将实施故事与ADR票证关联起来，我们可以开始看到与ADR及其状态相关的工单。这对于跨团队的ADR特别有用，例如跨多个核心系统改进跟踪路由的ADR。

实现的益处

很明显，AAF/ADR方法从早期阶段开始就非常适合Xapo，并且随着各种元素被塑造成适合Xapo文化，其益处不断累积。我们已经提到了由此产生的几个优势，但还获得了哪些其他益处呢？

虽然不是这种方法的一部分，但跨职能需求（CFR）和技术战略逐渐浮出水面。前者在提出ADR时自然而然地出现，并在发生这种情况时被明确地捕获。它们变得明确的事实使关键的AAF代表能够在相关点上权衡他们的需求，因为这些需求逐渐显现出来。例如，监管部门的代表及其在产品组织中的代表能够在技术论坛中明确说明合规性方面的具体需求。

技术战略的要点也出现了。Noush作为大多数AAF的首席技术官出席，可以分享她对整体技术方向的看法，以及她所面临的约束。然后可以在特定决策的背景下讨论这些问题，这意味着它们不仅与总体战略保持一致，而且战略可以在团队日常现实的严酷考验下进行压力测试。不仅如此，通过接触并鼓励参与这种讨论，总体战略得到了广泛的理解。

团队对原则的体验和一致性也受到了压力测试。我们已经强调了团队及其ADR与核心原则相遇的最突出例子，但这在更小的方面反复发生。与战略一样，团队接触这些对话不仅使他们能够隐式地反馈原则在现实中是如何形成的，而且还能够提出更改建议。因此，与会者可以了解整个组织对这些原则的一致性，不仅是抽象的，而且是在他们交付软件的过程中；这是一个有价值的数据点。

AAF的这种一般“意义构建”能力在更一般的方式上也很强大。前面提到的规模化工作的一个关键方面是向明确的领域驱动架构的过渡。随着工作的进行，每周都在进行，领域语言的流行程度显着提高。虽然最初并不总是清晰的，也不总是与有界上下文保持一致，但它在与特定ADR相关的使用意味着可以针对实际问题提供关于关键DDD方法的建议。这加速了对这些各种模式的理解，但也极大地促进了工程团队对领域驱动设计的更深入理解，启动了一个良性循环：关注领域语言，注意它何时能洞察耦合和其他关键设计问题（例如，当很明显两个团队在以微妙的不同方式谈论同一个领域概念时，或者他们似乎都倾向于实现只有其中一个团队应该实现而另一个团队应该委托的服务时），利用它来讨论这些设计问题，然后部署它们来解决这些问题，从而提高单个团队和整体速度。

引入AAF并不意味着架构师在组织中不再有任何作用。事实并非如此，我们的小团队仍然像往常一样忙碌，提供建议，支持AAF，并将时间集中在对Xapo有重大影响的高影响力项目上。赋予团队权力，让专家在更接近代码库的地方做出决策，这对影响实际变化所需的时间产生了重大影响。过去需要数周（甚至数月！）的设计和决策现在可以在几天内完成，并且有据可查，所有人都能理解，并且成为我们技术社区集体智慧的一部分。架构现在是一种集体责任，任何人都可以分享想法或挑战方法，所有这些都符合我们的指导原则。

经验教训

如果我们给人的印象是，采用这套相互关联的实践、工具、方法和思维方式是容易的或没有挑战的，那将是疏忽的。核心是需要转向一种新的“常识”体系，而这是一种内部的、人类的和群体层面的变化。

最明显的迹象是，放弃共识的舒适感是一件很难做到的事情。您会记得，架构建议流程只有一条规则：“任何人都可以做出架构决策”，并且既不需要达成一致，也不需要寻求更高权力的批准。尽管如此，即使有意识的头脑屈服于这个想法，在一次又一次的AAF中，人们还是会听到“那么，我们都同意吗？”这句话，这只是在讨论结束时脱口而出。虽然这表明向新思维方式的转变尚未完成，但对这种无意识需求的表达确实使我们能够提醒与会者，共识不是必需的，决策可以在没有共识的情况下做出并采取行动。

另一个信号是追求与原则一致的“完美”（无妥协）解决方案。虽然这种情况发生的次数要少得多，但最初很明显，那些在决策方面经验不足的人认为，那些过去拥有这些责任的人，“架构师”，可能只是在智慧方面像圣人一样，并且能够找到通往所有世界最佳的道路。对权衡的明确关注，以及架构师对权衡的建议，慢慢地解开了这种思维方式，当这些权衡开始被明确地记录在ADR中时，就实现了真正的解决。将这一点公开意味着所有相关人员都能理解，不仅这种妥协是可以接受的，而且是不可避免的。例如，人们认识到，在优化Xapo服务以实现团队自主的过程中，工作正在重复。这是一件坏事吗？不一定。协调和同步的开销往往大于消除重复带来的好处。讨论中提出的重点是，在某些情况下，重复会导致用户体验不连贯。在这种情况下，好处明显大于对齐工作带来的弊端。事先考虑这一点，并且作为一个集体，在权衡取舍时，有助于极大地确定重点。

决策也从始终置于商业决策的背景下获益良多。许多时候，决定哪种选择是“最佳”的决定性因素归结为产品或商业策略。在 AAF 会议中拥有产品代表意味着他们拥有所有可用于待定架构决策的背景信息，并可以相应地分享他们的建议。这里一个很好的例子是基础性的产品和设计决策，即无论移动应用程序在何处使用、由谁使用，最重要的是无论平台如何，都应拥有统一的、通用的用户体验。为了确保 iOS 和 Android 体验在所有地方保持一致，需要付出大量的努力，如果没有这种产品指导，这将是巨大的浪费。然而，由于它对整个产品理念和体验至关重要，因此它必不可少。了解这一点，团队可以非常迅速地做出多个战略一致的决策，而带来的好处是，所有在场的人都知道原因。

同样值得指出的是这种定期同步跟进的更普遍的好处。决策不仅有效地收集了所需的建议输入，而且（更重要的是）所有在场的人，无论决策是否与他们相关，都接触到了 Xapo 业务和集体推理过程的具体细节。这在异步返回工作时带来了巨大的益处，团队对 Xapo 正在开拓的道路的细节和微妙之处有了更深入的了解。这至关重要，因为没有指导和方向的团队自主权会导致混乱。像建议流程（包括责任）这样的约束帮助 Xapo 解放了自己，减少了我们的工程师需要考虑的大量事情。认真思考 Xapo 的技术支柱和原则也是一个关键的成功因素。有了这种普遍的协调和共享的理解，并通过简短的 AAF 每周加强和更新，所有团队在其专注时间内交付价值的能力令人印象深刻。

这些高价值、高影响力的每周会议还有另一个好处：它们让大家可以安全地改变主意，偶尔也会犯错或失败。从 CTO 到每个人都为这种模式做了榜样。例如，随着团队共同了解了领域驱动设计 (DDD) 的工具，并看到了 Xapo 的软件如何体现 DDD 的许多模式，有必要将服务重新分配给不同的团队，或对其进行重构以与更合适的团队及其边界上下文保持一致。这并不是说团队拓扑结构转型开始时团队拆分的第一次尝试与理想情况相差太远，但它可以承受增量改进。 [2] CTO 是最初决定这些团队以及软件分配的人。通过根据 ADR 中产生的学习成果，并部分由这些学习成果驱动，对这些责任边界进行重构，人们亲眼看到了设计，包括组织设计，不需要第一次就正确。

为了让这一切都能正常运作，很明显，持续、定期地管理 ADR 积压工作和明确定义的 ADR 所有权非常重要。此外，内部推广完整方法的好处，无论是在技术内部还是外部，都让大家能够牢记它并看到它的好处。由于 Xapo 的异步和全球性，决定专门安排一个人全职负责推动工程团队和其他部门之间的协作，以确保这一点。

一个有益体现的例子是重新审视各种 ADR。所有决策都是在特定时间做出的，应该努力尽可能多地捕捉到该上下文的具体细节。当明确地知道这种决策上下文将在未来某个时间点发生可预测的变化时，可以安排重新评估。当 Xapo 做出非战略性托管决策时，这种情况就发生了，因为它是当时唯一可行的选择。一段时间后，重新审视了这个决定，并进行了另一个后续 ADR，以将事情恢复到正轨，并迁移到战略云提供商。

在结束本节之前，重要的是要强调一个关键事实：AAF 和架构建议流程从未孤立存在。在 Xapo，前期奠定的基础产生了重大的积极影响，现有的 Xapien 文化的优势也是如此。团队明显受益于向团队拓扑结构式组织结构的转变，同时关注产品思维、持续交付基础设施以及 DORA 四个关键指标提供的数据。从功能性团队转向流对齐团队 (SAT) 模型在纸面上看起来很简单。实际上，对于任何组织来说，这都是一个巨大的变化，Noush 和他的团队花时间和空间让它扎根并开始良好运行非常重要。

Noush 和 Kamil 在 Thoughtworks 离开 Xapo 后，在采用 AAF 期间学到的一个重要教训是，它需要持续的关注和维护。仅仅创建一个论坛或结构不足以确保其持续成功。相反，它需要定期评估和支持来保持其势头和影响力。这意味着我们必须鼓励参与，提供资源和指导，解决出现的任何问题，并适应不断变化的环境。只有通过持续地培养和完善我们的方法和成果，我们才能确保它在长期内对 Xapo 仍然有效和有价值。

下一步是什么？

AAF 和建议流程无疑为 Xapo 带来了许多好处。然而，我们工程团队不能自满，我们正在寻找继续改进的方法。这是一个继续改进软件开发实践和文化的机遇，在发布时正在考虑几个机会。

Kamil 正在寻求将内部开源模型正式化，这将允许团队跨边界上下文进行贡献。这将使开发人员能够跨团队共享代码和最佳实践，减少重复工作，并为知识共享提供绝佳的机会。通过利用我们开发人员的集体知识和专业技能，我们可以加速创新，进一步提高代码质量，减少排队和摩擦。

Kamil 和团队也认识到继续努力改进和迭代开发人员体验 (DevX) 和工具的重要性。通过投资于简化开发和减少摩擦的工具和流程，Xapo 可以使我们的开发人员能够更高效、更有效地工作。

整个 Xapo 工程团队将继续开发和完善我们的技术原则，以确保它们与不断变化的业务目标和优先事项保持一致。通过定期审查和更新我们的原则，我们可以确保它们保持相关性，并为我们的开发工作提供指导。

每个人都将 AAF 的实施视为我们持续改进软件开发实践和文化的旅程的开始。通过追求这些举措，开发人员可以更协作地工作，尝试新想法，更高效地工作，并做出更明智的决策。这最终将帮助我们更快地交付更好的软件，并支持我们更广泛的业务目标。