古人云：“活到老，學到老。”互聯網算是最辛苦的行業之一，“加班”對工程師來說已是“家常便飯”，同時互聯網技術又日新月異，很多工程師都疲于應付，叫苦不堪。以至于長期以來流傳一個很廣的誤解：35歲是程序員工作的終點。

如何在繁忙的工作中做好技術積累，構建個人核心競爭力，相信是很多工程師同行都在思考的問題。本文是我自己的一些總結，試圖從三個方面來解答：

第一部分闡述了一些學習的原則。任何時候，遵循一些經過檢驗的原則，都是影響效率的重要因素，正確的方法是成功的秘訣。提升工作和學習效率的另一個重要因素是釋惑和良好心態。第二部分分析了我在工作中碰到和看到的一些典型困惑。成為優秀的架構師是大部分初中級工程師的階段性目標。第三部分剖析架構師的能力模型，讓大家對目標所需能力有一個比較清晰的認知。

如何學習

在繁忙的工作中，持之以恒、不斷學習和進步是一件艱巨的任務，需要堅強的毅力和堅定的決心。如果方法不得當，更是事倍功半。幸好我們的古人和現在哲人已經總結了很多優秀的學習方法論，這里匯總了一些重要原則。遵循這些方法必會對大家的工作學習大有裨益。

貴在堅持

有報道指出，過去幾十年的知識量超過之前人類幾千年的知識量總和。而計算機領域絕對是當代知識更新最快的領域之一，因此，工程師必須要接受這樣一個現實，現在所掌握的深厚知識體系很快就會被淘汰。要想在計算機領域持續做優秀架構師，就必須不停的學習，掌握最新技術。總之，學不可以已。

所謂“冰凍三尺，非一日之寒，水滴石穿，非一日之功”，通往架構師的道路漫長而又艱巨，輕易放棄，則所有付出瞬間付之東流。要想成為優秀的架構師，貴在堅持！雖然知識更新很快，但是基礎理論的變化卻非常緩慢。這就是“道”和“象”關系，縱是世間萬象，道卻萬變不離其宗。對于那些非常基礎的理論知識，我們需要經常復習，也就是“學而時習之”。

重視實踐

古人云：“紙上得來終覺淺，絕知此事要躬行。” 學習領域有所謂721模型：個人的成長70%來自于崗位實踐，20%來自向他人學習，10%來自于培訓。雖然這種理論存在爭議，但對于工程師們來說，按照實踐、學習和培訓的方式進行重要性排序，大致是不錯的。所以重視實踐，在實踐中成長是最重要的學習原則。

人類的認知有兩種：感性認知和理性認知。這兩種認知互相不可替代性。實踐很大程度來自于感性學習，看書更像是理性學習。以學開汽車做例子，很難想象什么人能夠僅僅通過學習書本知識就會開汽車。

書本知識主要是傳道——講述抽象原型，而對其具體應用場景的講述往往含糊其辭，對抽象原型之間的關系也是淺嘗輒止。采用同樣精確的語言去描述應用場景和關聯關系將會失去重點，讓人摸不著頭腦。所以，僅僅通過看書來獲得成長就像是用一條腿走路。

重視實踐，充分運用感性認知潛能，在項目中磨煉自己，才是正確的學習之道。在實踐中，在某些關鍵動作上刻意練習，也會取得事半功倍的效果。

重視交流

牛頓說：“如果說我看得比別人遠一些，那是因為我站在巨人的肩膀上。”我們需要從別人身上學習。從老師、領導、同事、下屬甚至對手身上學習，是快速成長的重要手段。向老師和領導學習已經是人們生活習慣的一部分了。但是從同事甚至對手那里學習也很重要，因為這些人和我們自身更相似。所以要多多觀察，取其所長，棄其所短。對于團隊的小兄弟和下屬，也要“不恥下問”。

此外，在項目中積極參與具體方案討論也非常重要。參與者先驗感知了相關背景，并且討論的觀點和建議也是綜合了發言者多種知識和技能。所以，討論讓參與者能夠非常全面，立體地理解書本知識。同時，和高手討論，他們的觀點就會像修剪機剪樹枝一樣，快速的剪掉自己知識領域里面的疑惑點。

重視總結和輸出

工程師在實踐中會掌握大量細節，但是，即使掌握了所有細節，卻沒有深刻的總結和思考，也會陷入到“學而不思則罔”的境地。成長的“量變”來自于對細節的逐漸深入地把控，而真正的“質變”來自于對“道”的更深層次的理解。

將經驗輸出，接受別人的檢驗是高層次的總結。這種輸出不僅幫助了別人，對自身更是大有裨益。總結的方式有很多，包括組織分享，撰寫技術文章等等。當然“日三省吾身”也是不錯的總結方式。總之，多多總結，多多分享，善莫大焉！

解答別人的問題也是個人成長的重要手段。有時候，某個問題自己本來不太懂，但是在給別人講解的時候卻豁然開朗。所以，“誨人不倦”利人惠己。

那些令人糾結的困惑

人生是一場馬拉松，在漫長的征途中，難免有很多困惑。困惑就像枷鎖，使我們步履蹣跚，困惑就像死鎖，讓我們停滯不前。

接下來我將總結自己在工作中碰到和看到的一些典型困惑。這些困惑或者長期困擾作者本人，或者困擾我身邊的同事和朋友。當這些困惑被釋然之后，大家都感覺如重獲釋，為下一階段的征程提供滿滿的正能量。人生就像一場旅途，不必在乎目的地，在乎的，應該是沿途的風景，以及看風景的心情。良好的心態是技術之旅最好的伴侶。期望通過這個解惑之旅，讓大家擁有一個愉快的心情去感受漫長的學習旅途。

學無止境嗎

必須要承認一個殘酷的現實：人的生命是有限的，知識卻是無限的。用有限的生命去學習無限的知識是不可能完成的任務。一想到此，有些工程師不免產生一些悲觀情緒。如果方法得當并且足夠勤奮，悲傷大可不必。

雖然，人類的整體知識體系一直在擴張。但是就很多重要的工程細分領域，基礎理論并不高深。計算機的很多重要領域，工程師有能力在有限時間內抓住核心要害。

比如，密碼學被認為是門非常高深的學科，但是一大類密碼技術的基礎是數論中一個非常簡單的理論——素因數分解：給出兩個素數，很容易算出它們的積，然而反過來給定兩個素數的積，分解的計算量卻非常驚人。

“一致性”算得上是計算機領域里面最經典的難題，它是所有分布式系統的基礎，從多核多CPU到多線程，從跨機器到跨機房，無所不在，幾乎所有的計算機從業人員都在解決這個問題，但是Paxos給出了一個很優雅的解決方案。

權限管理是很多工程師的噩夢，但如果你能搞定“Attribute Based Access Control（ABAC）”和“Role-Based Access Control（RBAC）”，也能達到相當高度。

另外，技術學習是一場對抗賽，雖然學無止境，超越大部分對手就是一種勝利。所以，以正確的學習方式，長時間投入就會形成核心競爭力。

沒有絕對高明的技術，只有真正的高手

致力于在技術上有所成就的工程師，都夢想有朝一日成為技術高手。但技術高手的標準卻存在很大的爭議。這是一個有著悠久歷史的誤解：以某種技術的掌握作為技術高手的評判標準。我經常碰到這樣一些情景：因為掌握了某些技術，比如Spring、Kafka、Elasticsearch等，一些工程師就自封為高手。有些工程師非常仰慕別的團隊，原因竟是那個團隊使用了某種技術。

這種誤解的產生有幾個原因：首先，技多不壓身，技術自然是掌握的越多越好，掌握很多技術的人自然不是菜鳥。其次，在互聯網時代來臨之前，信息獲取是非常昂貴的事情。這就導致一項技能的掌握可以給個人甚至整個公司帶來優勢地位。互聯網時代，各種框架的出現以及開源的普及快速淘汰或者降低了很多技能的價值，同時降低了很多技術的學習門檻。所以，在當前，掌握某項技能知識只能是一個短期目標。懷揣某些技能就沾沾自喜的人需要記住：驕傲使人退步。

所謂麻雀雖小，五臟俱全。如果讓你來做造物主，設計麻雀和設計大象的復雜度并沒有明顯區別。一個看起來很小的業務需求，為了達到極致，所需要的技術和能力是非常綜合和高深的。真正的高手不是拿著所掌握的技術去卡客戶需求，而是傾聽客戶的需求，給出精益求精的方案。完成客戶的需求是一場擂臺賽，真正的高手，是會見招拆招的。

不做項目就無法成長嗎

在項目中學習是最快的成長方式之一，很多工程師非常享受這個過程。但是一年到頭都做項目，你可能是在一家外包公司。對于一個做產品的公司，如果年頭到年尾都在做項目，要不然就是在初步創業階段，要不然就是做了大量失敗的項目，總之不算是特別理想的狀態。正常情況，在項目之間都會有一些非項目時間。在這段時間，有些同學會產生迷茫，成長很慢。

項目真的是越多越好嗎？答案顯然是否定的。重復的項目不會給工程師們帶來新的成長。不停的做項目，從而缺乏學習新知識的時間，會導致“做而不學則殆”。真正讓工程師出類拔萃的是項目的深度，而不是不停地做項目。所以，在項目之間的空檔期，工程師們應該珍惜難得的喘息之機，深入思考，把項目做深，做精。

如何提高項目的深度呢？一般而言，任何項目都有一個目標，當項目完成后，目標就算基本達成了。但是，客戶真的滿意了嗎？系統的可用性、可靠性、可擴展性、可維護性已經做到極致了嗎？這幾個問題的答案永遠是否定的。所以，任何一個有價值的項目，都可以一直深挖。深挖項目，深度思考還可以鍛煉工程師的創造力。期望不停地做項目的人，就像一個致力于訓練更多千里馬的人是發明不出汽車的。鍛煉創造力也不是一蹴而就的事情，需要長時間地思考。總之，工程師們應該總是覺得時間不夠用，畢竟時間是最寶貴的資源。

職責真的很小嗎

很多時候，一個工程師所負責系統的數量和團隊規模與其“江湖地位”正相關。但是，江湖地位與技術成長沒有必然關聯。提升技術能力的關鍵是項目深度以及客戶的挑剔程度。項目越多，在單個項目中投入的時間就越少，容易陷入膚淺。特別需要避免的是“ 在其位不謀其政”的情況。團隊越大，在管理方面需要投入的精力就越多。在管理技巧不成熟，技術眼界不夠高的前提強行負責大團隊，可能會導致個人疲于應付，團隊毫無建樹。最終“ 一將無能，累死三軍”，效果可能適得其反。

從技術發展的角度來說，技術管理者應該關注自己所能把控的活躍項目的數量，并致力于提高活躍項目的影響力和技術深度。團隊人數要與個人管理能力、規劃能力和需求把控能力相適應。一份工作讓多個人來干，每個人的成長都受限。每個人都做簡單重復的工作，對技術成長沒有任何好處。團隊管理和項目管理需要循序漸進，忌“拔苗助長”。

一定要當老大嗎

有一些工程師的人生理想是做團隊里的技術老大，這當然是一個值得稱贊的理想。可是，如果整個團隊技術能力一般，發展潛力一般，而你是技術最強者，這與其說是幸運，不如說是悲哀。這種場景被稱之為“武大郎開店”。 團隊里的技術頂尖高手不是不能做，但為了能夠持續成長，需要滿足如下幾個條件：

首先你得是行業里面的頂尖專家了——實在很難找到比你更強的人了！

其次，你經常需要承擔對你自己的能力有挑戰的任務，但同時你擁有一批聰明能干的隊友。雖然你的技術能力最高，但是在你不熟悉的領域，你的隊友能夠進行探索并擴展整個團隊的知識。

最后，你必須要敏而好學，不恥下問。

否則，加入更強的技術團隊或許是更好的選擇，最少不是什么值得驕傲的事情。

平臺化的傳說

平臺化算得上是“高大上”的代名詞了，很多工程師擠破頭就為了和“平臺化”沾點邊。然而和其他業務需求相比，平臺化需求并沒有本質上的區別。無論是平臺化需求還是普通業務需求，它的價值都來自于客戶價值。不同點如下：

很多平臺化需求的客戶來自于技術團隊，普通需求的客戶來自于業務方。

產品經理不同。普通業務需求來自于產品經理，平臺化需求的產品經理可能就是工程師自己。長期被產品經理“壓迫”的工程師們，在平臺化上終于找到“翻身農奴把歌唱”的感覺。

很多平臺化的關注點是接入能力和可擴展性，而普通業務的關注點更多。

歸根結底，平臺化就是一種普通需求。在實施平臺化之前，一定要避免下面兩個誤區：

平臺化絕對不是諸如“統一”、“全面”之類形容詞的堆砌。是否需要平臺化，應該綜合考慮：客戶數量，為客戶解決的問題，以及客戶價值是否值得平臺化的投入。

平臺化不是你做平臺，讓客戶來服務你。一些平臺化設計者的規劃設計里面，把大量的平臺接入工作、臟活累活交給了客戶，然后自己專注于所謂“最高大上”的功能。恰恰相反，平臺化應該是客戶什么都不做，所有的臟活累活都由平臺方來做。本質上講，平臺化的價值來自于技術深度。真正體現技術深度的恰恰是設計者能夠很輕松的把所有的臟活累活搞定。

所以平臺化的最佳實踐是：投入最少的資源，解決最多的問題。平臺解決一切，客戶坐享其成。

搞基礎技術就一定很牛嗎

經常聽到同學們表達對基礎技術部同學的敬仰之情，而對搞業務技術的同學表現出很輕視，認為存儲、消息隊列、服務治理框架（比如美團點評內部使用的OCTO）、Hadoop等才能被稱為真正的技術。事實并非如此，更基礎的并不一定更高深。

比如下面這個流傳很久的段子：越高級的語言就越沒有技術含量。但真是這樣嗎，就拿Java和C來說，這是完全不同的兩種語言，所需要的技能完全不同。C或許跟操作系統更加接近一點，和CPU、內存打交道的機會更多一點。但是為了用好Java，程序員在面向對象、設計模式、框架技術方面必須要非常精通。Java工程師轉到C方向確實不容易，但作者也見過很多轉到Java語言的C工程師水土不服。

基礎技術和業務應用技術必然會有不同的關注點，沒有高低之分。之所以產生這種誤解，有兩個原因：

基礎技術相對成熟，有比較完整的體系，這給人一個高大上的感覺。業務應用技術相對來說，由于每個團隊使用的不一樣，所以成熟度參差不齊，影響力沒有那么大。

基礎技術的門檻相對來說高一點，考慮到影響面，對可靠性、可用性等有比較高的最低要求。但是門檻高不代表技術含量高，另外成熟技術相對來說在創新方面會受到很大的約束。但是最先進的技術都來自活躍的創新。

對比下來，業務技術和基礎技術各有千秋。但真正的高手關注的是解決問題，所有的技術都是技能而已。

可行性調研的那些坑

工作中開展可行性調研時有發生。做可行性調研要避免如下情況：

把可行性調研做成不可行性調研。這真的非常糟糕。不可行性的結論往往是：因為這樣或者那樣的原因，所以不可行。

避免“老鼠給貓掛鈴鐺”式的高風險可行性方案。“天下大事必作于細”，可行性調研一定要細致入微，避免粗枝大葉。

避免調研時間過長。如果發現調研進展進入到指數級復雜度，也就是每前進一步需要之前兩倍的時間投入，就應該果斷的停止調研。

可行性調研的結論應該是收益與成本的折衷，格式一般如下：

首先明確預期的結果，并按照高中低收益進行分級。

闡述達成每種預期結果需要采取的措施和方案。

給出實施各方案需要付出的成本。

工程師天生不善溝通嗎

實際工作中，溝通所導致的問題層出不窮。工程師有不少是比較內向的，總是被貼上“不善溝通”的標簽。實際上，溝通能力是工程師最重要的能力之一，良好的溝通是高效工作學習的基礎，也是通過學習可以掌握的。下面我按工程師的語言說說溝通方面的經驗。

第一類常見的問題是溝通的可靠性。從可靠性的角度來講，溝通分為TCP模式和UDP模式。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道。TCP模式當然比較可靠，不過成本比較高，UDP模式成本低，但是不可靠。在溝通可靠性方面，常見錯誤有如下兩種：

經常聽到的這樣的爭論。一方說：“我已經告訴他了”，另一方說：“我不知道這個事情呀”。把UDP模式被當作TCP模式來使用容易產生扯皮。

過度溝通。有些同學對溝通的可靠性產生了過度焦慮，不斷的重復討論已有結論問題。把TCP模式當成UDP來使用，效率會比較低。

第二類溝通問題是時效性問題。從時效性講，溝通分為：同步模式和異步模式。同步溝通形象地說就是：你現在給我聽好了。異步溝通的形象表述是：記得給我做好了。在溝通時效性方面，有如下兩種常見錯誤：

已經出現線上事故，緊急萬分。大家你一言，我一語，感覺事故可能和某幾個人有關，但是也不能完全確定，所以沒有通知相關人員。最終，一個普通的事故變成了嚴重事故。對于緊急的事情，必須要同步溝通。

半夜三點你正在熟睡，或者周末正在逛街，接到一個電話：“現在有個需求，能否立刻幫忙做完。”這會非常令人郁悶，因為那并不是緊急的事情。不是所有的需求都需要立刻解決。

有效溝通的一個重要原則是提前溝通。溝通本質是信息交流和處理，可以把被溝通對象形象地比喻成串行信息處理的CPU。提前溝通，意味著將處理請求盡早放入處理隊列里面。下面的例子讓很多工程師深惡痛絕：一個需求策劃了1個月，產品設計了2周。當開發工程是第一次聽說該需求的時候，發現開發的時間是2天。工程師據理力爭，加班加點1周搞定。最后的結論是工程師非常不給力，不配合。就像工程師討厭類似需求一樣。要協調一個大項目，希望獲得別人的配合，也需要盡早溝通。

有效溝通的另外一個重點是“不要跑題”。很多看起來很接近的問題，本質上是完全不同的問題。比如：一個會議的主題是“如何實施一個方案”，有人卻可能提出“是否應該實施該方案”。 “如何實施”和“是否應該實施”是完全不同的兩個問題，很多看起來相關的問題實際上跑題很遠。“跑題”是導致無效溝通的重要原因。

良好溝通的奧秘在于能掌握TCP模式和UDP模式精髓，正確判斷問題的緊急性，盡量提前溝通，避免跑題。

帶人之道

有些初為導師的工程師由于擔心畢業生的能力太弱，安排任務時候諄諄教誨，最后感覺還是有所顧慮，干脆自己寫代碼。同樣的事情發生在很多剛剛管理小團隊的工程師身上。最終的結果他們：寫完所有的代碼，讓下屬無代碼可寫。“ 事必躬親”當然非常糟糕，最終的往往是團隊的整體績效不高，團隊成員的成長很慢，而自己卻很累。

古人說：“用人不疑，疑人不用。”這句話并非“放之四海而皆準”。在古代，受限于通信技術，反饋延遲顯著，而且信息在傳遞過程中有大量噪音，變形嚴重。在這種情況下，如果根據短期內收集的少量變形的信息做快速決斷，容易陷于草率。在公司里，這句話用于選人環節更為恰當，應該改為：錄用不疑，疑人不錄。

考慮到招聘成本，就算是在錄用層面，有時候也無法做到。作為一個小團隊的管理者，能夠快速準確的獲取團隊成員的各種反饋信息，完全不需要“用人不疑，疑人不用”。用人的真正理論基礎來自于“探索和利用”（Exploration and Exploitation ）。不能因為下屬能做什么就只讓他做什么，更不能因為下屬一次失敗就不給機會。

根據經典的“探索和利用”（Exploration and Exploitation ）理論，良好的用人方式應該如下：

首選選擇相信，在面臨失敗后，收縮信任度。

查找失敗的原因，提供改進意見，提升下屬的能力。

總是給下屬機會，在恰當地時機給下屬更高的挑戰。 總之，蒼天大樹來自一顆小種子，要相信成長的力量。

效率、效率、效率

經常看到有些同學給自己的績效評分是100分——滿分，原因是在過去一段時間太辛苦了，但最終的績效卻一般般。天道酬勤不錯，但是天道更酬巧。工程師們都學過數據結構，不同算法的時間復雜度的差距，僅僅通過更長的工作時間是難以彌補的。為了提升工作學習效率，我們需要注意以下幾點：

主要關注效率提升。很多時候，與效率提升所帶來的收益相比，延長時間所帶來的成果往往不值得一提。

要有清晰的結果導向思維。功勞和苦勞不是一回事。

做正確的事情，而不僅僅正確地做事情。這是一個被不斷提起的話題，但是錯誤每天都上演。為了在規定的時間內完成一個大項目，總是要有所取舍。如果沒有重點，均勻發力，容易事倍功半。如果“南轅北轍”，更是可悲可嘆。

架構師能力模型

前面我們已經講完了原則和一些困惑，那么工程師到底應該怎么提升自己呢？

成為優秀的架構師是大部分初中級工程師的階段性目標。優秀的架構師往往具備七種核心能力：編程能力、調試能力、編譯部署能力、性能優化能力、業務架構能力、在線運維能力、項目管理能力和規劃能力。

這幾種能力之間的關系大概如下圖。編程能力、調試能力和編譯部署能力屬于最基礎的能力。不能精通掌握這三種能力，很難在性能優化能力和業務架構能力方面有所成就。具備了一定的性能優化能力和業務架構能力之后，才能在線運維能力和項目管理能力方面表現優越。團隊管理能力是最高能力，它對項目管理能力的依賴度更大。

編程能力

對工程師而言，編程是最基礎的能力，必備技能。其本質是一個翻譯能力，將業務需求翻譯成機器能懂的語言。

提升編程能力的書籍有很多。精通面向對象和設計模式是高效編程的基礎。初級工程師應該多寫代碼、多看代碼。找高手做Code Review，也是提升編程水平的捷徑。

調試能力

程序代碼是系統的靜態形式，調試的目的是通過查看程序的運行時狀態來驗證和優化系統。本質上講，工程師們通過不斷調試可以持續強化其通過靜態代碼去預測運行狀態的能力。所以調試能力也是工程師編程能力提升的關鍵手段。很早之前有個傳說：“調試能力有多強，編程能力就有多強。”不過現在很多編輯器的功能很強大，調試能力的門檻已經大大降低。

調試能力是項目能否按時、高質量提交的關鍵。即使一個稍具復雜度的項目，大部分工程師也無法一次性準確無誤的完成。大項目都是通過不斷地調試進行優化和糾錯的。所以調試能力是不可或缺的能力。

多寫程序，解決Bug，多請教高手是提升調試能力的重要手段。

編譯部署能力

編譯并在線上部署運行程序是系統上線的最后一個環節。隨著SOA架構的普及以及業務復雜度的增加，大部分系統只是一個完整業務的一個環節，因此，本地編譯和運行并不能完全模擬系統在線運行。為了快速驗證所編寫程序的正確性，編譯并在線上部署就成了必要環節。所以編譯部署能力是一個必備技能。

讓盤根錯節的眾多子系統運行起來是個不小的挑戰。得益于SOA架構的普及以及大量編譯、部署工具的發展，編譯部署的門檻已經大大降低。基于應用層進行開發的公司，已經很少有“編譯工程師”的角色了。但是對于初級工程師而言，編譯部署仍然不是一個輕松的事情。

性能優化能力

衡量一個系統成功的一個重要指標是使用量。隨著使用量的增加和業務復雜度的增加，大部分系統最終都會碰到性能問題。 性能優化能力是一個綜合能力。因為：

影響系統性能的因素眾多，包括：數據結構、操作系統、虛擬機、CPU、存儲、網絡等。為了對系統性能進行調優，架構師需要掌握所有相關的技術。

精通性能優化意味著深刻理解可用性、可靠性、一致性、可維護性、可擴展性等的本質。

性能優化與業務強耦合，最終所采取的手段是往往折衷的結果。所以，性能優化要深諳妥協的藝術。

可以說，性能優化能力是工程師們成長過程中各種技能開始融會貫通的一個標志。這方面可以參考之前的博客文章“常見性能優化策略的總結”。市場上還有很多與性能優化相關的書籍，大家可以參考。多多閱讀開源框架中關于性能優化方面的文檔和代碼也不失為好的提升手段。動手解決線上性能問題也是提升性能優化能力的關鍵。如果有機會，跟著高手學習，分析性能優化解決方案案例（我們技術博客之前也發表了很多這方面的文章），也是快速提升性能優化能力的手段。

在線運維能力

如果說性能優化能力體現的是架構師的靜態思考能力，在線運維能力考驗的就是動態反應能力。殘酷的現實是，無論程序多么完美，Bug永遠存在。與此同時，職位越高、責任越大，很多架構師需要負責非常重要的在線系統。對于線上故障，如果不能提前預防以及快速解決，損失可能不堪設想，所以在線運維能力是優秀架構師的必備技能。

為了對線上故障進行快速處理，標準化的監控、上報、升級，以及基本應對機制當然很重要。通過所觀察到的現象，快速定位、緩解以及解決相關癥狀也相當關鍵。這要求架構師對故障系統的業務、技術具備通盤解讀能力。解決線上故障的架構師就好比一個在參加比賽F1的車手。賽車手必須要了解自身、賽車、對手、同伴、天氣、場地等所有因素，快速決策，不斷調整。架構師必須要了解所有技術細節、業務細節、處理規范、同伴等眾多因素，快速決斷，迅速調整。

在線運維本質上是一個強化學習的過程。很多能力都可以通過看書、查資料來完成，但在線運維能力往往需要大量的實踐來提升。

業務架構能力

工程師抱怨產品經理的故事屢見不鮮，抱怨最多的主要原因來自于需求的頻繁變更。需求變更主要有兩個來源：第一個原因是市場改變或戰略調整，第二個原因是偽需求。對于第一個原因，無論是工程師還是產品經理，都只能無奈的接受。優秀的架構師應該具備減少第二種原因所導致的需求變更的概率。

偽需求的產生有兩個原因：

第一個原因是需求傳遞變形。從信息論的角度來講，任何溝通都是一個編碼和解碼的過程。典型的需求從需求方到產品經理，最終到開發工程師，最少需要經歷三次編碼和解碼過程。而信息的每一次傳遞都存在一些損失并帶來一些噪音，這導致有些時候開發出來的產品完全對不上需求。此外，需求方和產品經理在需求可行性、系統可靠性，開發成本控制方面的把控比較弱，也會導致需求變形。

第二個原因就是需求方完全沒有想好自己的需求。

優秀的架構師應該具備辨別真偽需求的能力。應該花時間去了解客戶的真實業務場景，具備較強的業務抽象能力，洞悉客戶的真實需求。系統的真正實施方是工程師，在明確客戶真實需求后，高明的架構師應該具備準確判斷項目對可行性、可靠性、可用性等方面的要求，并能具備成本意識。最后，由于需求與在線系統的緊耦合關系，掌握在線系統的各種細節也是成功的業務架構的關鍵。隨著級別的提升，工程師所面對的需求會越來越抽象。承接抽象需求，提供抽象架構是架構師走向卓越的必經之途。

市場上有一些關于如何成為架構師的書，大家可以參考。但是架構能力的提升，實踐可能是更重要的方式。業務架構師應該關注客戶的痛點而不是PRD文檔，應該深入關注真實業務。掌握現存系統的大量技術和業務細節也是業務架構師的必備知識。

項目管理能力

作為工業時代的產物，分工合作融入在互聯網項目基因里面。架構師也需要負責幾個重大項目才能給自己正名。以架構師角色去管理項目，業務架構能力當然是必備技能。此外，人員管理和成本控制意識也非常重要。

項目管理還意味著要有一個大心臟。重大項目涉及技術攻關、人員變動、需求更改等眾多可變因素。面臨各種變化，還要在確保目標順利達成，需要較強的抗壓能力。

人員管理需要注意的方面包括：知人善用，優化關系，簡化溝通，堅持真理。

知人善用意味著架構師需要了解每個參與者的硬技能和軟素質。同時，關注團隊成員在項目過程中的表現，按能分配。

優化關系意味著管理團隊的情緒，畢竟項目的核心是團隊，有士氣的團隊才能高效達成目標。

簡化溝通意味著快速決策，該妥協的時候妥協，權責分明。

堅持真理意味著頂住壓力，在原則性問題上絕不退步。

成本控制意味著對項目進行精細化管理，需要遵循如下幾個原則：

以終為始、確定里程碑。為了達成目標，所有的計劃必須以終為始來制定。將大項目分解成幾個小階段，控制每個階段的里程碑可以大大降低項目失敗的風險。

把控關鍵路徑和關鍵項目。按照關鍵路徑管理理論（CPM）的要求，架構師需要確定每個子項目的關鍵路徑，確定其最早和最晚啟動時間。同時，架構師需要關注那些可能會導致項目整體延期的關鍵節點，并集中力量攻破。

掌控團隊成員的張弛度。大項目持續時間會比較長，也包含不同工種。項目實施是一個不斷變化的動態過程，在這個過程中不是整個周期都很緊張，不是所有的工種都一樣忙。優秀的架構師必須要具備精細閱讀整體項目以及快速反應和實時調整的能力。這不僅僅可以大大降低項目成本，還可以提高產出質量和團隊滿意度。總體來說，“前緊后松”是項目管理的一個重要原則。

項目管理方面的書籍很多。但是，提高業務架構能力同樣重要。積極參與大項目并觀察別人管理項目的方式也是非常重要的提升手段。

團隊管理能力

不想做CTO的工程師不是一個好的架構師。走向技術管理應該是工程師的一個主流職業規劃。團隊管理的一個核心能力就是規劃能力，這包括項目規劃和人員規劃。良好的規劃需要遵循如下原則：

規劃是利益的博弈。良好的規劃上面對得起老板，中間對得起自己，下面對得起團隊。在三者利益者尋找平衡點，實現多方共贏考驗著管理者的智慧和精細拿捏的能力。

任何規劃都比沒有規劃好。沒有規劃的團隊就是沒頭的蒼蠅，不符合所有人的利益。

規劃不是本本主義。市場在變，團隊在變，規劃也不應該一成不變。

客戶至上的是項目規劃的出發點。

就人員規劃而言，規劃需要考量團隊成員的能力、績效、成長等多方面的因素。

市場上有很多規劃管理方面的書籍，值得閱讀。最優化理論雖然是技術書籍，但它是規劃的理論基礎，所以不妨多看看翻閱一下。從自我規劃開始，多多學習別人的規劃也是規劃能力提升的重要手段。