什麼才是架構師的真核心？

阿里妹導讀

本文旨在幫助大家深入理解技術、架構和團隊領導力的本質，從而獲得持續成長的方法。歡迎在文末留言，你覺得架構師需要具備的核心能力是什麼？

技術架構師是在技術領域扮演著關鍵角色的專業人員。他們在業務需求分析、專案實施、技術架構治理等多個環節中發揮著重要的作用。

技術架構師不僅需要具備高超的專業技能，還需要具備良好的系統思維和認知心態。他們要能在宏觀層面上進行技術架構的規劃和治理，同時也要在微觀層面上帶領團隊進行業務專案的交付實施。技術架構師是技術人從最初的研發編碼，到成長為技術團隊的核心骨幹、技術主管、高階技術主管，甚至是技術 CTO 的關鍵一步，如圖 1-1 所示。

圖1-1 架構師在職業生涯的位置

架構師的生態位置

架構師的角色既像是踏著五彩祥雲的救世英雄，又常常成為各種問題的擋箭牌。他們經常被借用來贊成或反對某些事項的推進：

業務需求不僅數量龐大，而且頻繁變化。技術人員即使加班加點，也常常被抱怨效率低下、問題繁多。
產品經理在進行產品分析和設計時，經常需要技術人員參與評估，甚至要一行行檢查程式碼以瞭解系統現狀，但他們還會抱怨系統能力不足，無法提供必要的資料支援。
技術人員在專案實施過程中，最常遇到的是系統邊界問題，最常抱怨的是架構不夠先進，導致對業務需求的支援緩慢，生產環境中的應急事件頻發，缺乏時間和空間進行深入思考和個人成長，從而感到技術成就感較低。

這些現象反映出對技術架構師在軟體研發過程中的角色定位和價值貢獻認識不清晰。在探討架構師的系統思維之前，我們有必要明確架構師在生態系統中的位置，以及他們的權責。這些因素決定了架構師應具備的能力，並對他們提出了獨特的要求。

架構在產研中的位置

在大多數產品研發過程中，通常遵循一種瀑布式協作模式，如圖 1-2 所示。在這個過程中，業務人員首先了解需求，然後由產品經理進行收集和分析，最後傳達給技術人員實施。

圖1-2 瀑布式協作模式

這種模式的問題在於，它使得上游角色更加面向未來，而下游的技術人員則更多地依賴歷史經驗，處於資訊劣勢的地位。這種資訊的不對等很容易導致上游角色在制定方向和目標時，較少考慮實施路徑的可行性。因此，當研發的產品出現問題時，人們往往傾向於歸咎於架構的不靈活或缺乏前瞻性。

當技術架構團隊竭盡全力彌補資訊劣勢，提出一個相對可靠的架構方案，並能夠識別出對未來需求複用有影響的改造點時，他們通常會與業務人員、產品經理一樣，主動地自我合理化地認為，這樣的架構最佳化一定會影響專案的上線時間，因此傾向於先實施臨時方案，而不是進行架構最佳化。然而，當專案上線後出現問題，技術架構團隊再次主動排查並提出清理和解決歷史架構負債的方案時，業務人員和產品經理往往會指責說：這就是一個技術架構問題。

業產技是三角關係

為了改變瀑布式協作模式帶來的資訊不對稱問題，可以採用業務人員、產品經理和技術人員之間的三角關係協作模式。這種模式強調三個角色之間的直接溝通和協作，以確保資訊的及時傳遞和共享。如圖 1-3 所示。

圖1-3 三角關係協作模式

在面對不確定性的市場環境時，決策需要考慮多個維度，包括清晰的商業模式、客戶導向的產品設計，以及長遠前瞻的技術架構思考。這種多維度思考決策要求團隊成員不僅要專業，還要能夠獨立思考並輸出意見和判斷。

在三角關係協作模式中，業務人員、產品經理和技術人員各自圍繞業務目標發揮自己的專業價值。產品經理專注於設計使用者體驗，技術人員負責論證技術架構方案和可能的風險，業務人員則考慮市場策略。這種模式適合網際網路產品的研發，因為它鼓勵每個角色在自己的專業領域內發揮最大的作用，同時保持對業務目標的共同關注。

然而，團隊成員在未做好自己本職工作之前，應避免盲目補位或越位。技術人員的首要任務是確保產品研發的質量，而不是過度介入產品設計。產品經理應專注於提升產品體驗，而不是參與銷售談判。這種混亂的生產關係可能導致團隊效率低下和目標不一致。

業務人員、產品經理、技術人員三方保持獨立性與專業性，並不意味著各自為戰。相反，他們應該圍繞業務目標互相咬合，形成合力。產品經理根據業務目標設計產品體驗，技術人員根據業務目標設計系統架構，業務人員根據業務目標考慮市場策略。這種互相咬合的關係需要取捨和共識。例如，如果業務人員認為需要迅速搶佔市場，而產品經理和技術人員認為不應推出不完美的產品，那麼就需要透過溝通和協商來達成共識。

三角關係協作模式能夠發揮出“1+1+1>3”的效果，因為每個角色都能為其他角色提供支援和補充，彼此借力。技術人員可以透過資料分析提前發現客戶體驗問題，產品經理可以給技術人員提供前瞻性的資訊，業務人員可以提供真實客戶案例以完善產品設計。這種有效的補位是在每個角色做好本職工作的前提下進行的。

在這種三角關係設計下，技術架構師能夠更好地找到自己的位置，感受到業務目標的壓力，並更加積極主動地為業務成功貢獻自己的力量。三角關係協作模式有助於確保技術架構師不再處於資訊鏈路的末端，而是成為推動業務成功的關鍵角色。

架構師的系統思維

我們根據常見的結構化思考方法總結了一套架構設計思考法，旨在幫助技術架構師從多個視角和維度建立全面的系統思維，如圖 1-4 所示。

圖1-4 架構設計思考法

0→1：從混沌無序中抽取主線

這個架構設計思考法的核心意義在於：在面對一系列困惑和混亂時，首先應緊密關注問題本身，還原客觀事實，並迅速構建一個初步版本，以此作為啟動認知和迭代最佳化的討論基礎。隨後，圍繞這個初步版本逐步疊加和豐富其他維度的內容，直至形成一個完整的架構設計方案。

例如，在討論某系統能力升級方案時，有些人傾向於使用 PPT 繪製模組概念圖，並輔以抽象詞彙進行講解，這往往讓人感到困惑。單純透過概念推導概念的方式難以準確傳達意圖。為此，可以採取以下策略。

（1）使用者視角的客觀世界還原：首先，應該從使用者視角出發，透過講述使用者故事，使用互動流程和真實資料來描述問題。這種方法可以幫助團隊快速達成共識，並清晰地理解客觀事實。這個“1”將成為後續討論的核心物件，可以透過互動時序圖或 Excel 表格來直觀展示，而不是使用複雜的概念模組圖。

（2）客觀資訊的結構化整合與提煉：僅僅確定“1”是不夠的，還需要對它進行結構化的整合和提煉。透過結構化處理，資訊才能轉化為有意義的知識，並與以往的經驗相結合，從而進行初步的架構設計。例如，在處理資料流時，可以識別出哪些是可合併的同類項，哪些需要進行平衡校驗邏輯。

（3）加入多元視角的檢驗與抽象：經過第（2）步的處理，使“1”變得更加完整。接下來，需要加入多元視角的抽象和校驗，例如考慮重要異常、投資回報率、合理性、擴充套件性等因素，以形成一個完整的可實施主線。透過這種方法，在討論方案時，使用互動序列圖或表格來聚焦討論，可以幫助團隊從混亂中快速提煉出關鍵點，並形成一個清晰、可行的架構設計主線。

1→0：找尋影響問題的關鍵點

架構設計思考法的第二條建議是，在面對眾多因素而難以抓住關鍵點時，可以採用刪除法（即考慮去掉某個因素是否可行），以識別出真正的關鍵點。

例如，技術團隊每年進行技術規劃時常常感到痛苦，這是因為腦海中有無數需求、有無數的待最佳化點，還有無數的想法在縈繞，每個點都似乎值得在新的一年裡進行突破。然而，如果沒有有效的方法來抓住關鍵點，最終的結果可能僅僅是一個簡單的表格。

為了應對這一問題，可以採取以下幾種方法。

因果判斷法：當需要透過現象探究真實原因，以識別影響事情發展的關鍵點時，推薦使用因果判斷法進行檢驗：這個點到底是“因”，還是“果”。例如，某系統近期研發效能低下，就是“果”。要找到造成“果”的“因”：比如，系統架構太複雜，使得實現任何業務需求，都要修改大量程式碼。值得注意的是，因果關係往往是巢狀的，系統架構太複雜本身也可以視為“果”，而它的“因”可能是系統模型抽象層次不清晰。

樹幹樹枝法：有時候，各個因素之間並非單純的因果關係，而是依附關係，如同樹枝依附於樹幹。為找到關鍵點，可以嘗試使用樹幹樹枝法進行檢驗：如果去除這個點，是否會影響到整體，是否會導致結論不成立。透過多輪分析，繪製出樹幹與樹枝的關係，樹幹就是要找的關鍵點。例如，在上述研發效能低下的問題中，“因”還有很多，如系統架構的複雜性、研發流程的冗長、人員技能熟悉度低、業務需求分析不到位等。每個因素都可能成為樹幹級關鍵點。在專案組組建的初期階段，可以將人員技能熟悉度低視為樹幹級因素。人員技能熟悉度低可能導致業務需求分析不充分，對研發流程不熟悉，以及對系統架構缺乏瞭解。

支點撬動法：有時，各個因素之間的關聯關係較弱，難以透過上述方法確定關鍵點。此時，支點撬動法就可以發揮作用，即尋找能夠激發這一系列因素的關鍵要素。舉一個例子，在 2024 年的《政府工作報告》中提出，“充分發揮創新主導作用，以科技創新推動產業創新，加快推進新型工業化，提高全要素生產率，不斷塑造發展新動能新優勢，促進社會生產力實現新的躍升。”在這個場景中，科技創新便是撬動現代化產業建設的關鍵要素。

以上是目前實踐中總結的一些抓取關鍵點的方法。但在此過程中，我們一定要注意粒度問題，避免走極端。例如，一提到關鍵點，就立刻深入本質；一觸及本質，就急於找根因；一找根因，就深挖到人性層面，最終將所有問題歸咎於人性原罪。這種做法既缺乏實際價值，也無助於問題的有效解決。

1→2：複雜問題拆解分而治之

架構設計思考法的第三條建議是，面對抽象問題時，應該採用拆解的方法（一分為二），透過分而治之的策略來確定每個小問題的邊界。透過解決這些小問題，可以降低全域性思考的難度，從而更快地形成解決方案。在處理複雜問題時，可以採取以下兩種典型的技術架構動作。

縱深拆解：拆解是一種有效的分而治之的方法，但它不僅僅是簡單的物理分割，而應該是有邏輯的、有機的拆解。例如，將生產環境故障指標直接分配給每個團隊成員是無效的。相反，應該拆解為建設如故障發現、故障應急恢復等能力，然後對這些能力進行技術架構設計，以實現最終目標。

橫向解剖：在討論業務需求時，經常會遇到僵局，比如產品經理認為這是技術架構問題，技術架構師認為這是業務需求問題，而業務人員則認為這是產品設計問題。要打破這種僵局，就需要對問題進行一層層的解剖，清晰地區分業務需求問題、產品設計問題和技術架構方案。每一層都應該向上游遮蔽下游的細節，這樣才能清楚地定義問題。通常，從參與角色的角度進行解剖更容易獲得全面和深入的理解。

1 →N：面向未來的前瞻性思考

在進行技術架構設計時，前瞻性至關重要，避免被業務需求牽著走。在考慮技術方案時，不僅要關注當前條件，還要預見到系統從 1 到 N 過程中可能遇到的挑戰。

前瞻性的核心在於對時間的考量：從長遠角度出發，預測關鍵生產資料可能的變化，並據此進行架構設計。這些關鍵生產資料如下所述。

業務場景：作為系統演進的驅動力，包括市場份額、客戶價值、競爭對手動態等。

團隊組織：人是系統的創造者和推動者，若不能發揮人的積極性，系統就無法支援業務的快速發展。

技術架構：本身是一種極其重要的生產資料，這一點卻常常被許多人忽視。例如，在設計不合理的程式碼中，我們經常看到同一個語義的常量在多個不同的地方被重複定義，這無疑增加了維護的難度和成本。相反，透過簡單的技術架構最佳化，如定義一個靜態常量，就能輕鬆解決這一問題。

針對這些生產資料，以下是從 1 到N 擴充套件的幾個技巧。

（1）架構考慮所有可能性，但做有限且明確的實施。

在處理充滿不確定性的業務場景時，技術架構師面臨的一個挑戰是如何在缺乏詳細資訊的情況下提供專業的意見和評估。在這種情況下，技術架構師應該基於自己的經驗和對業務變化的理解，羅列所有可能的情況，併為每種情況提供相應的架構方案和評估。

例如，技術架構師可以提出：“基於××業務的假設，系統架構需要××量級的工作量，進行××樣的能力迭代升級，可以實現××業務效果和價值，但需要進一步××業務輸入。” 這樣的做法可以幫助業務人員更清楚地理解不同選擇的影響，並做出更明智的決策。

然而，在實施技術架構時，並不需要實現所有可能性。技術架構設計可以很宏大，但實施應該從小處著手。對於不確定的部分，應該做好擴充套件設計，以便在未來有需要時可以輕鬆新增新功能。對於實在無法預測的部分，應該明確拒絕（寧願不做也不錯做），以避免留下潛在的風險和隱患。

（2）沒有靠譜的人，只有靠譜的機器。

在生產環境故障覆盤會議中，技術人員的積極性和責任感是值得肯定的，但過度依賴個人稽核並不利於系統的長期穩定和發展。當技術人員提出“以後××類變更都加上我來稽核一個環節，我確認沒問題再往後走”的建議時，雖然體現了個人擔當，但這種做法並不推薦。

這種做法可能導致系統變得脆弱，因為它過度依賴個別人員的判斷和決策。在技術方案設計時，我們應該追求自動化和系統化的解決方案。能夠由系統自動執行的任務，就不應該依賴人工流程來保障。能夠透過領域模型進行校驗的問題，就不應該依賴旁路系統的側面印證。

（3）提前思考“幸福”的煩惱。

許多技術人員渴望參與高併發大流量系統的開發，但在實際編碼過程中，往往採取簡單直接的方式，忽視了未來可能面臨的大流量和高併發問題，以及對資損風險的考量。他們可能會辯稱，當前的業務量尚未達到需要考慮這些問題的水平，或者認為這類事件發生的機率極低，因此在一期工程中不必過度關注。

然而，要構建能夠應對未來挑戰的技術架構，必須從第一行程式碼開始就進行深思熟慮。這意味著在編碼過程中，技術人員應該提前考慮高併發、大流量，以及系統的嚴謹性。

通常，技術人員更傾向於享受從 0 到 1 的創新過程，而在網際網路快速迭代的環境中，從 1 到N 的擴充套件過程往往被壓縮。因此，在從 0 到 1 的階段就加入對從1 到 N 架構的預判至關重要。很多時候，系統的結構性問題在最初的設計階段就已經確定，後期很難更改。如果要修改，只有一個機會，那就是在設計之初。

-1 ←→ 1：上下左右全方位思考

在考慮技術方案時，不要一條道走到黑，應採取前後、上下、左右、正反全方位的思考方式，以確保方案具有全面性和多維視角。以下是一些實踐中常用的思考方法。

正反思考法：在日常的架構設計、系統分析和測試文件編寫中，對於正常業務需求功能的描述通常沒有太大問題，只需遵循既定步驟進行撰寫即可。然而，普遍存在的一個現象是對問題的反面論述不足。例如，文件中可能會詳細描述支付的正常流程，但對於退款或拒付等反向流程的描述卻往往不夠細緻。業務功能的正常流轉可能被充分論述，而異常場景的討論卻常常被草草帶過。然而，只有將正面和反面結合起來，才能構成一個完整的體系，對反面的思考實際上是對正面的有效補充。通常情況下，雖然正面情況出現的機率較高，但消除反面情況中可能出現錯誤的影響所需投入的精力，往往遠超過正面情況帶來的收益。

極限思考法：在評估技術架構風險時，應深入思考最壞情況下可能對業務造成的影響。透過極限設問，可以激發團隊考慮最極端的情況，並準備相應的風險應對措施。這樣，即使在面對最壞情況時，也能有足夠的準備和應對策略，從而更加樂觀地進行方案設計。

對稱思考法：在審查程式碼或邏輯結構時，應從整體上檢查其邏輯結構的完整性、對稱性和美觀性。例如，使用 if 語句時，應確保有相應的 else 語句，以覆蓋所有可能的場景。對稱思考法不僅有助於提高程式碼的可讀性和美觀性，還能強制性地提醒開發者考慮邏輯的對立面，從而減少因考慮不周而導致的錯誤。對稱的美是一種生產力，因為美的事物往往簡潔並能夠直接觸及本質。同樣，技術人在編寫程式時追求的也是邏輯清晰、簡潔，並直達業務本質。通常，邏輯結構清晰的程式基本上沒有大問題。而那些邏輯不清晰的程式（例如，變數命名隨意，方法缺乏語義）往往都有 Bug。

M×N → M+N：解耦降低複雜度

在技術架構設計過程中，從系統耦合的角度出發，尋找解耦的突破口是一種有效的方法。例如，高速公路網的連線並不是在所有目的地之間都修建一條高速公路，而是透過建立主幹道和分支道路來實現，這種方式降低了系統的耦合度，從 M×N 的複雜度降低到了 M+N。

技術架構解耦可從以下兩個方向進行。

解耦上下游關聯性：在業務和技術架構發展的早期階段，為了快速解決問題，通常將多個模組混合在一起，例如電商網站最初可能將會員模組、交易模組、庫存模組等雜糅在一個系統中實現。然而，隨著業務的發展和架構的演進，對這些模組進行解耦是必然的。解耦的目的在於重新定義各個模組的邊界，平衡新業務發展要求下各方發展速度的差異，並透過解耦實現各自的快速發展。

在服務化的分散式架構中，解耦是非常常見的做法。幾乎所有的跨域系統架構升級都涉及解耦。例如，電商網站後續發展大多會進行領域服務的拆分，將會員模組獨立為會員系統，交易模組獨立為交易系統等。

解耦各個角色的依賴：在領域模型抽象之前，需要注意到解耦各個角色之間的依賴關係。技術架構師在資訊不足的情況下，應基於經驗做出假設，並將技術架構設計與商業選擇、產品設計等解耦開來。透過這種解耦，不同角色可以基於服務水平協議（SLA）進行互動，並基於自身的專業知識為對方提供更多的選項和可能性。這種解耦有助於提高系統的前瞻性和競爭力。

在幾乎所有大型系統架構的升級中，都可以看到解耦思考法的應用。因此，當缺乏設計思路時，建議從解耦的角度審視和思考，可能會帶來新的發現和收穫。

架構思維勝在無招

架構設計思考法為技術架構師提供了一種理解和應用系統思維的途徑，但它並不是架構思維的唯一或最終解決方案。架構思維是需要不斷打磨和提升的，對於架構師而言，建立系統化的思維模式並不是依靠一成不變的方法，而是為了在不同的時間、空間背景下，透過廣泛的經驗積累和實踐訓練，靈活地提出適合當前情境的架構方案。