做者:甘兵,知乎內容做者:連城前端
來源:http://blog.51cto.com/ganbing/2057482python
筆者其實沒有想到去面試,只是在智聯上更新了一下簡歷,就陸陸續續接到不少獵頭的郵件和電話,閒話少說,下面就分享給你們Linuxer的面試經歷:mysql
首先,獵頭或者公司人資會把公司的介紹及崗位要求發到你郵箱(或者QQ、微信),下面這份是獵頭髮給個人崗位說明,爲了職業道德操守,公司的介紹和麪試通知信息我就不貼出來了,我就把崗位要求貼出來:ios
職位描述:web
一、 負責應用服務器的安裝、配置、優化與維護;面試
二、 負責應用系統的日誌信息備份、管理、維護與分析;sql
三、 負責應用系統的平常監測於維護、故障處理、性能分析與優化;mongodb
四、 負責應用部署系統、環境配置系統、監控系統的開發、部署、升級與維護,建設高性能的運維平臺。shell
崗位要求:數據庫
一、 熟悉Linux操做系統的基礎知識,熟練使用Linux經常使用操做命令;
二、 熟練配置Nginx、HAproxy 等應用相關軟件的部署、配置與優化維護;
三、 熟悉網絡基礎知識、熟悉TCP/IP的工做原理,會配交換機或路由器,能熟練的對網絡狀況進行分析
四、 熟悉shell/perl/python中的一種或多種進行運維程序的開發;
五、 熟悉Nagios,Ganglia等監控軟件
看着上面的要求你們是否是以爲要求也不高啊,你要細看就會發現,這家公司要求的還挺多,不只要會網絡知識(熟悉TCP/IP好像是每家單位的都會寫這樣的要求),還要會開發技能。相信不少作運維的兄弟在網絡這一塊是個頭疼的事情,都對交換機和路由器不怎麼會配置和管理。
關鍵點來了,就是和麪試官溝通了,有筆試的公司會讓你作些面試題,沒有筆試就直接和麪試官聊了,下面是我和麪試官溝通完以後記住的一些問題,分享給你們看一下,筆者一共記住了7個問題,好像還有兩個問題實在想不起來了,若是你們有更恰當的回答必定要貼出來一塊兒探討和進步:
一、介紹下本身?
(幾乎每家公司首先都會讓你作個自我介紹,好像是必修課同樣)
回答:此處省略筆者的自我介紹,筆者建議介紹本身的時間不宜過長,3-4分鐘爲宜,說多了面試官會以爲你太囉嗦了。說太少了也不行,那樣會讓人感受你的經歷太簡單了、太空了。
正常狀況下,通常你在作自我介紹的同時,面試官這個時候在看你的簡歷,他須要一邊看簡歷、一邊聽你介紹本身,若是你說個幾句話就把本身介紹完了,他確定還沒緩過神來,對你的映像會減分的。在介紹的同時思惟要清晰,邏輯要清楚,最好是根據你簡歷上寫的經從來介紹,這樣能夠把面試官的思路帶到你這裏來,讓他思路跟着你走。不要東扯一句,西扯一句。
儘可能少介紹本身的性格、愛好(最好能不說就不說),你能夠簡單羅列幹過幾家公司(最多羅列3家公司/也包含目前所在的公司,注意順序不要亂),都在那幾家公司負責什麼工做,都用過什麼技術,在着重介紹一下你目前所在的公司是負責哪些工做的,能夠稍微詳細一點介紹,不要讓面試官聽着暈頭轉向的感受。
二、灰度發佈如何實現?
回答:這個問題過後在知乎上看到了一位網友的建議以爲不錯,你們能夠參考看一下 !
仔細考慮一下灰度發佈系統要達到哪些目的,基本就能有答案了。須要注意的是,客戶端應用(不管PC端仍是移動端)的灰度發佈要比Web應用的灰度發佈更爲複雜,由於應用運行在用戶持有的終端上,數據採集和回滾都更爲困難(但可採集的數據類型要更加豐富)。
注:本人缺少移動客戶端產品的經驗,下述內容可能不適用於移動客戶端產品。
我所理解的灰度發佈系統,主要任務是從產品用戶羣中按照必定策略選取部分用戶,讓他們先行體驗新版本的應用,經過收集這部分用戶對新版本應用的顯式反饋(論壇、微博)或隱式反饋(應用自身統計數據),對新版本應用的功能、性能、穩定性等指標進行評判,進而決定繼續放大新版本投放範圍直至全量升級或回滾至老版本。
從上述描述能夠得出灰度發佈系統須要具有的一些要素:
用戶標識
用於區分用戶,輔助數據統計,保證灰度發佈過程當中用戶體驗的連貫性(避免用戶在新舊版本中跳變,匿名Web應用比較容易有這個問題)。匿名Web應用可採用IP、Cookie等,需登陸的應用可直接採用應用的賬號體系。
目標用戶選取策略
即選取哪些用戶先行體驗新版本,是強制升級仍是讓用戶自主選擇等。可考慮的因素不少,包括但不限於地理位置、用戶終端特性(如分辨率、性能)、用戶自身特色(性別、年齡、忠誠度等)。對於細微修改(如文案、少許控件位置調整)可直接強制升級,對於相似新浪微博改版這樣的大型升級,應讓用戶自主選擇,最好可以提供讓用戶自主回滾至舊版本的渠道。
對於客戶端應用,能夠考慮相似Chrome的多channel升級策略,讓用戶自主選擇採用stable、beta、unstable channel的版本。在用戶有明確預期的狀況下自行承擔試用風險。
數據反饋
用戶數據反饋:在獲得用戶容許的前提下,收集用戶的使用新版本應用的狀況。如客戶端性能、客戶端穩定性、使用次數、使用頻率等。用於與舊版本進行對比,決策後續是繼續擴大新版本投放範圍仍是回滾。
服務端數據反饋:新版本服務端性能、服務端穩定性等,做用與用戶數據反饋相似。
新版本回滾策略
當新版本灰度發佈表現不佳時,應回滾至舊版本。對於純粹的Web應用而言,回滾相對簡單。主要難點在於用戶數據的無縫切換。對於客戶端應用,若是期待用戶自行卸載新版本另行安裝舊版本,成本和流失率都過高。能夠考慮經過快速另行發佈新版本,利用升級來「回滾」,覆蓋上次灰度發佈的修改。
對於移動客戶端,新版本發佈成本較高,須要Appstore、Market審覈。本人沒有移動客戶端產品的經驗,不太肯定移動客戶端產品如何處理灰度發佈及回滾。但儘可能將客戶端打形成Web App,會更有利於升級和回滾。(不過蘋果對純Web App類的App有較強的限制,好像已經不容許在Appstore上發佈這類應用了?)
新版本公關運營支持
對於改版級別的大型升級,須要配合公關運營支持,用於及時處理用戶在微博、博客等渠道給出的「顯式反饋」。對比經過隱式數據反饋獲得的結論後,綜合考慮應對策略。
三、Mongodb熟悉嗎,通常部署幾臺?
回答:部署過,沒有深刻研究過,通常mongodb部署主從、或者mongodb分片集羣;建議3臺或5臺服務器來部署。MongoDB分片的基本思想就是將集合切分紅小塊。這些塊分散到若干片裏面,每一個片只負責總數據的一部分。 對於客戶端來講,無需知道數據被拆分了,也無需知道服務端哪一個分片對應哪些數據。
數據在分片以前須要運行一個路由進程,進程名爲mongos。這個路由器知道全部數據的存放位置,知道數據和片的對應關係。對客戶端來講,它僅知道鏈接了一個普通的mongod,在請求數據的過程當中,經過路由器上的數據和片的對應關係,路由到目標數據所在的片上,若是請求有了迴應,路由器將其收集起來回送給客戶端。
四、如何發佈和回滾,用jenkins又是怎麼實現?
回答:發佈:jenkins配置好代碼路徑(SVN或GIT),而後拉代碼,打tag。須要編譯就編譯,編譯以後推送到發佈服務器(jenkins裏面能夠調腳本),而後從分發服務器往下分發到業務服務器上。
回滾:按照版本號到發佈服務器找到對應的版本推送
五、Tomcat工做模式?
回答:Tomcat是一個JSP/Servlet容器。其做爲Servlet容器,有三種工做模式:獨立的Servlet容器、進程內的Servlet容器和進程外的Servlet容器。
進入Tomcat的請求能夠根據Tomcat的工做模式分爲以下兩類:
Tomcat做爲應用程序服務器:請求來自於前端的web服務器,這多是Apache, IIS, Nginx等;
Tomcat做爲獨立服務器:請求來自於web瀏覽器;
六、監控用什麼實現的?
回答:如今公司的業務都跑在阿里雲上,咱們首選的監控就是用阿里雲監控,阿里雲監控自帶了ECS、RDS等服務的監控模板,可結合自定義報警規則來觸發監控項。上家公司的業務是託管在IDC,用的是zabbix監控方案,zabbix圖形界面豐富,也自帶不少監控模板,特別是多個分區、多個網卡等自動發現並進行監控作得很是不錯,不過須要在每臺客戶機(被監控端)安裝zabbix agent。
七、你是怎麼備份數據的,包括數據庫備份?
回答:在生產環境下,無論是應用數據、仍是數據庫數據首先在部署的時候就會有主從架構,這自己就是是屬於數據的熱備份;
其實考慮冷備份,用專門一臺服務器作爲備份服務器,好比能夠用rsync+inotify配合計劃任務來實現數據的冷備份,若是是發版的包備份,正常狀況下有臺發佈服務器,每次發版都會保存好發版的包。
總結一下面試注意幾點事項:
第一,你要對本身的簡歷很熟悉
簡歷上的寫的技能本身必定要能說出個一二,由於面試官的不少問題都會挑你簡歷上寫的問。好比你簡歷上寫了這麼一條技能「熟悉mysql數據庫的部署安裝及原理」。你即然寫了這麼一條技能,你在怎麼不熟悉你也要了解mysql的原理,能說出個大概意思。萬一面試官問到了你寫的這一條,你都答不上來,那在他內心你又減分了,基本上此次面試但願不大。
第二,不要不懂裝懂
若是面試官問到你不會的問題,你就說這個不太熟悉,沒有具體研究過,千萬別不懂裝懂,還扯一堆沒用的話題來掩飾,這樣只會讓面試官反感你。
第三,準備充分
竟可能多的記住原理性的知識,通常面試問的多的就是原理。不多問具體的配置文件是怎麼配置的。面試前也要了解清楚「職位描述」和「崗位要求」,雖然有時候大多數不會問到崗位要求的問題,但也要了解和熟悉。
第四,面試完後必定要總結
儘可能記住面試官問的每個問題,回去記錄下來,若是問到不會的問題,過後要立馬查百度或者找朋友搞清楚、弄明白,這樣你才能記勞,下次面試說不定又問到一樣的問題。