嘉賓 | 高樓編輯 | 李慧文很多人眼裏的性能 不過是開發的邊角料 盾山科技高樓專訪：如何成為一個身價百萬的性能工程師？ - 趣味新聞網

嘉賓 | 高樓

編輯 | 李慧文

很多人眼裏的性能，不過是開發的邊角料，看待性能工程師，天然就戴著一副有色眼鏡。其實，一個可以獨立做性能分析的人，在市場上搶都搶不到。可是，怎麼纔能成為這樣的性能工程師呢？InfoQ 深度采訪盾山科技 CEO、7DGroup 創始人，從底層為你揭秘性能高手的思維模式，以期幫助大量性能工程師們撥開職業的迷霧，登上身價百萬的台階。

1

我選擇測試是因為它需要完善的邏輯思維能力

InfoQ：您是為什麼會選擇性能這個方嚮的？

高樓： 在我 2005 年剛畢業那會，IT 還是個很好的就業方嚮，薪資高，而軟件測試尚處於萌芽階段，新潮且未知。那時很多人選擇測試是因為不用寫代碼就可以拿到高薪。而我選擇 測試是因為我覺得測試是需要完善的邏輯思維能力的。它包括的範圍不僅是代碼，從操作係統到上層應用、數據庫等等。

具體來說，我的第一份工作是路由器測試，不僅包括功能測試，也包括性能，可以寫代碼做，也需要用到硬件測試儀。這份工作中並不是把功能驗證一下、代碼能跑起來就行瞭，關鍵的是得懂各種協議。對協議的深入理解，纔是測試的前提。我覺得非常有意思，也學習到瞭不少知識。

我第二份工作是在一傢外企做無綫産品的測試，就是測試界麵上的元素，像顔色、布局、文本框之類的，對照定義好的規則就可以瞭。做瞭一段時間之後，我就放棄瞭，因為沒有技術的提升。

在分析對比瞭之後，我覺得 上層應用的性能測試對技術的要求範圍大的 ，從我在第一傢公司做路由器測試同時也兼做售後問題處理的經曆來看，上層的應用的問題是很復雜的，需要從上到下所有的知識細節，這樣定位問題纔能快速，所以我選擇瞭性能分析工作。

這個選擇確實如我所想， 從上層應用的視角來看的時候，會涉及到完整的技術棧，包括操作係統、網絡、中間件、數據庫、緩存、隊列等等。 我進入到瞭一個每天都會麵對新問題的狀態，新問題會不斷帶來新鮮感，讓我保持學習的狀態。

InfoQ：擇業後，很多人初次上手性能項目，往往會手忙腳亂，能不能請您用一個項目為例分享一下作為外部專傢解決係統性能問題的經驗呢？

高樓： 我說一個物聯網的項目，當時 TPS 在 100 左右，並且硬件資源也沒有用完。客戶方還需要我們給齣容量評估，即對應業務量的增長需求，應該準備多少硬件資源。

我一開始先讓他們把性能場景執行起來，監控分析各類數據。這種 TPS 低、響應時間長的現象可能會包含著很多性能問題，所以我們不得不細細地排查。經過一個星期左右的分析並優化，我們調整瞭中間件、數據庫等的參數，還做瞭錶結構、索引、業務代碼的修改，對一些具體的實現方案也做瞭架構調整。

最後在同樣的硬件環境中，我們把 TPS 優化到瞭 1000TPS，硬件資源也都用起來瞭，還做瞭擴展性測試，查看瞭增加節點之後産生的損耗，給齣瞭容量評估的結果。

做為一個第三方、甚至第四方到現場工作，對項目掌握的不可能比項目中的人更多，時間也是有限的。所以我的邏輯就是： 首先要快速掌握項目中的技術棧，列齣來架構圖，看有哪些環節是在自己的知識體係範圍裏的，哪些是自己不清楚的。對不清楚的部分，立即去查資料。

查資料的時候，對於技術組件的功能部分先不用看，性能相關都要看，比如說：綫程數、超時、隊列、內存等等。但是對不熟悉的軟件平台，也一樣是要 先看架構圖，再分析係統的實現邏輯以及性能相關的配置，迅速找到性能瓶頸點。 而做這一套操作是需要有知識背景的，從操作係統、數據庫到代碼功底，都是需要自己慢慢纍積的。

2

性能項目本該體現齣的價值是給齣一個係統明確的容量結論，給齣容量對應的硬件規模

InfoQ：現在性能相關需求普遍非常混亂，您認為造成這種現象的根因是什麼呢？性能真正的價值應該是什麼呢？

高樓：我覺得性能的需求不應該用混亂來形容，而應該用未開化來形容。現在的性能需求，大部分都還處在懵懂未開化的階段，主要錶現在 這些需求並不閤理，而且常常會齣現概念誤用。

比如說，我們在做項目時經常得到的一類性能需求是：係統要達到 10000TPS，響應時間要求在 1 秒以內。這樣的需求沒有背景約束說明，如在什麼樣的業務模型、業務數據量、係統環境之下要達到的，顯然是不閤理的。

還有就是概念上的錯誤引導。在我寫完第一個專欄的時候，有人問我：性能測試、壓力測試、峰值測試等等這些不算是閤理的性能策略嗎？這些都不能算是，因為我在性能項目中從來沒用過這樣的策略來指導落地的過程。拿最基礎的性能中的關鍵概念 TPS、並發用戶、在綫用戶、資源使用率等來說，在性能報告中，有很多人不清楚它們的真正作用而在張冠李戴。

這些現象，主要是由於 在性能方嚮上，市場的需求引導有偏差 導緻的：我們為瞭快速擴張或心理上的安全感，經常拿硬件來堆容量。

舉一個我親身經曆過的項目來說，一個買瞭幾百台高配置的硬件資源的企業，在經過性能優化之後，最後隻需要 60 台左右就滿足瞭容量需求，然而硬件已經買瞭，還帶來瞭其他成本問題。而這些本來隻需要一些很少的性能投入就能解決，但事實上性能的投入卻少得可憐。我記得在一個項目中，有兩三百個開發，二三十個項目並行，隻有一個半的性能測試人員，這顯然是對性能應該做什麼如何做都沒有概念。

而有些對成本控製得特彆嚴苛的企業，由於經費的不足，不得不在少得可憐的測試環境中來推導生産上的容量，不得不麵對各種局限導緻的問題。

這一弛一張之間，導緻的結果就是性能的價值根本得不到體現。隻有一種情況下，性能會被非常明確地提到桌麵上來，那就是當生産齣現性能問題的時候。前陣子，我處理過一個項目，涉及到硬件廠商、軟件廠商、數據庫廠商三傢企業，係統總是齣現問題，而這三傢廠商相互推諉瞭兩個月居然是因為一個工程師拿瞭個同步讀寫 IO 的命令測試瞭一下，就說硬件資源支撐不瞭應用係統的 IO 需求。這裏麵有立場的問題，也有技術能力的問題。

産生這種現象的原因是 性能項目本該體現齣的價值沒有體現齣來，即給齣一個係統明確的容量結論，給齣容量對應的硬件規模。 這就導緻瞭大企業更相信堆硬件，而小企業的性能隻能查查軟件層麵的問題。

要想解決性能相關的亂象，在我看來隻有一個齣路，那就是做性能分析的人要有係統的、嚴格的性能工程思維，從需求到場景到分析到運維的過程中都可以覆蓋完整的性能工程思維。

3

一個可以獨立做性能分析的人，在市場上搶都搶不到

InfoQ：您認為性能工程師相比其他工程師最大的區彆在哪？需要怎樣的能力？為什麼選擇從事性能分析的人比較少呢？一些畢業生、求職者的心中，存在職業鄙視鏈，您怎麼看待這個現象呢？

高樓：閤格的性能工程師，必須學會的是性能瓶頸分析定位。既然要定位問題，在一個係統運行的過程中，涉及到的所有技術細節都是要掌握的技能。這是性能工程師和其他最大的區彆， 知識麵要足夠廣的同時也需要足夠深。

我們不是寫代碼的，但我們要能迅速找到代碼慢在哪裏。我們不是數據庫工程師，但我們要能迅速找到一個具體的 SQL 或配置的不閤理。這樣的能力要求，應該說不是基於對個人能力的要求，而是對一個團隊的要求。不過當你一個人能乾過一個團隊的時候，想想就知道你的位置也會高起來。

而現在，市場上做性能分析的人比較少的最大的原因就是，很少性能工程師花大量的時候去彌補知識的廣度和深度。同時，還有一個重要的原因就是性能分析是要靠項目來曆練的，就是見多瞭自然就懂得多。隻做腳本和簡單監控的性能工程師可以定義為走流程的工程師，不涉及到性能分析的部分。

關於開發和性能行業，其實，當把職位調侃成鄙視鏈的時候，這已經是一種誤導瞭。當我帶團隊的時候，我想的是這個事情要有人來做，至於這個事情要的技術功底是什麼樣子，需要多少成本，其實是和市場有關，而人的成本取決於供需關係。

技術人員是真實地存在鄙視鏈的，當一個問題，我能搞得定，而你搞不定的時候，我就可以鄙視你。

現在市場上認為開發比性能“牛逼”的感覺應該來源於薪資，而薪資是市場供需關係決定的。如果你隻是做一個性能腳本開發工程師，給個 CPU 使用率之類的報告，確實不值什麼錢。 而性能工程師的價值在於把性能項目做好，保證綫上的穩定運行。如果一個性能工程師可以拍著胸脯說：這係統上綫因為性能齣現故障，我負責！這樣可以獨立做性能分析的人，在市場上搶都搶不到。

在我之前的項目中，帶過一個架構師。作為性能齣身的我帶一個團隊，還帶工作十年以上架構師的角色，自然會有人覺得我是帶不動的。在技術的正麵衝突中，當問題齣現時，我們同時去分析判斷，他會給齣建議，我也會給齣建議，在不斷地推演判斷分析的過程中，他們發現我這個做性能齣身的似乎也不是軟柿子可以鄙視的，之後就溝通順暢瞭很多，個中關鍵不是誰能勝瞭誰，而在於能不能正麵地對話。

在我看來，這其實隻是技術人員（也可以說是知識分子）的清高而已，隻是一種人際交往的狀態。這種清高也很容易打破，不用技術的話，其實擼個串、喝個酒也可以打破。

4

精心沉澱 + 動手實踐是成為以一敵萬的性能工程師的唯一捷徑

InfoQ：很多初入性能行業的人，還處於職業上的迷茫期，您對他們有什麼建議嗎？性能工程師該如何自我成長呢？

高樓： 我先談性能工程師的成長路徑吧。如果想成長為一個好的性能工程師，路徑是比較明確的：

・ 首先，要學 IT 基礎知識，架構、操作係統、數據庫、緩存、隊列、網絡、語言等的基礎知識，當然基本的操作也是要會的；

・ 其次，要學工具。性能工具、監控工具、分析工具等等，有瞭工具纔是有瞭操作的對象；

・ 最後，要學原理，一定要理解原理纔能真正學會性能。

這裏我要強調一下， 一定要理解原理纔能真正學會性能。 舉個例子來說，前幾天跟我項目的一個小夥子說會用某個性能工具做腳本，也相當熟練，於是我就問瞭幾個和工具相關的問題，結果近十個問題他幾乎一個沒答上來。因為他並不清楚原理。 不懂原理，遇到問題隻知道現象，而不知道如何分析解決。

接著我來探討迷茫和成長。這兩個問題是一體兩麵的。不成長你就會迷茫，去忙著成長瞭，就沒時間迷茫瞭。在當前的市場上，很多人的知識點都是片麵的，市場人員的流動性大，導緻求職者不得不總是學一些新的技能，而學會瞭又可能要麵對下一個新的技能，而想積纍個人技術素養需要很長的時間。所以我特彆想強調 靜心沉澱 的作用。

其中，看書是成本最低的一種沉澱方式瞭。前陣子因為項目的需要，我需要把微服務分布式架構的很多內容係統地整理一遍，於是我就一次性買瞭三十幾本和微服務分布式架構相關的書，一本本翻，覺得好的就仔細看完。 當然，無所謂獲取知識的途徑，耐心最重要。

我還有一個習慣，就是會把自己會的東西都記錄下來，當我一字一字輸齣的時候，就覺得這些會的東西已經告訴彆人瞭，自己也就不會守著已知的東西，而去學習一些未知的內容瞭。

此外，多動手實踐也是重要的成長方式。這句話看起來是句廢話，但是可以統計一下技術人員在接觸到一個新技術時，自己花瞭多少時間動手實踐呢？

最後我想說，如果連學習這件事情都進行不下去，那就不止是職業上的迷茫瞭，人生也會迷茫。

嘉賓介紹

高樓

性能專傢，架構級性能解決方案資源專傢，盾山科技 CEO，7DGroup 創始人，性能標準撰寫人，網名 Zee。擁有 16 年性能測試分析調優經驗，緻力於架構級性能測試、容量水位規劃、性能瓶頸分析、性能異常等技術方嚮，注重性能測試之後的調優過程和如何將性能測試與分析的結果在生産環境中體現。他帶領過 300 人以上的國內外混閤團隊，完整做過 40+ 項目，做為齣品人和講師參加過多次技術大會。目前，工作重心在微服務分布式架構級性能規劃、全鏈路壓測等具體落地實施方麵，主要做企業谘詢、培訓、實施等工作內容。

活動推薦：

在今年的 4 月 24 日和 25 日，ArchSummit 全球架構師峰會即將落地上海，此次會議，我們一共設置瞭十五個專題，其中包含大數據與人工智能、中間件開發實戰、移動端開發實踐、微服務架構設計等等，詳細專題內容可通過下方 Banner 掃碼瞭解，期待和你一起現場交流。

點個在看少個 bug