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

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

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

什麼是系統設計練習？

系統設計練習（Kata）是一種簡短的、限時的設計練習。一個小組會收到一段文字描述的業務問題，然後繪製架構草圖，向其他成員展示並回答一些難題。人們也稱之為架構練習（Kata）。這種形式最初由 Ted Neward 以工作坊的形式提出，其規則和主持人角色等細節都記錄在Neal Ford 的架構練習頁面上。 Neward 在該頁面上提出的問題是：當工程師一生中只有不到六次機會進行架構設計時，企業該如何培養優秀的架構師？ 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。