好久沒寫文章了，最近要來刷下存在感，近兩年，運維自動化被炒的火的不行，行業趨勢不可擋，現在企業招運維工程師都要求會一門開發語言。我們公司也不例外，由於剛上市，一下子有錢了，開始招兵買馬瞎折騰，因此最近我也面試了不下十來個求職者，本成想可以很容易招到幾個不錯的小夥，結果卻令我很失望，今天貼幾個面試者例子上來，跟大家吐槽下：

面試 A 君：

應聘職位：高階系統工程師 ， 工資要 18K

此君簡歷寫的不錯，在 360 幹過幾年，簡歷上寫的是維護公司的 360 網盤平臺，管理著 2000 多臺機器，寫了很多自動化工具。 然後我就讓他跟我聊聊他做的自動化工具，哥們娓娓到來跟我講他寫的那些指令碼（自動部署、批量命令、日誌分析），從他的表情中感覺他好像覺得他做過的這些東西很牛 B （其實都是一堆 SHELL+PYTHON拼湊起來的粗糙工具，需求稍一改變就不能滿足，指令碼的擴充套件性極差），他說他現在的工作基本上 80% 都能通過指令碼完成，說完後直視我，貌似是等待著我的認可，出於尊重，我只好說那確實不錯。接下來我就拿他寫過的批量併發執行命令的指令碼跟他深入聊了下，他說這個指令碼是 Python 多執行緒併發的， 1000 臺機器執行一次批量命令 1分鐘就能全部完成，我於是讓他給我講講多執行緒與多程序的區別，在什麼時候用執行緒或程序更合適，結果哥們說了很多廢話也沒有講明白。然後我又讓他用 PYTHON 多執行緒給我寫個簡單的生產者消費者模型，哥們愣是不知道這是啥東西？ 那我又問，如果你不知道生產者消費者模型是什麼，那你的併發非同步處理是怎麼做的？哥們語塞說沒在這方面做過深入研究，我於是又問了幾個其它方面的問題，比如他的 Ngnix 日誌是如何分析的？ 自動部署如何跟 git 結合的？監控報警介面是如何優化才降低誤報率的？但回答的都不理想，然後，就沒有然後了 …. 。 在這裡我只能說，我不是想打擊他，如果你只是寫了幾個指令碼就聲稱自己就是自動化大拿了，未免有點牽強。所以他被PASS 掉了，因為我覺得把他招過來，真的不會給我們公司的自動化水平提高多少 !

面試 B 君：

應聘職位：運維自動化開發工程師， 工資不能低於 16K

此君簡歷上說他擅長 PHP\Python 開發，在原公司做過運維自動化平臺。我很感興趣，讓他講一下他做的東西，主要是監控平臺和 CMDB 資產資料庫，讓他著重講了一下他的監控架構，他說他的專案主要是主動監控方式，就是監控伺服器每隔一兩分鐘去輪巡一次所有的機器的 SNMP 介面，把各機器的基本系統效能資訊抓回來，再通過RRDTOOL 出圖。他們有 500 多臺機器散落在 3 個不同地區的機房，我問他你們這種做主動監控輪巡一次得多少時間？他說 1 分鐘左右，我說如果輪巡過程中，如果有幾臺機器連不上怎麼辦？他說他的輪巡是併發的，連不上的不會影響其它機器的監控，我說但是你的執行緒池的執行緒個數是有限的，有幾個執行緒因為機器連不上，那就會產生阻塞直至超時，但在超時之前這幾個執行緒是不會再空閒出來的，因此肯定會導致整個輪巡時間的加長呀。哥們想了想說，確實存在這樣的問題。然後我問他有沒有考慮過用被動監控方式 ，就是讓客戶端自動彙報資料呢？他說當時他們也這樣想過，但是一想到要在所有的機器上裝個客戶就覺得會增加複雜度，並且維護和管理不容易。我說採用被動模式確實會增加點複雜度，但會給你帶來很多好處呀，監控客戶端自動給你的伺服器彙報資料會大大減少你主監控伺服器的負載，並且可監控的東西要多的多呀，你還可以自定義外掛，自動升級，並且還可以把監控客戶端當做它用，比如自動化部署、任務下發等。可能是出於尊重，哥們假裝同意了我的看法。

然後我又問他們的專案是幾個人開發的，他說算他在內有 3 個人一塊做，我說那你們之前是如何協作的，比如介面互相是如何呼叫和約定的？ 他說基本上是每個人寫自己的介面，互相之間約定好如何呼叫。我問那你們有沒有遵循什麼標準？ 比如是統一用 http api 還是其它的？介面格式是統一用 Json 還是用 XML 或其它？哥們說他們有的用 JSON 、有的用 XML 。 我說你們沒有用 restful 標準嗎？哥們表示沒聽過。。。。。 OH ，好吧！如果大家開發時都不遵循一定的標準和規範，我真心不知道他們的系統以後如何擴充套件，不知道這個哥們離職後誰還能看懂他的程式碼？不知道這種拿一堆隨心所意寫出來的指令碼來拼湊起來的所謂的系統能滿足多少實際需求？

面試 C 君：

應聘職位：運維工程師 工資要求 11K

哥們剛工作不到 2 年就要 11K ，真比我當時工作了 2 年掙 的多多了 ( 即使去掉通貨膨脹影響 ) ，但如果技術好那也沒有問題的。 結果問了一堆基礎問題都答不好，再要這些錢是否有點自不量力了？ 問他 LVS ，結果只是配置過，讓他講幾種負載排程原理也講不明白，問他平時怎麼管理大量機器，他說用 SaltStack 或自己批量寫指令碼，我問那你用指令碼批量管理機器，是通過什麼方式呢？他說是用 SSH 批量金鑰登入，我說那你給我講講 RSA 金鑰認證原理吧，他接下說的就是怎麼通過 ssh-keygen 命令，怎麼把公鑰拷到客戶端機器上等怎麼實現金鑰認證的過程。我打斷他說我想聽的是原理，不是認證方法，結果哥們一點都說不出來，接下來問的一些其它問題也是這樣，只知其然，不知其所以然，最後我說，你這種情況我們給不了 11K ，如果低點你願意考慮嗎？哥們說不太會考慮， 那。。。。好吧，只能打發他走了。

其它的一些面試者情況也好不到哪裡去，一路十多個面下來，讓我很失望，本以為過了這麼多年以後，整個行業的從業素質會提高很多。但結果卻還是老樣子，所以大家可以想想業內大家都在炒的運維自動化到底實際有多水？如果從業人員技術水平都這樣，還談個妹自動化呢？ 自動化真的是寫寫指令碼，再拿個開源軟體拼拼湊湊下就完了嗎？在我看來這撐死了只能叫輔助運維，不叫自動化，自動化應該是真正的開始讓機器幫你監測問題＼發現問題＼處理問題＼解決問題＼自我修復＼自我維護＼自帶乾糧，各模組之間儘量低耦合＼可擴充套件＼可插拔。應該是真正能幫企業降低 IT 運營成本，使運營成本視覺化＼可測量＼可對比，應該是真正能減輕運維人員的工作量而不是又製造一堆新的問題，應該是切合企業真正的實際需求做出來一些好用的工具和平臺，而不是搞一些花裡胡哨卻最後扔在那裡沒人用的花架子（我自己在這方面就掉進過大坑，之前主導做的一個開源軟體就是個失敗案例）。

總之最後給我的感覺是，會開發的不真正的懂業務邏輯，開發出來的東西沒人用，會運維的開發水平又太爛，寫出來的程式碼爛到哭。想找個真正合格的運維自動化人才真是不容易。

我近期一共只面了 10 多個，確實不能代表全行業水平，有些真正技術牛人估計我也沒有碰到，但是 10 多個樣本里面一個合適的都找不到，我覺得這也能差不多從側面說明一個行業的整體平均水平了， 這些求職者水平不高，卻又想要高工資，我能說這是眼高手低、好高騖遠的表現麼？打鐵還需自身用，如果真想要高工資，請先踏實點把自身技術水平提高，如果真想做架構師，那請把架構技術和思想學好，如果真要做自動化運維，請先把至少一門開發語言學好、學透，不只是會寫個指令碼就完了，指令碼只是指令碼，那不是自動化， So ，哥們別再逗了！

希望此文能給業內小夥伴選擇職業路徑時提供幫助！