如何建構系統設計練習，以訓練工程師評估架構權衡方案

一個團隊為一個地區性音樂節設計了一套票務預訂系統。該系統輕鬆應對了預期的負載，設計評審也圓滿結束。然而，專案需求隨後發生了變化：主辦方承諾，即使售票期間某個資料中心宕機，售票系統也必須繼續運作。這意味著同樣的系統現在存在單點故障，設計工程師必須決定修改哪些功能、放棄哪些功能，以及如何解釋這些選項。

這是一個範例場景，並非已記錄的事件。系統設計演練旨在模擬這種情況：一個在現有約束條件下運作良好的設計方案，在遇到新的限制條件後，工程師必須給出合理的解釋來捍衛或修改方案。本指南面向工程賦能負責人和工程經理。內容涵蓋系統設計演練的定義、建置方法、運作和評分流程，以及培訓何時不再適用。所有案例和標準在使用前都應由高級工程師進行驗證。

什麼是系統設計練習？

系統設計練習（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。