在微服務架構中管理技術債務

作者 | Glenn Engstrand

譯者 | Rayden

策劃 | 丁曉昀

審校 | 張衛濱

在 QCon Plus，Glenn Engstrand 談到了一種促進技術債務管理的方法。大多數參與軟體開發的人員在試圖讓産品經理或項目經理同意他們花時間修複項目技術債務時都會遇到困難。Engstrand 在 Optum Digital（前身為 Rally Health）采用的方法能夠以一種系統性和非對抗的方式管理這些具有不同優先級的問題。

什麼是技術債務？

從廣義上講，技術債務是在軟體開發過程中的一系列決策，這些決策會導緻團隊通過建構特性以創造價值的能力受損。

大家應該對下面的交流十分熟悉：産品經理描述了他們想要添加到産品中的下一個功能。開發人員要求給很長的時間才能實作該功能，而一般管理者會認為這個時間太長。開發人員則會談到需要解決修改大量難以了解的代碼時出現的相關問題，或者要應對舊的代碼庫或架構中的各種缺陷。是以，開發人員要求更多的時間來解決這些問題。産品經理會拒絕他們的要求，并指出眼下還有一大堆等待實作的期望功能。

如果情況長期無法解決，這種惡性循環可能導緻失去市場競争力，甚至複雜軟體系統的整體崩潰。

我們有兩種方式暫時應對這種情況，其中一種是選擇簡單或快速但并非最佳的解決方案，另一種則會導緻技術棧落伍或能力的欠缺。這兩種情況都需要花費工程團隊的時間來處理偶發的複雜問題，進而影響創造價值或修複缺陷。

在保持快速傳遞功能的同時償還技術債務會很困難，而且系統架構越大越難。管理數十或數百個微服務的技術債務要比單個服務複雜得多，并且不償還債務所帶來的風險會增長得更快。

每個軟體公司都會遇到必須處理技術債務的時候。

在 Optum Digital，一個産品集（也被稱為軟體産品線）是一系列滿足特定需求的産品的組合。每個産品都會有多個團隊，通常會與軟體用戶端或後端服務保持一緻。還有一些團隊負責面向平台的、橫跨多個項目集的功能。每個團隊很可能負責各種軟體庫。我們有 700 多名工程師在開發數以百計的微服務。他們非常重視技術債務，因為失控的風險是非常大的。

2018 年，我們的首席技術官 (CTO) 最初發表了一篇關于工程投資重要性的博文，在這兩年多的時間裡，他們将自己的整體業務拆分為了微服務。

技術能力計劃

公司的工程師們提出了技術能力計劃（Technology Capability Plan，TCP）來解決技術債務問題。

TCP 是一種基于社群的用于制定償還技術債務計劃的方法。在工程中，它通過收集、組織和傳達技術領域中不斷變化的需求向工程端和産品端傳遞資訊，以保證架構的長久性和适應性。換句話說，它可以用來指出公司如果不及時采取具體措施，将會在何時陷入困境。

該計劃鼓勵社群按照特定的格式制定償還技術債務的計劃。在記錄每個領域技術債務的風險分數後，根據該風險分數設定要進行處理的優先級。通過優先級計劃，可以與産品經理積極而有效地協商技術債務償還的工程時間。

工程社群

在組織内，工程社群是橫向形成的，換句話說，它們與特定的團隊或産品無關。工程師們通常因為他們熱衷于使用相同的技術而加入到這些社群來，是以社群是開放的，并有機地發展。

但是，如果某些社群具有戰略價值，它們可以将其設為邀請制。如果成員是經過篩選确定下來的，那麼社群重點應該放在文化補充（culture add）上而不是文化契合（culture fit）上，而且還應該具備代表性和多樣性。

他們通常有專門的交流方式（例如，wiki 話題、聊天頻道和電子郵件清單），以便于持續交流和資源共享。

這些工程社群的政策都是自下向上制定的，這是保持 TCP 有效性和真實性的關鍵。

每月的社群會議會記錄下來并進行共享，會議紀要會發送給所有工程師。每個社群的會議活動都保持更新記錄，每個季度這些檔案會收集起來，并在内部作為 TCP 釋出。

制定償還技術債務的計劃

每個社群的計劃都包含約一頁左右的說明以及一張記錄随着時間推移所需的技術演進的表格。

表格中的每一行對應某種程式設計語言、架構、庫或平台即服務的“首選”、“可接受”、“不主張”或“不可接受”（PADU）版本，這是與組織的技術棧息息相關的。

每一列代表一個時間段（例如一季度或一年）。整個表格可以展示未來三年的資料。

表格中每個單元格都包含該時間範圍内該技術的生命周期狀态：計劃（plan）、棄用（deprecate）、遷移（migrate）、使用（use）或移除（remove）。

其中“計劃”狀态表明需要制定計劃進行更新。“棄用”意味着團隊不能再采用該技術版本。“遷移”表明每個團隊都應該主動遷移到适當的版本。“使用”表示該技術版本是應該使用的。“移除”意味着該技術可能在該時間段内随時失效。

說明頁用以描述每種技術的應用背景以及不遵循計劃可能帶來的影響或後果。這些社群驅動下的計劃能夠幫助組織管理因使用過時的、不安全的或不受支援的技術版本所帶來的技術債務。

每個産品集也送出 TCP 計劃。産品集驅動下的計劃可用于指導償還其他形式的技術債務，例如重構大型代碼庫或者将單體服務拆分為多個較小的服務。

TCP 中除了社群和産品貢獻的部分之外，還會介紹計劃的願景，另外有一個章節會介紹目前風險最大的産品領域。

什麼是技術風險？

工程社群和主要産品集工程師們制定了償還技術債務的計劃之後，就需要進行一系列的工程投資。在資源有限的情況下，應如何确定處理的優先級呢？産品管理人員并不知道該怎麼做，因為工程投資不是從他們那裡來的。要回答這個問題，需要了解如果不遵循計劃會帶來什麼樣的風險。

這種風險可以通過風險分值進行量化。得分越高，風險越大，優先級則越高。“使用”狀态下的技術分值始終為零，随着技術版本變為“遷移”、“棄用”或“移除”狀态時，風險分數會逐漸增加。

計劃制定都是自下而上的，而風險評分則是自上而下的。技術債務償還計劃由社群工程師們制定，而計劃清單的優先次序則由工程管理人員制定。

Optum Digital 的名額都收集到所謂的平衡計分卡中，這是一種哈佛商學院研發出來的戰略績效管理工具。

各種計劃中技術債務都以産品為機關進行彙總。每個産品的風險評分是該産品所有技術風險評分的總和。即便産品中隻有一項技術仍在使用或依賴已經處于“棄用”、“遷移”或“移除”狀态的技術，該産品的風險評分也會受到負面影響。如果産品中有多個代碼庫都不合規，風險評分隻會計算一次。每種産品風險評分彙總結果的中位數要記錄在平衡計分卡中。

在存儲庫上使用自動化的靜态代碼分析以确定技術依賴關系很有價值的。另外還需要支援 CI/CD、DevOps 和 GitOps，以便于快速、可靠地計算這個名額。

為幫助團隊專注于産品，我們還要以不同的方式計算 TCP 風險分數。這種情況下，計劃中的每一項技術都以代碼庫為機關進行彙總，每個代碼庫的風險分數是該代碼庫所有技術風險分數的總和。

産品代碼庫的總風險評分彙總為産品本身的總風險評分。通過這種方式，我們可以跟蹤每個産品的風險消除情況，或者基于 TCP 風險進行産品比較。

在路線圖中獲得工程投資

現在，我們已經有了一個優先計劃來償還技術債務，這個計劃是由工程師團隊制定的，并得到了上司層的支援，那麼我們該如何為這個計劃提供資金，并将其置于路線圖中呢？

首先，讓我們回顧一下，在沒有 TCP 的情況下，當工程經理和産品經理坐下來為下一個 sprint 制定開發計劃時，通常會發生什麼：在無 TCP 環境中，隻有工程經理和産品經理，産品經理總是能以銷售作為理由來達到他們的目的。

讓我們在有 TCP 的情況下重新看待這種情況。産品經理剛剛與主管們開完會，讨論了 TCP 的重要性以及如何在平衡計分卡中降低 TCP 風險分數，然後與工程經理坐下來為下一個 sprint 制定計劃。産品經理要求提供三個新功能。工程經理說：“如果由我決定，我會把這三個功能都做出來給你。不幸的是，我們所有的工程師和他們的主管們都已經意識到，這個風險極高的技術債務需要在本季度償還。如果你在過去的一年裡一直關注 TCP 就應該已經意識到了這一點。”

你看到這種變化了嗎？因為 TCP 是企業範圍内對技術債務及其風險的權威共識，工程經理就不用通過吵架或者威脅，而是使用這種集體讨價還價的能力獲得應有的工程投資。

在少數的情況下産品經理依然在準許工程投資方面不夠靈活，那麼問題最終會提升到管理層進行解決。還記得風險分數是平衡計分卡的一部分嗎？對于管理層來說，平衡計分卡就是他們的儀表盤，可以觀察公司發展方向。儀表盤上顯示的這些名額可以讓他們更真實地感受到技術債務，使得他們更可能選擇償還結束債務的工程投資。

TCP 的替代方案

我所知道的僅有的另一種管理技術債務的系統性方法記載在 Google Site Reliability Engineering 一書中。

下面我們快速介紹一下這種方法，并說明我為什麼認為 TCP 更好。

首先，基于 SLO 或服務水準目标目标達成共識。每次系統超出這些 SLO 之一時就将其視為錯誤。每個時間視窗有一個商定的可接受錯誤數量，稱之為錯誤預算。如果系統在下一個時間視窗之前已超出其錯誤預算，将不可釋出任何功能。

為了避免這種情況，産品經理應該更願意轉移工程資源來償還技術債務。

接下來解釋一下 Google SRE 方法非常不穩定的原因。對于大多數産品經理來說，功能和銷售之間的因果關系似乎比技術債務和系統中斷之間的因果關系更真實。有一種假設是，消除技術債務總是使系統更加穩定。雖然長期來看這是正确的，但不能保證在短期内有效。

錯誤預算會倡導短期思維，是以不利于産品經理準許此類工程投資。由于很難預測何時超出錯誤預算，是以很難計劃何時安排工程投資。

這種方法容易使産品經理與工程經理産生某種對立關系，這種僵持方式會使接受的風險變大，是以獲得管理層準許的難度更大。最後，這種方法容易将支付技術債務政治化，産品經理試圖通過說服高管不要将某些中斷計入他們的錯誤預算，或通過重新協商 SLO 或錯誤預算來推遲工程投資匮乏所産生的後果，進而與系統博弈。

而 TCP 方法側重于在産品和工程之間達成真正的共識。TCP 驅動下的開發在路線圖方面更具可預測性，是以所有相關方都不容易出問題。

總 結

技術能力計劃能否解決所有的工程問題麼？當然不能。

你還會有技術債務嗎？絕對會有。

在客戶驅動下是否仍需要走捷徑以傳遞功能？我相信你會的。

TCP 無意阻礙或限制工程師和産品經理做他們最擅長的軟體開發和釋出。TCP 向工程師和産品經理發出信号，表明走捷徑會産生額外的成本，并且他們不能無限期地忽略這些成本。

使用 TCP，您不必等到中斷嚴重時才開始償還技術債務。沒有任何流程、政策、技術或工具可以作為品質工程的有效替代品。

TCP 記錄了工程師們關于什麼是風險最高的技術債務以及償還它的合理時機的共識。要使 TCP 得到尊重，它的計劃必須是相關的、準确的、有說服力的和可信的。隻有當它的貢獻者是經驗豐富且成熟的專業人士，具有強大的工程技能以及誠信品質時，這一切才能實作。

我認為我們 TCP 文檔中的這句話是最好的總結：

設計持久和具有适應性的産品需要對今天的現實和明天的可能性有深刻的了解。它需要了解驅動它的技術和市場力量，需要長期緻力于集中和持續的進步。

https://www.infoq.com/articles/managing-technical-debt-microservices/