去哪兒網系統防腐化治理實踐

作者介紹

李佳奇

14 年加入去哪兒，目前擔任技術總監，負責機票主系統後服務和用戶體驗技術團隊，同時擔任業務架構 SIG 負責人，機票架構組負責人，在複雜系統架構設計， DDD 落地，高併發高吞吐系統設計等領域積累大量經驗。    

1. 背景

2022 年，Qunar 技術中心完成了轟轟烈烈的服務瘦身項目，在各個技術團隊的努力下，最終完成了將上千個應用和千萬行代碼瘦身 50% 的目標。

在如此艱鉅的任務達成目標之後，對於技術團隊來講，接下來的重點就變成了如何維持住這來之不易的成果，如何避免反彈。作爲一家處於激烈競爭的互聯網公司，Qunar 致力於不斷爲用戶提供低價的產品，同時維持優秀的服務水平和用戶體驗，業務的演進和系統的迭代在持續不斷的進行。隨着業務的演進和系統的迭代，原本瘦下來的系統上會有新的代碼填充進來，也會有新的應用加入或者拆分出來，這些動作都是會重新增加系統的臃腫程度，如果沒有治理手段，會導致我們好不容易取得的瘦身成果慢慢流失。就像一個成功瘦身的人，如果瘦下來之後沒有制定和執行合理健康的飲食計劃和運動計劃，遲早又會回到身體臃腫的狀態。

基於此，在瘦身項目推進的同時，Qunar 技術中心啓動了系統防腐化治理的項目，目的是在瘦身項目達成目標之後，建立和運用治理手段，防止或者減緩系統不受控制的膨脹，將系統的維護成本維持在較低的水平。這項工作由作者牽頭，Qunar 技術中心業務架構 SIG 承接。

其實要做到這一點並不是一件可以一眼看到路徑和方法的事情。首先應該如何確定工作方向，此時我們手上只有一個已知目標，就是鞏固住瘦身成果，但是如何達成這個目標是不明確的，是需要我們儘快思考清楚的。在思考接下來的工作方向時，我們注意到，既然是爲了鞏固瘦身成果，那麼我們做的瘦身動作的逆向操作所產生的影響，就對應了系統的膨脹，我們只要能夠管理好這些逆向操作，就能夠對抗系統膨脹的趨勢。那麼，會造成系統膨脹的動作有哪些呢？上面的已經提到過了，比如代碼的增加，應用的添加和拆分，但是這裏要注意，如果爲了阻止系統膨脹而完全禁止代碼添加和應用增加，那麼就是因噎廢食，捨本逐末了，業務要發展，系統要優化，必定會帶來代碼增加和應用增加。我們要管理的應該是無效或者低效的代碼增加，以及無效或者低效的應用添加和拆分。而無效低效的代碼和無效低效的應用帶來的都是系統的腐化。因此我們就把鞏固瘦身成果這一目標的實現方向確定爲防止系統的腐化。

明確了防止系統腐化這個工作方向後，接下來的工作要解決的問題就變成了：

  1. 如何定義腐化

  2. 如何測量腐化

  3. 如何治理腐化

2. 如何定義腐化

2.1 腐化指標識別和模型參考

如何定義腐化要解決的是腐化指標識別的問題，腐化指標的識別是一個由虛向實的過程。在尋找這些指標的過程中，我們發現我們在溝通系統腐化時，使用到的語言大部分是在描述系統的複雜度，因此我們決定使用系統複雜度來描述系統腐化，用系統複雜度指標來定義系統腐化。

所以接下來在定義部分的工作就是建立系統複雜度的評估模型。而建立複雜度評估模型，本質上是在完成下面的公式：

也就是確定每個複雜度維度對應的複雜度計算值 _factor _k，確認每個複雜度維度對應的權重 weight k，然後計算各維度結果之和。

在對系統複雜度模型建模的過程中，我們嘗試尋找業內的相關資料，但是業內公開資料中涉及到系統複雜度建模的資料並不是很多，這裏給讀者列舉一些我們在過程中參考並且受益的相關資料。

參考的幾個模型介紹：

The Open Group Conference 2015 中給出的複雜度評估模型

該模型可以用於評估技術架構複雜度、應用架構複雜度以及業務架構複雜度。該模型給我們帶來的參考意義在於，其描述了一種 2*2 維度來定義複雜度的方法。

如上圖所示，描述複雜度可以從被評估對象中元素和關係兩個維度入手，每個維度可以通過其數量和分類（變化程度）這兩個維度的數據來進行復雜度的定義。

國防科技大學學報 41 卷第 1 期 - 系統複雜性及度量

國防科技大學的這篇論文主要提供了區分複雜度概念的方法，我們可以從系統的功能、系統的結構、系統的類別等方向來描述一個系統的複雜度，同時描述系統內部邏輯本身的複雜度也是可以納入模型的指標。

McCabe 度量法

熟悉軟件工程測試的讀者應該對此比較熟悉，上圖所描述的方法又被稱爲環路度量法，是一種基於程序控制流的複雜度計算方法。當我們把程序流程看作強連通有向圖時，可以下面的公式來計算其複雜度：

V(G) = M-N+2。其中 M 爲圖中邊的個數，N 爲圖中頂點的個數。

讀到這裏的讀者可以簡單計算下上圖的環路複雜度是多少。

McCabe 度量法後續又補充了更多的度量方法，也爲我們提供了有價值的參考，這裏簡單羅列一下：

以上是我們在做自己的複雜度建模探索時，參考的相關模型和資料，但是由於業內相關資料不多以及成熟落地案例不多，因此大部分工作還是要我們自己進行探索。

2.2 Qunar 複雜度模型建模過程

接下來介紹下 Qunar 系統複雜度建模中所做的工作。

我們對於系統複雜度的定義是：系統複雜度是指系統在自身描述、迭代、集成、維護、保證可控等方面的困難程度。

一個系統的複雜度可以從以下維度類別來進行描述：

我們對系統複雜度建模過程就是複雜度維度的選取和計算方法的確認過程。

那麼該如何進行復雜度維度的選取呢？基於這個問題我們有以下 3 點考慮：

  1. 模型通用性——由於我們是針對整個 Qunar 技術中心的系統進行復雜度建模，因此模型需要兼顧各類業務場景下的各類系統，模型中包含的指標應該足夠通用化，避免使用帶有特定場景特徵的指標。

  2. 指標可測量性——模型是要服務後續的治理動作的，因此模型中包含的指標一定要能夠實際可測量，要充分了解並考慮到目前技術基礎設施層面對於系統各項指標測量的支持能力。

  3. 可解釋性——模型中每個指標及其計算方法要充分可解釋，滿足各技術團隊的接入需要，儘量減少技術團隊對於模型的疑議。

因此，爲了滿足以上考慮點，我們在指標選取的過程中採用瞭如下步驟：

簡單解讀下上面的步驟。首先，通過頭腦風暴的方式，讓業務架構 SIG 中各個業務線的技術同學根據自身業務場景和系統現狀，發散思維，提供自己認爲的可以作爲複雜度指標的維度，這要做的目的是充分保證指標的豐富性，爲後面能夠得到足夠通用的模型打下基礎。在通過頭腦風暴得到足夠豐富的信息之後，接下來將大家貢獻出來的內容識別成一個個維度，識別的標準是可以獨立定義並測量的指標。接着，將這些識別出來的維度進行篩選，過濾掉具體業務特性的，不合理的，高度近似的維度。經過篩選後的維度需要進行精簡，因爲我們認爲，一個模型最好的狀態是隻有一個指標，如果能夠找到全面且唯一的指標是我們這個模型的最優解，在精簡的過程中，我們進一步得到了彼此獨立、能夠測量、和複雜度高度相關的一組正交維度。

經過以上步驟，我們識別出了 29 個維度，經過篩選和精簡最終我們得到了 8 個複雜度相關維度：

這裏需要爲大家說明的是，在這 8 個維度中，有 6 個複雜度核心指標和 2 個輔助指標。輔助指標的意義在於，當我們衡量一個系統的複雜度是否合理時，需要結合輔助指標來判斷合理性。比如，和業務重點方向（Epic）關聯程度高的系統，對於複雜度的容忍上限就會高一些，同理，處於核心鏈路路徑上的系統，具備相對高一些的複雜度也是合理的。

確定維度之後，下一個問題是維度的量化。通過上面的維度表格可以看到，我們選取的複雜度指標的量綱和量級差異比較大，一個系統的代碼行數可能會有幾萬或者十幾萬，但是依賴數量可能是百級別或者幾十這樣的級別。量綱和量級的差異會導致這些指標難以進行加和。因此，需要對這些指標進行歸一映射，我們將這些指標按照一定的算法映射到了 [0,10] 的區間。

同時，上文對於公式的描述中還提到了權重因子 _weight _k 的確認，根據維度含義和特性的不同，我們賦予了不同的權重。

需要特別說明的一點是，由於我們的模型指標中包含有效代碼行數和代碼總行數，爲了保證這兩個指標能夠在代碼覆蓋率提升的過程中是收斂並複雜度應處於下降趨勢，我們又引入了代碼覆蓋率因子加入到權重中。

建模到這一步，已經很接近得到最終模型了。但是，在此之前，我們還需要思考一個問題：所有應用都通過這個模型計算出來複雜度然後放到一起對比是合理的嗎？會不會存在一些不在覈心鏈路但是仍然很重要的系統比如一些配置類系統無法充分評估其複雜度？

我們對這個問題思考的結論是：

所以我們明確下應用和系統的概念，如下圖：

應用 A/B/C 組成系統 D，在進行復雜度評估時，將以系統 D 爲基本單位，系統 D 的複雜度爲應用 A/B/C 的複雜度之和。

2.3 建模結果

在完成上面的步驟之後，我們得到了最終的系統複雜度模型:

整個模型比較複雜，讀者可以點擊圖片查看大圖。爲了方便閱讀理解，用不同顏色的框圈出了模型的不同部分。紅顏色的框代表 2 個輔助指標，藍顏色的框代表 6 個核心指標，粉顏色的框代表歸一規則。

3. 系統複雜度看板落地

通過上面的建模工作，我們得到了衡量系統複雜度的模型，接下來要做的事情是將模型進行數字化落地並實際應用到技術中心的系統測量中。

在這部分，我們主要做了下面三件事：

相關的能力和系統如下圖:

在落地的具體過程總，秉持着不重複造輪子以及 Qunar 自身完善的技術基礎設施，我們幸運地發現模型中各項指標的數據採集工作都已經通過各個基礎設施能力實現了。在數據層上，我們充分利用了現有的基礎設施，通過不太高的數據是配成本獲得了模型需要的原始數據：

其中：

基於上面數據採集和計算模塊的實現，我們最終上線了系統複雜度管理系統：

通過系統複雜度管理系統，我們對業務域、業務域下的系統以及系統中具體的應用的複雜度進行查詢和追蹤，使得我們接下來的防腐治理機制的實施成爲可能。

4. 防腐治理機制的實施

有了上面的建模和落地，我們得到了系統複雜度查詢和跟蹤的管理系統，接下來爲了實現系統防腐的最終目標，我們結合 Qunar 技術中心應用的歷史增長數據，制定了以年爲週期的複雜度增長治理機制。

我們劃定的增長率上限：10%/ 年，分攤到每個月是 0.85%

計算方式是：代碼行自然增長率 * 代碼行維度指標在模型佔比

同時我們選擇的基線是 22 年底瘦身項目完成後的應用數據。

制定了基線和增長控制目標之後，接下來我們設計了系統腐化檢測機制：

檢測機制會每日更新系統的最新複雜度數據，然後結合上面的增長率上限進行是否超限判斷，一旦超限會被確認爲系統正在腐化，會通過和我們的項目管理系統 JIRA 平臺進行自動整合來創建腐化治理任務並設定完成日期。若對應技術團隊未在完成日期前完成腐化治理，則會納入到 Qunar 用於評估系統質量的防腐指標中並進行周知和升級。

5. 成果和總結

基於以上機制的建立，Qunar 系統防腐項目目前的成果如下：

Qunar 系統防腐這個項目從一個比較難以找到抓手的目標開始，通過對目標的分析，問題的轉化和進一步明確，通過參考相關資料和團隊自身的創造力和技術思維能力，最終得到了能夠在 Qunar 落地的系統複雜度模型，並運用到系統防腐治理中。希望讀者能夠通過本篇文章獲得一些啓發，能夠讓讀者能夠通過本篇內容有所收穫，不論是直接得到一個系統複雜度的評估模型，還是對於自身團隊中類似問題的解決方法的參考，對於筆者來說都是非常有意義的事情。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/6cgvHiwNwuQYVZyZwePIOQ

猜你喜歡