德國Picnic創業公司如何在規模擴充套件階段時才發現架構的重要性？ - Sander

banq發表於2021-08-22
創業套件架構

你是一家小型初創公司的一部分。您腦子裡只有一件事：運送產品並快速找到適合市場的產品。程式碼為王！軟體架構？但是，事實證明，每個系統都有一個架構。無論它是不是好產品，特別是在產品起飛，從初創階段轉向規模擴大階段時，你才會發現它。
Picnic團隊首先在荷蘭的一個城市提供雜貨，然後在全國範圍內提供雜貨，後來擴充套件到德國，最近擴充套件到法國。我們得到了產品並找到了我們的市場。
Picnic 的系統和團隊也在以相應的速度發展。大約 20 個產品團隊構建和維護從最初的核心繫統發展而來的服務。在過去的一年裡，我們的技術團隊規模增加了一倍多。儘管如此，跨這些服務的軟體架構仍然是一個臨時且相當隱含的問題。
從團隊的角度來看，架構選擇似乎是最佳的，但從整個系統來看，它們往往不是。在這篇文章中，我們將探討如何透過賦予軟體架構更突出的作用來改進這一點。這篇文章不會涉及特定的架構風格或技術：這實際上取決於您正在構建的產品。我們可以分享的是我們為提高系統架構質量而設計的流程。
雖然產品團隊自主構建和交付（微）服務很棒，但在擴充套件時會出現一些問題。特別是圍繞更大的計劃，開發跨越多個產品。不止一次，關鍵的技術依賴是在流程後期發現的。這會導致重複工作或返工。再舉一個例子，多個團隊轉向了更多基於事件的架構，但以不同的方式和不同的時間線。更一般地說，關於如何有效應用那些仍然侷限在孤立團隊中的新技術的見解。
 

架構工作組
在這一點上，我們認為從長遠來看，完全分散的架構決策（或缺乏架構決策）會損害我們的使命。同時，鐘擺也不應該完全向另一個方向擺動。在擴充套件環境中，完全集中所有架構決策既不可行也不可取。守門行為會減慢團隊的速度並破壞自治。
因此，架構工作組 (AWG) 應運而生：由來自各個產品團隊的經驗豐富的工程師組成的小組，他們提供部分時間為整個技術團隊解決架構問題和挑戰。AWG 的目標是授權各個產品團隊做出正確的決策。為此，團隊需要對架構上重要的開發有一個粗略的概述，以及一個從團隊收集輸入並向團隊提供反饋的過程。
我們決定採用輕量級流程，邀請產品團隊為重大開發編寫架構提案。重大意味著它要麼是一個大專案，要麼涉及許多團隊和系統，因此會帶來獨特的風險和挑戰。
架構提案作為 AWG 稽核流程的輸入。這樣，架構工作組就有機會權衡即將發生的架構重大變化。透過引入此過程，可實現以下結果：

  • 協調：可以預先發現產品團隊之間的潛在衝突或機會，避免重複工作。
  • 質量：透過對架構提案提供整體反饋，我們提高了整體架構的一致性和質量。
  • 文件：重要的架構決策透過架構提案進行記錄，每個人都可以使用。

AWG 與團隊一起確定即將到來的重大發展，並確定哪些可以從提案和審查中受益。在一個團隊在 Confluence 中完成他們的提案後（稍後將詳細介紹格式），架構工作組的兩名成員開始審查。直接針對提案本身提供反饋，並計劃與提案作者進行一次反饋會議。通常所有跟進點都由產品團隊解決，但如果反饋導致提案發生較大變化，則可能會安排另一輪審查。
同樣，此過程的目標不是阻止計劃，而是幫助產品團隊提出和回答正確的架構問題。我們希望營造一種鼓勵預先設計和討論重要決策的文化。
 

架構提案模板
以這種深思熟慮的方式思考架構變化並不是每個人都自然而然的。AWG 開發的工具之一是供團隊使用的模板。這是一個簡單的 Confluence 模板，要求作者至少解決以下幾個方面：

  • 目標/要求：描述提議變更的業務成果。如果這部分不能寫清楚，就無法判斷提議的架構更改的有效性。有時，提案會被擱置，直到對實際目標和要求足夠明確為止。
  • 當前解決方案：簡要描述當前域模型的相關部分，並提供現有服務及其互動的上下文圖。
  • 提議的解決方案：描述變更及其架構影響，重點關注新服務、API 設計、資料建模、與現有系統的整合以及可能採用的新技術。我們提供有關何時使用元件圖或序列圖的指南。
  • 操作問題：概述負載和效能目標，以及更改的任何安全注意事項。此外，如果提案中有 API 更改或其他需要管理的依賴項，則團隊應提供推出計劃。
  • 風險：架構總是要權衡取捨。在架構設計階段識別出的任何風險，以及影響評估和緩解策略都應記錄在案。

每個部分都包含有關哪種圖表型別最適合的指標，以及預期的抽象級別。所有提案（包括反饋）都對整個技術團隊開放。這樣，每個人都可以學習並與其他團隊保持同步。
 

微調流程
自從我們在 2020 年底啟動 AWG 並引入提案流程以來，我們在此過程中吸取了一些教訓。
最初，我們將流程與我們的季度計劃週期保持一致。所有技術負責人都將被邀請參加聯合會議，以揭示需要架構提案的主題。然後，提案將在季度開始之前按照嚴格的時間表完成，從而做出明確的透過/不透過的決定。不經意間，我們將 AWG 變成了某種變革諮詢委員會，給圍繞季度路線圖規劃的已經擁擠的時期增加了壓力和不確定性。所以我們改變了這一點。現在，我們不舉行大型季度會議。相反，我們在滾動的基礎上組織 AWG 與產品團隊的個人簽到，以確定他們的需求並反映團隊架構的當前狀態。我們希望就他們的關鍵變化向團隊提供建議，而不是在困難時刻阻礙或加重他們的負擔。
編寫架構提案並不容易。擁有好的例子，並與其他團隊分享這些確實有助於人們開始。我們根據最初提案的反饋改進了模板。很明顯，編寫提案通常會發現與計劃的目標和要求有關的重要問題。無論提案的其餘部分有多好，如果基本面不正確，也沒關係。為了解決這個問題，我們現在要求團隊首先迭代目標和需求部分，直到所有利益相關者都同意。只有這樣，團隊才能編寫剩餘的部分，充分詳細地設計架構。
 

我們接下來要做什麼……
引入具有輕量級提案流程的架構工作組對於 Picnic 來說在擴大規模的同時非常有效。我們沒有定義每個團隊都應該遵循的大型集中式架構。相反，我們希望將架構思維融入所有開發人員的思想中。AWG 不會限制人們的創造力，而是幫助評估架構選擇在更廣泛的野餐環境中是否有效。它還在技術層面將團隊聚集在一起，致力於跨越多個產品的雄心勃勃的計劃。
我們當然還沒有達到我們的最終狀態。隨著越來越多的產品團隊加入 AWG，我們擴大了團隊以跟上。最近也發生了從季度“拉動模式”到更多自助服務模式的轉變（從產品團隊的角度來看）。在讓 AWG 參與的時間上找到適當的平衡是一個持續的過程。到目前為止，我們已經從許多架構建議中受益，這些建議預先產生了有價值的見解，提高了我們系統的質量。

相關文章