如何构建系统设计练习，以训练工程师评估架构权衡方案

一个团队为一个地区性音乐节设计了一套票务预订系统。该系统轻松应对了预期的负载，设计评审也圆满结束。然而，项目需求随后发生了变化：主办方承诺，即使售票期间某个数据中心宕机，售票系统也必须继续运行。这意味着同样的系统现在存在单点故障，设计工程师们必须决定修改哪些功能、放弃哪些功能，以及如何解释这些选择。

这是一个示例场景，并非已记录的事件。系统设计演练旨在模拟这种情况：一个在现有约束条件下运行良好的设计方案，在遇到新的约束条件后，工程师必须给出合理的解释来捍卫或修改该方案。本指南面向工程赋能负责人和工程经理。内容涵盖系统设计演练的定义、构建方法、运行和评分流程，以及培训何时不再适用。所有案例和标准在使用前都应由高级工程师进行验证。

什么是系统设计练习？

系统设计练习（System Design Kata）是一种简短的、限时的设计练习。一个小组会收到一段文字描述的业务问题，然后绘制架构草图，向其他成员展示并回答一些难题。研究人员也称之为架构练习（Architecture Kata）。这种形式最初由 Ted Neward 以工作坊的形式提出，其规则和主持人角色等内容均有文档记录。 Neal Ford 的建筑套路页面纽瓦德提出的那个发人深省的问题（如文中引述的）是：当工程师一生中只有不到六次机会参与架构设计时，组织该如何培养优秀的架构师？而Kata（设计练习）则能让他们在没有生产风险的情况下获得额外的练习机会。

要闻速览

1. 描述性能问题

先从任务入手，而不是从主题入手。任务是在不断变化的约束条件下捍卫架构。在实际工作中，这种情况发生在设计评审、事件跟进和规划会议中，需求会不断变化：流量增加、可用性要求提高、数据驻留规则改变、预算收紧等等。

许多工程师都能设计出合理的架构图。但当两个目标发生冲突时，能够说出自己愿意做出哪些取舍，以及什么样的证据会改变他们的想法的人却寥寥无几。而这第二项技能，正是“kata”（一种设计练习）所要练习的。

写一句性能说明，并请工程经理检查一下：“给定一个架构和一个变更的约束，工程师指出哪些功能被破坏，提出变更建议，说明权衡取舍，并说明他们仍然不知道什么。”

2. 诊断学习和情境差距

在构建任何东西之前，请将任务与你的课程目前练习和评估的内容进行比较。

1. 练习是否使用实际任务？ 如果训练只教授孤立的模式，而评估是多项选择题，那么没有人练习过如何捍卫自己的选择。
2. 认知需求是什么？ 在布鲁姆修订后的分类法中，比较选项与限制条件属于“分析与评估”阶段，而提出修订后的设计方案则属于“创造”阶段。我们的指南将…… 将学习活动与布鲁姆分类法相匹配 展示了如何将活动与该级别相匹配。
3. 除了技能之外，还有其他因素阻碍了吗？ 检查工程师是否有时间进行设计，是否有人负责架构决策，以及需求是否已记录在案。如果决策是由团队外部人员做出的，那么任何实践都无法改变团队的现状。将这些问题交给能够解决的人。

3. 设计准备和练习

给每个阶段分配明确的任务。

准备。 通过简短的诊断来检查前提条件：团队使用的词汇（可用性、一致性、延迟、成本）、他们需要掌握的基本知识点，以及您自己的设计评审模板。自主学习适合这个阶段，回顾检查仅用于确认前提条件。

实践。 实际运行练习。根据尼尔·福特网站上的描述，团队组建完成后，练习分为三个阶段：讨论阶段，团队确定要构建的内容；同行评审阶段，每个团队进行展示并回答问题；投票阶段，同行对每个团队的作品进行评价，给予“赞”（“做得好”）、“一般”（“漏掉了一些细节”）或“踩”（“做得不好，而且很糟糕”）。一些规则可以直接借鉴：团队可以对不熟悉的技术做出假设，但必须明确说明；不能假设他们可以组建一支全明星团队。

添加变更约束。 标准的空手道套路给出的问题是固定的。为了训练本指南中的技能，请在套路进行到一半时添加第二张卡片：一张需要团队克服的变更约束卡。这是我们的设计选择，并非原规则的一部分，因此请先进行试玩。

反馈。 将反馈与决策联系起来，而不是与总分联系起来。“您已将业务拓展到两个地区，但没有说明切换期间下的订单会如何处理”比“5 分满分，得 3 分”更有用。

实时输入还是异步审核？ 当选择模糊不清时，实时引导最为有效，工程师可以从资深同事的解释中学习，了解他们为何坚持己见。异步审查足以将书面论证与带注释的示例进行比较。

4. 通过一个实际例子进行分析

仅供参考。高级工程师在使用前应验证案例和答案标准。

案子。 一个地区性节日周末售出 20,000 万张门票，其中大部分在开售后的前十分钟内售出。项目简报的第一版要求设计一个能够应对这种高峰期的预订系统。设计方案为：单层网页、单数据库，并在结账时调用支付服务提供商。

约束条件已更改。 中途，主办方补充道：如果一个数据中心离线，销售必须继续进行，并且任何门票都不得出售两次。

第一次尝试。 “增加第二个数据中心并复制数据库。”团队选择了熟悉的方案，但没有说明当两个站点无法相互通信时，禁止重复销售的规则将如何处理。

反馈并重试。 引导员要求团队指出两个相互冲突的目标，并说明在网络分裂的情况下他们会优先保护哪一个。重试时，他们要求他们做出选择，并描述客户的体验。

一次更有力的尝试。 “我们会维护禁止重复售票的规则。在售票点分开的情况下，只有主售票点售票，另一个售票点则显示候补页面。为了避免同一座位被重复售出，我们接受短时间内较低的票源供应量。我们假设售票点分开的情况很少见且持续时间很短，因此我们希望主办方确认候补页面是否可以接受。如果他们需要两个售票点都同时售票，我们会提前为每个售票点分配不同的座位区域，但这会造成部分座位无法售出。” 请注意，此答案明确指出了冲突所在，表明了立场，说明了代价，并指出了未知之处。

解释每种回应的合理性或不足之处。 评判每项方案时，应依据既定标准，而非评审者个人偏好的架构。第一种方案仅提及组件，而未说明其优缺点。而更优的方案则更为具体，阐明了其假设，并提供了替代方案及其价格。

5. 评估能力并制定转移计划

能力证明体现在工程师对从未见过的新案例的处理上。评分标准包括权衡利弊的推理能力以及对新限制条件的应对。一个简单的评分标准是每个标准采用 0 到 2 分的等级：

评分标准：0 分表示缺失或缺乏支持，1 分表示部分缺失相关内容，2 分表示完整且符合既定标准。请单独定义关键错误，例如忽略已声明的安全或数据保护要求，以免总分掩盖此类错误。本评分标准仅为建议，并非已验证的就绪标准：请与工程经理共同调整并进行试点。我们的指南 设计具有实用反馈的互动练习 涵盖如何撰写与决策相关的反馈。

精心安排工作交接。在练习结束后，请每位工程师就一项实际的设计决策进行评审，并提出相同的问题。对过往事件进行客观的回顾，也是过渡到实际工作的有效途径；请参阅我们的指南。 运行无责事件审查.

互动式教学有助于

交互式格式有助于确保每个人在小组讨论开始前就做出承诺。在实时 Kata 演示中，主持人可以展示变更后的约束条件，要求每位团队成员写下他们会做出的权衡以及原因，然后在讨论开始前公布结果。原始格式​​末尾的同伴投票也可以轻松地以同样的方式进行。同样的案例也可以以自学模式进行，方便准备或供错过演示的工程师使用。AhaSlides 支持交互式学习，并可在实时和自学模式之间切换。它是一个演示和学习工具，而不是用于绘制或运行架构图的地方，因此请将图表保存在白板或您的设计工具中。请将您计划依赖的任何特定创作、反馈或报告功能与您自己的工作流程进行核对。有关选择格式的指导，请参阅我们关于……的文章。 何时使用自适应、交互式和实时学习.

衡量发生了哪些变化

预先确定哪些内容能够证明工程师能够在不断变化的约束条件下捍卫架构。将针对未知案例的权衡推理与项目开始前的基准进行比较。明确纳入哪些人员、分母和时间节点。如果结果有所改善，在将功劳归于培训之前，应查看同一时期内还有哪些其他变化，例如新的设计评审模板、人员变动或引起关注的事件。

可能存在的限制

• 设计权威。 如果团队不做出决定，那么练习的效果就有限。
• 时间。 练习一个套路只需几个小时；真正的设计需要几周时间，而且涉及套路无法提供的数据。
• 案件承保范围。 一个案例体现了多种权衡取舍。评分并不能反映工程师的总体判断力。
• 复杂。 更复杂的架构并不一定是更好的架构，所以不要奖励组件数量最多的架构。
• 转让。 在研讨会上表现出色与在紧张的复习中表现出色是不同的，因此要在实际环境中完成套路练习后检查表现。

尽早将这些问题告知赞助商，并制定单独的解决方案。Kata 可以提升工程师解释和辩护能力，但它并不能赋予工程师权威或时间。

常见问题

什么是系统设计练习？

这是一种时间限制内的简短设计练习，由一个小团队针对某个业务问题绘制架构草图，向其他成员展示并回答具有挑战性的问题。它也被称为架构卡塔（Architecture Kata）。

一个团队应该有多少人？

原版形式采用3至5人的小组，通常是在一个房间里进行4至10个小组的分组。小组规模要足够小，以便每个人都能发言。

如何评估系统设计练习？

给出一个新的案例，并根据既定标准，对权衡利弊的推理以及对变化约束条件的响应进行评分。同伴投票可以提供有用的反馈，但本身不能作为评分依据。

从哪儿开始

选择组织中一个反复出现的设计决策，并围绕它撰写一段案例描述。添加一项变更后的约束条件，请一位工程经理验证案例及其答案标准，并拟定一份包含三个标准的评分细则，列出关键错误。在全面推广之前，先在一个团队中进行试点。

要了解如何让 kata 在您自己的团队中实时运行，并在之后以自定进度重复使用，请探索 AhaSlides。