前段時間，朋友圈被《我是技術總監，你干嘛總問我技術細節》刷屏了，微信群里也有不少討論。

就我所看到的情況，各種意見都有：

• 有人認為“技術人不能丟掉技術”。
• 也有人認為“工作做到上面都是考驗人性”。
• 還有人認為“工種不同，技術細節不清楚很正常”。

借這個機會，我想談談自己的經歷。十多年前，我曾經去 BAT 中的一家面試過(到現在也是我唯一一次 BAT 的面試經歷)。

當時剛畢業幾年，寫代碼解決一般問題任務已經“得心應手”了，各方面知識也懂一點，會搭 MySQL 的 Master-Slave，會用 Memcache，HTTP 協議也基本熟悉……

在那個許多公司還在為 100 萬 PV 就頭疼的年代，這樣的水準在技術上算比較領先了。所以我以為，這次面試應當是十拿九穩。

結果大大出乎我的意料，可以說是“慘敗”。我熟悉的領域一個也沒有談起，我解決的問題一個也沒有問到，卻問了一大堆“技術細節”問題。比如一個 Int 變量要占幾個字節，字符串的查找，替換怎樣最快……

在學校里，我最熟悉的 Java，C 和 C++ 的課程只是囫圇吞棗，這類知識早就忘記了，做題比較多的也是離散數學、數值計算等等，工作了之后一直做 Java，根本不會深入到這樣的細節。

所以，面試結果用“慘敗”來形容，是一點不夸張的。

當時我覺得很委屈，對已經工作的人，為什么要考這些細節的書本知識?而且是日常開發根本用不到的書本知識?難道不應當重視實際經驗嗎?

等再工作幾年我逐漸發現，這些原本不是“細節的書本知識”。如果你要解決的問題稍微有點挑戰性，沒有現成工具可以利用，只能靠自己思考和分析，或者借鑒其他現成工具的原理，就離不開這些看不起的“細節知識”。

比如，后來(一直到如今也是)我經常說：“好的程序員不會凡事都靠實地測試，而是會預先計算”，就必須用到這些細節的知識。

拿如今最熱門的“高并發”應用來說，單個節點每秒處理多少個請求，每個請求包含哪些數據，每部分數據的大小是多少，機器的帶寬是多少，網卡的吞吐率可以達到多少……

能把所有這些數據綜合起來，心里就大概有了把握，而且這種理性結算的結果，遠遠比“寫個程序去壓測”要靠譜得多。

所幸我在這次面試失敗之后幾年就領悟到這個問題，于是又花時間(那時候 996 還很少見)把數據結構、算法、網絡、系統結構等等基礎知識全部梳理了一遍。如今回想起來，當時的這輪梳理確實值得，自己后來受益匪淺。

[[268743]]

行業內有句話說：搞技術的不玩虛的，就服實打實的解決問題的本事。我認為這句話是成立的。

在我走上技術負責人的崗位后，也解決過不少技術上的疑難雜癥，尤其是我“本職”領域之外的問題。

比如困擾大家很久的接口概率性失敗的現象，最后診斷出是證書問題;又比如 HTTP 能通 SSH 不能通的問題，最后發現是 TCP 的 TIME_STAMP 配置問題;再比如面對不穩定的遺留系統，迅速拿出方案隔離不穩定部分，為技術改造贏得時間……

能解決這些麻煩的問題，自然能贏得各團隊伙伴的信任，不過我并非這些領域的專家，只是多虧了之前對基礎知識和技術細節的掌握，再加上學習和分析而已。

在很長的時間里，我一度非常相信“技術負責人就是要懂細節”，否則內心也很慌張。對細節的把握，讓我感到踏實、放心。

同時，我也熱衷于在面試中考察候選人對細節的了解，如果不了解細節，這個人就很浮躁。

換句話說，優秀的技術人員應當像把篦子，一路梳理過去，各種細節了如指掌，所有的問題原形畢露，這樣工作才稱職，自己才放心。

然而，隨著面臨問題的復雜，職位的升高，我發現自己日益焦慮，因為這是“不可能的任務”：

• 技術細節太多了，想要對每個細節都了如指掌只會讓人疲憊不堪。
• 技術人員也太多了，想要在每個人那里都保持權威也會讓人高度緊張。

到最后我發現，這已經不是一個用不用功、專不專心的問題，因為精力有限，要照顧的方面又太多，所以無論你多么用功，多么專心，都會感到力有不逮、左支右絀的局面。

看來，篦子這種模型有點問題——篦子當然好，但通常都不長，一手能夠拿住，如果要覆蓋很寬的面，就非常吃力。

那么，該怎么辦呢?如果自己找不到出路，我嘗試去觀察其他人是怎么做的。觀察一段時間之后，我還真有很大收獲。

最大的收獲是，我發現沒有人可以了解所有的細節。如果光看媒體，似乎很多“大佬”無所不知、無所不曉。

但仔細分析就發現，“大佬”往往只有在自己熟悉或者有充分準備的領域可以談得很深，遇到自己不熟悉的領域，他們要么不發聲，要么說錯了但會有公關團隊去掩蓋。

不可否認，一些企業里的高級管理人員或者創業者仍然保持了早期的工作作風，或者大概是為了保持“權威的存在感”，喜歡抓細節，喜歡就細節問題發表自己的看法。

在面試中，也有一些面試官喜歡過分追究細節，不斷拿特別細特別專門的問題來考驗候選人，營造自己的優勢。

但仔細觀察往往發現，這些人看起來無所不知，但如果是在他們不熟悉的領域，這樣做多半沒有好處。

“抓細節”往往導致本末倒置，“隨時就細節問題發表看法”往往容易適得其反，“用細節問題讓候選人難堪”可能錯過有潛力的候選人，這一切，都抬高了企業的運營成本。

我經常說，IT 行業可以從其他領域借鑒經驗，對技術細節的把握也是如此。以我對其他領域的了解，許多成功的技術領導者，其實并不關心細節，至少不會在細節上花太多的精力。

比如上世紀“太空競賽”中，美國載人航天工程推進部分的總工程師馮·布勞恩，他最關心的是火箭分幾級最合適，登月計劃到底采用哪個方案更好，是地球軌道交會還是月球軌道交會。

至于火箭制造的各種細節，其實他沒有精力去操心，也輪不到他操心(參考《系統問題應當如何排查?看看 NASA 著名的“10 厘米發射”吧》)。

再比如我軍的高級將領里，真正會打槍、槍打得好的沒有幾個，但這并不妨礙他們叱咤風云、攻城掠地。

更典型的例子如 1955 年授銜上將的張愛萍將軍，在后來主抓“兩彈一星”工程，指揮我國第一顆洲際導彈發射時，絲毫沒有技術背景的他卻贏得了大批專業技術人才的信任和懷念。

這其實是普遍現象。上世紀中情局的若干高科技工程中，主管 Parangosky 并不是理工科出身，但這不妨礙他受到大家的一致尊重，被公認為“奇跡創造者”(參考《K-129，CIA“偷天換日”的工程奇跡【二】》)。

所有這些例子充分說明，不管是否技術出身的技術領導者，都不必過分強調“技術”，不必強求事無巨細全部掌握。相反，強求“面面俱到”反而顯得荒謬。

我曾經寫文章介紹過我國著名的理論物理學家束星北教授(參考《看，這就是束星北先生》)。

在十年動亂中遭受迫害。有一次，他被要求爬上電線桿去接電線，這種任務實在為難一把年紀的束星北，結果管制他的人反而說起了風涼話：還什么搞物理的大學教授呢，連個電線都不會接……

看看正反兩方面的例子，我感到有點慚愧，因為我自己許多做法就是反面典型。

比如希望掌握所有細節，不但消耗了自己的精力，也沒有給其他人放手工作的信任感;再比如拿細節去要求候選人和其他同事，有時候甚至到了“刁難”的程度，其實并不利于客觀判斷他們的水平和貢獻。

所以在觀察、比較、思索了很久之后，我的結論是：技術領導者的精力是有限的，他們的能力模型既不應當是“博而不精”的寬泛，也不應當是“深而不廣”的專注，甚至業界流行的“T 型人才”也不準確。

對技術領導者來說，最合適的能力模型應當是釘耙型。

[[268744]]

說到“釘耙”，許多人第一個想到的大概是豬八戒的九齒釘耙，我們就拿九齒釘耙為例。

釘耙很寬，掃出去可以覆蓋一個面;同時釘耙又有許多齒，可以在某些具體的點上深入。

不過無論如何，太上老君只有那么多神鑌鐵可以用來打造九齒釘耙，在資源有限的情況下就得具體分析，考慮釘耙到底有多寬，有幾個齒，每個齒應該有多深。

技術領導者可以動用的全部精力，就是打造釘耙可以用到的全部原料。每一名技術領導者都要思考，這些精力該如何分配，是照顧更寬廣的面，還是照顧更深入的點?照顧哪些點?照顧到多深……

身為技術領導者，重要的不是你永遠在每個點上都扎到很深，而是應當具備“無論哪個點上出現問題，需要你的時候都能深入扎進去”的能力。

換句話說，重要的是能及時識別和發現問題，及時了解問題，及時給出靠譜的解決方案。

哪怕當時答不上來，但是能通過詢問、學習、分析能迅速定位和解決問題，就是合格的技術領導者。

而且與一次成型的釘耙不同，技術領導者必須時常“吊著一股勁”，那就是根據具體情況識別出最重要的問題，據此調整自己的精力分配和能力組成：

• 如果運維弱一點，就要在運維這個點上扎深一點。
• 如果前端弱一點，就得在前端這個點上扎深一點。
• 如果暫時各團隊狀況都還不錯，那就把覆蓋面鋪更廣一點，多為未來做規劃……

從這個角度，也就可以理解為什么許多人說領導的關鍵就在于“找到合適的人，放到合適的位置上”，只有這樣，領導者的釘耙才可以鋪得很寬，不必在具體的細節上耗費太多。

但是，如何找到合適的人，如何放到合適的位置，這恰恰是需要有足夠的細節知識才能作出可靠判斷的。

總之一句話，各公司的情況不同，同樣公司在不同階段的情況也不同，合格的技術領導者一定需要具備“柔性”素質，能融入百般場景，解決萬千問題。

這也解釋了為什么許多非技術出身的領導者，也可以做好技術團隊的管理。

原因大多是他們眼光精準、視野開闊、思維嚴密，并且對未來有充分的預見，時常能識別出當前最重要、最要緊的問題，投入資源去解決，確保一切處在有序、可控的狀態。

當然，還少不了對技術人員的尊重，對技術規律的敬畏。

在此之外，技術出身的技術領導者還有額外的優勢。他們對基礎知識的掌握，對細節的了解，讓他們即便面對陌生領域，也能夠迅速搭起“從已知到未知”的橋梁，迅速得到“內行人”的視角，迅速和大家找到共同語言。

非技術出身的領導者在這方面就要吃力許多，所以也只有少數極高明的人能做得好。

認同這一點，許多問題也豁然開朗了。身為技術領導者，最重要的是保持對技術的敬畏，以及不排斥談細節的意愿，所以虛浮的作風是萬萬要不得的。但同時，也不必苛求自己時刻了解所有細節。

在工作中，我們可以經常詢問自己：

• 當前我是不是在解決最要緊的問題?
• 這個問題的背景我是否充分認識了?
• 對于解決方案我是否有足夠的了解和把握?
• 我目前沒有具體關心的那些問題，是不是有靠譜的團隊在用靠譜的方式解決?

如果這些問題的回答都是肯定的，那么即便有一些技術細節不了解也是相當正常的，大可放心繼續工作。

如果有一個問題的回答不是肯定的，那么工作就還沒有做到位，這時候即便你掌握了各種技術細節，大概也不算稱職。

對自己是如此，對其他人也是如此。至少在我看來，在招聘技術負責人時，沒有必要過分糾結技術細節，而應當側重考察對方的技術素養，所以重要的不是對細節了解多少，而是工作習慣有多細致。

[[268745]]

具體來說，技術細節的問題，大概可以分為三類：

第一類，是候選人自稱做過，也著重投入過精力的領域。合格的候選人，對這些細節是應當完整掌握的，并且其掌握應當能互相支撐印證，構成完整的技術決策網，不能有“想當然”的環節。

如果這個領域的細節答不出來，或者經不住追問，那多半是很有問題的。

比如候選人說自己做過服務治理，那么能談的不應當只是和流行的 PPT 一樣，大而化之地列舉服務治理的好處，幾個主要組成部分。

還應當清楚服務注冊流程、服務生命周期定義、異常(尤其是安全)情況處理、擴縮容規范和限制等細節信息。

如果談不出來，“做過服務治理”的經歷就應當打個折扣。

第二類，是候選人沒有專門做過，但是不管解決哪個領域的問題都需要具備的基礎細節不可缺少。

比如“一個 Int 類型變量占幾個字節”的問題就是如此，系統要做復雜一點，在分析和設計的時候，這些知識是不能空缺的。

候選人還應當了解其它的基礎細節，比如光在真空中的傳輸速度是 30 萬公里/秒，而在光纖中的傳輸速度是 20 萬公里/秒。

這樣分析技術問題時才有根據，比如北京到上海的直線距離大概是 1200 公里，所以單程理論傳輸時間大約要 10ms，則 Ping 值在 25-30ms 左右是正常的，沒有更多優化空間優化。

但南京到上海的距離只有不到 300 公里，如果 Ping 值也在 30ms，則網絡上估計還有些問題。

這樣的細節知識，就是前端、后端、運維都可以用上的(此處數據經過老高(高春輝)確認)。

第三類，是候選人沒有專門做過，但也不那么基礎的細節。這類細節如果答不上來，其實并不是很要緊。

很難想象做社交的技術人員能懂得音視頻處理的細節，做金融的技術人員能懂得游戲開發的細節。只要職位上升到一定的高度，都不可能在技術細節上面面俱到。

就像上文說的，只要候選人有足夠的技術素質，在寬度上能覆蓋這些領域，能找到靠譜的人、評估出靠譜的方案，或者在深度上能保持(經過一段時間的學習了解)介入能力，這些問題多半都是可以解決的。

所以我的最終答案就是，“能力上不求全責備，意愿上不推三阻四”。

如果面試遇到細節問題，最真誠的答案大概是這樣：“我是技術總監，我可以把幾個重要領域的細節全部談清楚，但其他領域的細節我未必知道。不過我通常能判斷一個不那么熟悉領域的方案是否靠譜，如果再多給我一點時間，我相信自己能答上來”。