等級與能力

T4需要具備什麼樣的能力？

你熟練掌握運維基礎技能麼？

如（僅舉例）: SSH的原理是什麼？如何保證安全性？什麼是非對稱加密？什麼是中間人攻擊？SSH是如何避免中間人攻擊的？這個特性對傳輸正確性有哪些影響？known_hosts和中間人攻擊是什麼關係？為什麼裡面寫的金鑰和我寫到遠端的公鑰不一致？這個金鑰又是什麼？會有什麼影響？

你瞭解服務麼？

你的服務的瓶頸在哪？容量是多少？有多少指標是你關注的，哪個指標現在處於有風險的狀態，你的伺服器每個時刻都在做什麼？能夠通過曲線圖讀出目前系統所處的狀態或者正在執行的任務麼？常用的模組間的連線策略和負載均衡策略有哪些？每種的優勢和缺點是什麼？你的服務適合使用哪種策略？

你是一個合格的管理員麼？

線上的每一個細節都知道麼？有哪些種任務排程的方式？分別適合哪些場景？你的服務是什麼樣的？有沒有重複的程式碼，和不一致的指令碼？舉幾個例子？你的服務是“乾淨”的屋子，還是一個“骯髒”的雜物堆？你能給新人講清楚服務的細節麼？你帶的新人踩過坑麼？

如果上述三個問題的回答是yes。並且能夠在你做的運維工作中結合自己的知識能夠有效的解決問題。那麼你具備T4工程師的能力了。這是一個必要非充分條件！！

T5需要具備什麼樣的能力？

當到達T4的時候，已經積累的足夠的經驗，包括在運維技能上的，服務上的，成本和效率上的考慮。

在遇到一個比較複雜的問題上。要能夠有自己的思考和分析了。什麼樣的情況，該選擇什麼樣的方案解決問題。每個方案的特性是什麼？不要說你的方案好，這個方案的缺陷是什麼？會引發哪些新的問題？引發的這些新問題該如何的去解決？什麼時候開始解決？什麼時候我的方案已經不適宜了，該被推翻重來了？當你在提出一個方案的時候，能夠很好的回答這樣的問題。那麼你已經具備了權衡的能力。那麼說你已經有的經驗，你的思維判斷能力能夠支援你解決比較複雜的問題了。沒有完美的方案，如果能夠針對比較複雜的問題。採取有效的折中，突出方案的有點，弱化方案的缺點。要時刻記住一點。沒有完美的方案。但是有美的、簡單方案。如果用簡單的、美的、有效的方式解決了問題。能夠帶領工程師完成工作。這是T5應該有的能力。

以資料儲存方案為例。為什麼選擇左面的方案而沒有選擇右面的方案。有哪些條件？資料支撐是什麼？左邊的方案為什麼選擇mfs，而沒有選擇hdfs，資料支撐？論據支撐？為什麼選擇入口伺服器，而不是直接mount磁碟，存在的風險是什麼？資料是？為什麼選擇4臺入口機，而不是3臺，5臺？為什麼選擇lvs，而不是bvs？mfs的副本對下載速率有哪些影響？改選擇多少副本？有資料麼？整個方案穿透了都少層？哪層會先成為瓶頸？什麼時間，達到什麼條件，我們可以過渡到右邊的方案，前期需要做什麼？如果遇到風險我們該怎麼辦？能夠通過有效的方式監測和預知風險麼？

T6以上需要什麼樣的能力？

需要更多的技術積累。積累先進的技術，跨工種的技術。比如：系統底層的原理，如何提高程式設計的效率，快速實現自己的想法？什麼是design？如何做好的設計？我們的測試團隊都在做什麼？如何保證軟體質量？軟體質量只是QA的事情麼？我們日常使用的運維工具，哪些是合理的？哪些是不合理的？什麼樣的系統是美的？如何以最簡潔的方式解決一個問題？為什麼搜尋廣告是key word->ad ， 而網盟是url->key word->ad？研發工程師做的運維方面設計決策是否是合理的？我們的理由上和資料上的支撐是什麼？

listhost設計的初衷，設計的折中？有哪些特性和缺點？作者的考慮是什麼？如果沒有listhost呢？同樣的問題，服務樹呢？如果你只能告訴我5點，我認為深入思考的還不夠。資料傳輸有哪些種方式，什麼時候選擇推，什麼時候選擇拉，之間的區別又是什麼？gingko對kfp的改進是什麼？gingko和kfp對資料傳輸指令碼設計有哪些影響？

足夠的積累+解決問題+影響別人 = T6，T7......

更正一些錯誤的理解

關於好的產品：

一個成功的產品（系統，工具，尤其是底層的）一開始都是在滿足自己的需求。在把自己的問題很好的解決了之後，發現它確實是一個偉大的產品。linux，git，perl，ruby都是這樣。當然也不是說不要胸懷大志，只顧解決自己的問題。同樣，這也不是一個好的工程師。理想的情況應該是，先把自己的問題解決掉（用功能和程式碼抽象等等技術），在解決問題的同時兼顧別人對同樣的問題的看法和需求。一個工具和解決方案必有它的優勢和弱項。如果一開始就想去解決所有人的問題，那必將得到一個毫無特色的，處處充滿妥協的產品。最有多問問自己，你有沒有“真正”“好”的解決了自己的問題？

為指令碼正身：

說道這裡，我想說一下“指令碼”。“指令碼”指的是用python，perl，ruby，shell等語言寫出來的工具。在我們眼中貌似成了一個貶義詞。一個解決方案如果是指令碼的，就會被認為功能低下，無法複用，簡單臨時的拼湊。（不知道大家是否都存有這樣的偏見，但在我周圍的環境中是有的）。我想在這裡為“指令碼”正正身。一門語言，我們不能夠簡單說他好與不好。不能說c就是好的，指令碼就是不好的。關鍵在於如何使用，在什麼場景下使用，寫的是一個沒有引數處理，沒有文件，沒有異常處理，沒有單元測試的指令碼肯定不是一個好的指令碼。

破除浮華的“平臺”：

“平臺”虛無縹緲，只要是工程師工作的"介面"，都可以認為是“平臺”，比如linux是一個作業系統平臺，git是原始碼管理的平臺。我們對“平臺”的看法是偏執的，但我們指的“平臺”大多是web的平臺，要登陸，有花哨的人機互動介面。但是缺少程式設計互動介面。部分工程師還引以自豪學會了javascript。但是你的問題是否需要用web的解決方案來解決？能不能用工具就搞定了？如果，我是說如果，必須要開發web，有沒有考慮面向資源的web？開發RESTful的web？引入一些框架，提高開發效率。有多少專案大家在排期的時候都是按照半年排期的？原因就是一個web，一個所謂的“系統”。我曾經在主機管理工具中嘗試引入rails開發web，2個小時主體的功能就完成了。完成了頁面，資料庫設計，同時支援API，能夠直接通過curl新增、修改、刪除、查詢。如果必須開發web，那麼至少是這樣的web。

推薦一本小書--“你的燈亮著麼？”，中文版已經絕版，這兒有部分中文翻譯。主要是教你如何定義問題，看待問題，解決問題，思考問題的奇書。

簡短說明：這是一本關於“問題”的書。問題的產生，問題的解決方式，問題的演化等等。從這本書中我學到了：問題不能夠被解決，只能夠被轉化。在我每次遇到問題解決問題的時候這句話都受益匪淺。這是一本建議大家每年都要讀一遍的“小書”，每次讀完後都會有新知。