作為運維面試官的一些思考

01-31

掐指一算作為面試官，面試運維相關的技術人員也有兩年了。從一線運維，運維開發，運維經理，甚至運維總監各種層級的職位的人都見了過不少，也算是有了一些自己面試的套路。鑒於最近面的幾個面試者表現實在不理想，有的甚至是完全沒有準備，分享一下我面試的套路，希望能對後來的人有所幫助。當然更希望看到人能把這些套路在實際工作中運用起來，而不只是準備面試的時候用到。

1. 監控，報警，線上部署

這個可以說是基本面中的基本面了，在我的預期中問道你所在公司是如何做這些事情的時候應該是不假思索張口就來的。監控包括機器、中間件、web、具體業務的不同監控，對於每個監控的指標有沒有足夠深刻的理解。例如 Java 類的陳谷 JVM 監控有哪些指標，每個指標有什麼含義，哪些指標比較重要；Nginx 又需要監控哪些指標，資料庫又有哪些。報警也是和監控一脈相承的，哪些指標是最重要的，這些最重要的指標如何設置報警的閾值，一旦報警又該如何處理，這些基本面的東西如果被問到的時候還要再撓腦袋去想，恐怕這次面試的結果就不會太好了。監控報警可以說是一個運維的眼睛，如果你眼睛都不好使了，那做事情肯定會有很多問題。

線上部署也是同理，如何進行發布，發布後如何觀察問題，出現問題如何回滾，這種日常比較高頻的操作不需要你說的太花哨，但是如果說的磕磕絆絆的總會讓人產生一些懷疑。

2. shell 腳本，自動化

shell 同樣是基本面的範疇，如果是運維開發可能會有另外的要求。一般情況下都會考一個常用查看系統指標命令加輸出格式處理的上機實操題。如果這個基本盤拿不下，那希望也不大了，這塊可能會根據實際情況上難度，不斷的加處理條件，看一下思路和能力究竟如何。有的人這時候會拒接寫，或者說平時都是去網上查的沒辦法直接寫，這個就不是很好了。雖說從解決問題的角度上網查確實可以，但是出於基本面的考察簡單的 shell 都不能直接寫就有點說不過去了。

運維自動化並不完全算基本面的東西，因為在這裡能看到一些對現有運維體系的思考和如何改進的思考，算是比較加分的項目了，會看是如何自動化的，以及這個自動化方案中是不是有些沒注意到的細節瑕疵。還看過一些公司的運維開發是只做運維自動化工具的開發，並不做一線運維，這種情況還是略有一些顧慮，畢竟我們現在還是需要所有人上一線，在一線中提取需求自己改善的。

3. 故障處理

這個其實是我最關注的一個點，都說運維是背鍋的，但真能把鍋背起來可不是那麼容易的。運維的成長很大程度是依賴故障出現的，不誤刪幾次庫怎麼知道操作要謹慎，不出幾次沒頭緒的故障怎麼知道自己對系統哪裡認識的不深，不出幾次低級的磁碟滿內存滿的故障怎麼知道自己監控不到位。如果每次都能準確快速的解決故障，分析故障發生的原因，提出之後改善的方向，那這種運維是不會背鍋的，而且能給業務提出第一手的建議和幫助，這種對業務有幫助的運維是很受歡迎的。如果問每次故障原因是什麼，回答不知道；問怎麼處理的，回答找開發；怎麼預防，回答總是發生沒想好怎麼辦，那估計還是沒戲了。

我在面試的時候某些問題會一直問到很細節甚至有些偏門的地方，這時候可能並不太希望面試者能給出很精準的答案，更多的是看在壓力下的思路和表現。有一些面試技術人員的指南說要在放鬆環境下面試技術人員，這樣可以讓對方儘可能的發揮。不過面運維我一般是不太支持這個觀點的，畢竟運維很多情況下面臨的都是救火的情況，未知的領域，還需要儘快的做出準確的反應，面試時候加再大的壓力恐怕都不會有某次真實工作來的大。然而還是有很多面試者在被追問幾句之後立刻就聲音下去眼看著就慌了，那這種心理素質我覺得做運維還是要再鍛煉一下，什麼時候故障來了，苦難問題來了你很興奮的就撲上去了，那你可能就快成事了。

4. 對業務的熟悉和幫助

這個算是更高層面的一個要求了，看看是不是真正了解自己所支持的業務。有的運維被問所支持的具體業務時說的都是 tomcat，mysql 這些，說並不關心在之上具體是什麼。這樣做並不是不可以，但是其實會限制你之後的發展方向。從傳統的角度來看運維是個支撐部門，提供保障類的服務。但是運維的一些基本能力是可以輸出到業務層面的，比如流量的趨勢變化，業務穩定性的指標變化，從故障中查看出來的代碼層面的問題等等。甚至有的運維可以根據業務的變化提出系統結構應該如何調整，技術選型應該如何做這樣有影響力的技術方案。這樣的話可以把自己從一個支撐的角色，變成一個價值輸出的角色，會對整個公司更有影響力。這一切都離不開對上層業務的理解和思考，甚至從客戶那裡獲得反饋來思考如何改善，或者自己作為客戶來體驗產品提出意見，這也是能讓運維脫穎而出的一個路數，不過大前提是基本面依然要牢固的保持住不動搖。

說了這幾條，如果你覺得自己都還不錯的話歡迎加入我廠，現在上車還來得及，別的不能說太多了。如果你自己還有什麼面試運維的套路和被面到的套路，也歡迎分享一下。