阿里10年沉澱｜那些技術實戰中的架構設計方法
上週我寫的一篇文章《關於技術能力的思考和總結》引起了大家的關注，好多讀者的評論“以寫代想、以想促真、以講驗真”，大家的感受很深刻，基於上次的文章，這篇文章我其實更想跟大家聊聊一些常用的思考方法，思考問題的方式對了，往往可以幫助大家少走彎路。
常用思考方法
技術常用思考方法
技術思考本質還是結構化思考，所以常見的結構化思考方法也是適用的。這也是大家會看到很多技術架構師都會用一些方法論去分析問題的原因。但這裡我不是重新去論述這些常見的技巧，而是分享從技術實戰中得到的一些思考方法，為此我分為了技術架構設計的方法和技術Leader的思考方法兩類。
技術架構思考方法
0——->1
這個思考方法的含義是：
當我們在一堆迷茫和混亂中不知道如何下口時，應該先貼近問題本身，還原客觀事實，並快速形成 1 個能夠拉起認知並快速討論迭代最佳化的版本。大家圍繞著這樣的一個初始版本去疊加和豐富其他維度的內容，直到方案的共識。
我舉一個實際的CASE，大家在談某平臺能力升級的方案時候會經常喜歡用PPT畫一些模組圖，試圖透過一些抽象的詞彙來釐定清楚邊界，核心概念。大家以為是在講本質講原則但實際所有人聽了都是雲裡霧裡，不知所云。因為透過概念去推導概念是無法真正回答問題的。
而比較好的應對方法我總結為以下三個步驟：
【使用者視角的客觀世界還原】
使用者故事的串聯，基於互動流程和真實的資料來描繪這件事在客觀世界中使用者視角看來是怎麼發生的。這就是我們找準一個大家都能夠共識的視角，讓所有人快速把客觀事實搞清楚畫出來這個 1，而這個 1 就是後續討論的靶子 。這個 1 的表現形式我認為往往都是很簡單的，要麼是互動時序圖，要麼是Excel表格，而不是複雜的模組概念圖。
【客觀資訊的結構化整合與提煉】
只是樹立起來 1 這個初始版本，還遠遠不夠。因為第一個步驟只是將模糊、混亂的東西透過一種方法資訊化表達出來，這還遠遠達不到使用的程度。所以還需要將上述資訊進行結構化的整合與提煉，因為資訊只有經過結構化才能夠變成有意義的知識，才能夠與之前的經驗形成互動，也才能夠進行初版的設計加工。比如對資料流的處理，就會發現有哪些是可以合併的同類項，有哪些平衡校驗邏輯等。
【加入多元視角的檢驗與抽象】
透過第二步的處理把 1 這個版本變得更加豐滿，但是要形成完整的可實施方案還遠遠不夠。我們還需要加入更多維度的校驗和抽象，比如進一步抽象以看透其本質，比如加入重要異常，ROI，合理性等擴充套件性等多方的視角去做校驗。
所以大家以後在遇到很多方案談不清楚的時候，不要去聽別人講什麼原則，概念，價值等等虛頭巴腦的東西。把大家拉回來，回到最簡單的最樸素的東西來對焦，那就是 一張互動序列圖 或者 一張表格。越快速從一堆迷茫中快速提煉出這個 1 ，就越容易快速拿到結果。
1——->0
這個思考方法的含義是：
當我們在做一個方案時面對無數因素無法抓住關鍵點時，我們應該考慮刪除法（把這個 1 拿掉不要行不行）去尋找決定性因素，以確保我們是真正的抓到了關鍵點。
我舉一個實際的CASE，每年都會做技術規劃，相信這是很多架構師/Leader很痛苦的事。痛苦的根源就是在腦子裡面有無數需求，有無數的待最佳化點，也有無數的想法在縈繞，看到每個點覺得值得在新一年做攻堅。最終多半形成的就是一個表格，把今年要做的事羅列下，最多還排個優先順序，好一點的換個形式變成xmind或者PPT，再稍微好一點的可能會搭配上業務的目標和策略打法。但透過這些表面現象，其本質就是一個表格，沒有抓住重點的表格。相信大家應該都看得蠻多的了。
如何應對這類問題我總結為以下幾個技巧：
【因果判斷法】
很多時候我們都在談，要抓住事情的本質，要具備化繁為簡的能力，其實就是在談透過表面的結果去探究真實的原因。所以在看哪些是決定性因素時，大家不妨用因果法去檢驗：這個因素到底是深層次原因還是誘導的結果。
【樹幹樹枝法】
有時候各個因素之間並不是單純的因果關係，而是依附關係，就像是樹枝依附在樹幹上一樣。而我們要找到決定性因素，可以嘗試這個方法去檢驗：如果把這個因素去掉會不會影響全域性，是不是導致結論不成立。透過這樣多輪的分析，是可以繪製出來樹幹的與樹枝的關係，這個樹幹就是要找的決定性因素。
【支點撬動法】
有時候各個因素之間可能沒有直接或者間接關係，或者這個關聯關係太弱很難透過以上兩個手段去確定關鍵點。可以嘗試支點撬動的辦法，即尋找可以激發這一堆要素的關鍵要素。我之前給團隊舉一個例子，國家抓經濟肯定不可能是米麵糧油各種瑣碎地抓，肯定是找到幾個關鍵點起到支點撬動的作用，如房地產行業。抓住這個就能夠帶動上下游產業，進而激發各行各業。
以上是目前實踐下來的抓取關鍵點的一些方法。但這裡一定也要注意一個粒度問題，千萬不要走極端。比如一提關鍵點，就去思考本質，一提到本質就去找根因，一找根因就挖到人性，然後得出來就是人性的原罪問題。這種都是沒有任何營養的做法，也不利於事情的推動解決。
1——->2
這個思考方法的含義是：
當我們思考一些抽象問題/方案時候，需要對問題進行拆分（一分為二），透過分而治之的方法來確定每個小問題的邊界，透過對小問題的解決來降低全域性的思考難度，以儘快形成解決方案。
這個應該不需要舉例子了，大家日常都應該有所接觸，這裡只是列舉幾個比較典型的技術架構動作：
【縱深拆解】
拆解是非常好的一個將問題分而治之的辦法，但要注意的是要做有機的拆解而不是物理的分解。比較典型的案例就是關於故障指標這個課題的處理，我是見過有團隊層層分解，把故障指標分解到每個同學身上，這是極其錯誤的做法，也不可能得到想要的結果。我們應該是要做拆解，就是把要守住故障指標這個結果拆解成哪幾類關鍵動作，進而要求團隊關鍵動作做到位，而不是強行分解指標。
【橫向解剖】
做過實際研發的同學一定遇到一些業務需求的討論，很多時候來來回回扯不清楚，而且經常會出現產品說這是技術架構問題，技術架構說這是業務需求問題，業務方說這是產品設計問題的現象。要破解這個僵局就需要把這個問題進行解剖，一層一層解剖清楚，把業務需求問題描述清楚，把產品設計搞清楚，把技術方案搞清楚。每一層都面向上游遮蔽下游的細節，才有可能把問題定義得清楚。一般來說，將這件事參與的角色進行解剖會更容易看得全面，更透徹。
以上是我實踐對問題拆分的一些方法技巧，凡事多看幾層終歸是能夠更加有結構性地認知事情本事，也越有利於問題的解決。
1——->N
這個思考方法的含義是：
當我們思考一些技術方案時候，不要僅侷限在當時當刻的條件約束，要適當考慮系統的承載從1變到N的過程中的對系統架構帶來的挑戰。
做技術架構師的都知道做架構要求有前瞻性，不能被業務拖著走。但很多時候我們其實沒有仔細思考如何才能夠做到前瞻性，我總結為最關鍵的考慮的因素就是時間，把時間拉長來考慮關鍵生產資料可能發生什麼變化，透過去架構這種變化所得出來的方案就具備了前瞻性。一般意義上來說，我們平臺演進的生產資料抽象地歸納為三類：
業務場景：這是最原始的生存資料，更是平臺演進的源動力。典型的如市場份額變化，使用者體價值的變化，競對動態等。
團隊組織：是人創造了平臺，也是主導平臺的演進發展，這個生產資料如果不能得到有效利用，充分釋放能動性就會出現平臺無法支援業務快速發展，同時人也在平臺中內卷。
技術架構：技術架構其實本身也是非常重要的生產資料，這是很多人會忽略的地方。大家想一個最簡單的例子，同一個變數分散在多個地方導致語義不清，維護成本巨大就明白了。
針對這幾個生產資料我抽取了幾個技巧去思考如何從 1 擴張到 N：
【架構考慮所有可能性但做有限明確實施】
從業務場景的變化情況來看，的確充滿很多不確定性。也遇到過一種典型的業務與架構的死迴圈的情況：前端業務面臨太多不確定性需要技術架構給予專業意見和評估，但是技術架構認為業務啥都想不清楚還要我評估這評估那，兩邊就開始互相死鎖。
而比較好的做法就是架構能夠基於自己的經驗和業務變化的理解，將可能性進行羅列考慮，然後給出來基於XX業務假設下，系統架構需要XX量級的工作量做XX樣的能力迭代升級，可以做到XX的業務效果和價值，但需要進一步XX的業務輸入。這就是架構考慮所有的可能性的含義，是需要給予業務的選擇。
但技術架構實施卻未必是要留有太多的空白，架構要大但是實施要小，對於值得留白的地方做好擴充套件設計，對於實在看不清楚的地方就要明確攔截（寧願不做也不錯做），將可能性留足但也不瞎埋坑。
【沒有靠譜的人只有靠譜的機器】
我常常去聽一些故障覆盤會議，在談以後如何改進的時候很多同學都價值觀爆棚，說以後XX類變更都加簽上我來稽核一道，我確認沒問題再往後走。雖然這種精神值得鼓勵但是這種做法實在是很不值得推薦，這樣沉澱出來的平臺其實是非常脆弱的，在做技術方案時一定要思考能夠交給系統的絕對不能用流程，能夠做到領域模型校驗的千萬不要靠旁路系統的側面印證（如不必要場景下的核對）。
【提前思考“幸福”的煩惱】
很多技術同學都希望做高併發大流量的系統，但很多時候在寫程式碼的時候身體很誠實，怎麼簡單怎麼來。實際做的時候既不考慮大流量也不考慮高併發，對於資損風險考慮也極其少，而且基本上都很有道理：現在的業務量沒到不需要考慮那麼多，這種事發生機率極其小一期先這樣……要對技術架構做提前思考就必須從每行程式碼做起，提前考慮高併發大流量和嚴謹性。
通常來說大家其實都比較喜歡從0到1的過程，按照網際網路的迭代式打法，後面的1到N的過程也會被不斷壓縮。所以提前在0到1的過程加入1到N的架構預判非常重要，因為很多時候結構性的問題在最開始就決定了，而且只有一次機會。
-1<——->1
這個思考方法的含義是：當我們思考一些技術方案時候，不要一條道走到黑，要前後、上下、左右、正反多個方面去思考，讓技術方案具備更多維的視角。
我把常用的技巧總結如下：
【正反思考法】
日常也review了很多同學產出的架構方案和系分以及測分，大家對於正常業務需求功能的論述基本上都沒有啥大問題，按部就班去寫就可以。但普遍的問題都是對對問題的反面論述不多，如支付正常流程濃墨重彩，退款/拒付等逆向流程就沒那麼細緻，業務功能正常流轉論述很飽滿但是異常場景就寥寥幾筆。但正面與反面結合起來才是完整的一體，而且對反面的思考其實是對正面的有益補充。而且通常來說，我們在正面出現的機率大於反面，但是反面出現差錯的影響所需要付出的精力卻遠遠大於正面。
【極限思考法】
在review技術架構方案風險相關的內容時，我都會特意問一下，如果出現XX問題最壞的業務影響是什麼。為什麼是問最壞的業務影響，是因為如果談風險那肯定都是有一點點的，不利於大家去深究最關鍵的問題。透過極限設問，其實是激發大家去做最壞的打算，有了最終極的兜底手段才能夠更樂觀去做技術變更。
【對稱思考法】
在review程式碼或者邏輯結構時，在深挖細節和關鍵點後，我時常會拔出來看看整體的邏輯結構是不是飽滿，是不是對稱，是不是美。最簡單的例子就是寫了if 我一定要有else，不然沒對稱結構就讓我很不舒服。因為我相信對稱的美就是一種生產力，因為美的東西一定是簡潔且直達本質的。而我們寫程式要的就是邏輯清晰簡單直達業務本質，邏輯結構清晰的基本上沒大問題，不清晰（如變數瞎命名，方法無語義）的深挖下去多半都能發現大問題。根源就是邏輯清晰程式碼才清晰，程式碼不清晰基本上就是邏輯混亂，邏輯混亂就會產生BUG。
M*N——->M+N
這個思考方法的含義是：當我們思考技術問題時，可以嘗試從系統耦合的角度去思考，嘗試找一些突破口。
我舉一個實際的CASE，高速公路網的連線不是把所有目的地之間都修一條高速公路，而是會選擇修建複用的高速公路主幹道 + 分支道路的方式來組織這個網路。一條一條串聯的方式就是耦合在一起的，這就是M * N。透過主幹道 + 分支道路的方式 就是解耦的，M + N 就能夠組建這個高速網路。
在技術架構上如何運用解耦這個技法，我有如下幾個提煉。
【解耦上下游關聯性】
在業務和技術架構發展的前期，把很多東西糅雜在一起是最快解決問題的方法。但隨著業務和平臺架構的進一步演進，勢必是要做解耦，目的就是重新去界定各個模組的邊界，平衡新的業務發展要求下各方發展快慢的訴求差異，透過解耦互相鬆綁快速發展。
這種技法在服務化的分散式架構中非常常見，基本上跨域的平臺架構升級都有解耦的影子。
【解耦各個角色的依賴】
解耦上下游關聯性其實更多是在技術模型的抽象上，但在落入到技術模型範疇之前，還有就是我們在做更加抽象的解決方案探討時要注意解耦各個角色之間的依賴。上述【架構考慮所有可能性但做有限明確實施】中提及的就是最好的案例。其實這裡的本質表達就是，技術架構的設計應該要與商業選擇，產品設計等解耦開來。
透過這一層的解耦其實能夠多個角色之間基於SLA去互動，並且能夠基於自身的專業思考給予對方更多的選項和可能性。很多時候的前瞻性和競爭力可能就是比別人多一個選擇。
解耦思考法其實很有意思，幾乎所有的大型平臺架構升級都有這個思考法的影子，所以下次沒啥思路的時候可以從這個角度做一個審視思考，說不定是有新的收穫。
總結
以上是我在做技術架構方案時沉澱總結的一些思考方法，這些思考方法不可能解決遇到的所有實際問題，只能算是一個思考提示，在遇到問題可以嘗試從這幾個方法去看看是否有靈感。基於方法論但是不侷限於方法論才是方法論最大的意義和價值。接下來一篇文章，我會從技術Leader的視角談談我在實踐中的一些思考。
作者：知明，螞蟻金服國際事業群資深技術專家，全球資金平臺技術負責人，負責了螞蟻全球化程序中底層資金清結算、外匯等平臺能力的搭建和迭代演進。
原文連結
本文為阿里雲原創內容，未經允許不得轉載。