面試遊戲公司運維工程師的經驗分享----未完待續

很久沒更新博文了，不管心態仍是生活，都變得有些懶散，呵呵，，發下牢騷，如下正文:

生活總要有點激情，前幾天在獵聘網站刷新了下簡歷，有幾個獵頭聯繫了豪鷲，我挑了其中一家遊戲公司過去面試，面試過程1個半小時左右，已經變成運維老鹹菜的豪鷲分享下這次的面試經歷吧，歡迎網友留言探討。。

面試準備：

面試通過：
約了14:30面試，提早5分鐘到達戰場，因會議室都有人在用，因此在前臺沙發等了近25分鐘。。

一輪面：運維總監面試
一、自我介紹
這個問題99.99%都會遇到，因此在面試以前，有必要本身先根據本身簡歷內容梳理一下，這個問題對面試官佔有比較高的印象分，豪鷲是按照這樣來回答：
a、目前就任哪一個行業哪家公司什麼職位，具體的工做內容；
b、在現就任的公司以前，在哪一個行業哪家公司什麼職位，具體的工做內容；
c、而後對於xx行業，好比遊戲行業的運維，也能夠說一些本身的理解和見解；
固然，這些都是豪鷲本身的思路，僅供參考。

好比豪鷲的回答是：
目前我就任於xxx技術有限公司任職Linux系統工程師，是一家資訊行業的人工智能公司，那我負責的具體工做主要是：

（1）、負責服務器的維護、監控、系統環境部署，日誌收集分析，故障排除等；
（2）、與開發共同設計並實施服務器的高可用架構，制定並實施相關運維技術和場景應急方案，確保服務高效、穩定可用；
（3）、代碼更新上線，服務器擴容方案、故障分析與處理，Nginx負載均衡，數據庫高可用方案設計及架構升級，saltstack運維自動化工具等；
在這以前也待過一家創業型的電商公司，也是服務器系統運維方面的工做。
在這兩家公司，作過幾個大的架構優化，好比：MySQL的高可用架構MHA，Redis哨兵模式，MongoDB副本集，ES集羣，Nginx負載均衡等。
代碼上線更新的話，不一樣公司用不一樣的解決方案，電商公司用的是shell+rsync，預發佈環境代碼從svn拉取，線上代碼從預發佈環境直接同步過去。
當前就任的這家公司，用的是gitlab+jenkins+shell/python頁面+saltstack的批量部署。
對於項目運維經驗，app，網站，後臺都有一些運維經驗，對於遊戲行業的運維，我沒有這方面的運維經驗，但很多同窗都是在遊戲行業裏面作運維的，因此有時候或多或少也會作一些運維方面的交流，
那遊戲行業早期的架構也就是LNMP或LAMP，開服，合服，停服等操做都使用shell腳本維護，發展到最近3年左右，慢慢地有了自動化運維管理平臺的概念，shell也慢慢過渡到以python爲主的技術，對於像貴公司這種作遊戲研發和平臺維護的，可能大多數都是用python來作運維平臺，經過運維來維護和更新上線等。

注意：我以爲最重要的是沒關係張，說重點，以及即使是沒有作過遊戲運維，但起碼要讓面試官知道你是有準備這方面的東西。工做內容我以爲只說最近兩家公司的工做內容就好了，以上介紹下來，大概花3~4分鐘左右，不長不短。

二、說一下MHA實現的原理和過程，而且MHA高可用架構有什麼缺點？
MHA是一套優秀的做爲MySQL高可用性環境下故障切換和主從提高的高可用軟件，目前來講是一個相對來講的高可用技術方案。
在MySQL故障切換過程當中，MHA能作到在30秒以內自動完成數據庫的故障切換操做，而且在進行故障切換的過程當中，MHA能在最大程度上保證數據的一致性，以達到真正意義上的高可用。
MHA主要由兩部分組成：管理節點和數據節點。管理節點能夠單獨部署在一臺獨立的機器上管理多個master-slave集羣，也能夠部署在一臺slave節點上。數據節點運行在每臺MySQL服務器上，管理節點會定時探測集羣中的master節點，當master出現故障時，它能夠自動將最新數據的slave提高爲新的master，而後將全部其餘的slave從新指向新的master。整個故障轉移過程對應用程序徹底透明。那好比咱們如今生產環境用的MHA，就是用一主三從，其中一個從節點不參與主節點的選舉，只作備份使用，而管理節點部署在其中一個從節點上。（最好結合本身生產環境來講明，讓面試官以爲你是有過生產環境部署及維護的經驗）

至於MHA實現原理，可參考如下：
（1）從宕機崩潰的master保存二進制日誌事件（binlog events）;
（2）識別含有最新更新的slave；
（3）應用差別的中繼日誌（relay log）到其餘的slave；
（4）應用從master保存的二進制日誌事件（binlog events）；
（5）提高一個slave爲新的master；
（6）使其餘的slave鏈接新的master進行復制；

MHA缺點：（豪鷲說了4個，也不知對錯，歡迎補充）
（1）須要全部機器基於SSH免認證配置，存在必定的安全隱患。
（2）管理節點的監控進程，一旦發生一次主從切換，那麼監控進程就會掛掉，須要從新啓動，不過這個能夠經過結合腳原本檢查自啓。
（3）切換過程仍是會須要一小段秒級的切換時間，並不能真正嚴格意義上實現無縫切換。
（4）管理節點只對主庫進行監控，不過這個也能夠經過腳本對其餘從節點的狀態進行監控。

三、用戶投訴說網站訪問不了或訪問慢，怎麼排查問題？
這題目在生產也是常常遇到過，因此相對來講，仍是不難回答，最好是回答排查思路以及解決方案，如下僅供參考，這道題目回答得仍是比較細的
首先先肯定是訪問全部網站都慢仍是隻是單單你負責的網站慢。固然這句話很明顯就是廢話，既然問到這了，確定指的是你維護的網站了。。呵呵。。
出現訪問網站慢的緣由：
（1）若是是某個地區訪問慢，若是有cdn的話，多是那個地區的cdn節點出現問題。
（2）網站服務器出口帶寬佔滿了
（3）服務器負載大
（4）網站代碼質量問題、能夠經過瀏覽器訪問按F12查看哪些元素加載慢，或者代碼中SQL語句未優化的問題
（5）數據庫服務器瓶頸

優化辦法：
（1）CDN的問題，聯繫廠商
（2）流量帶寬問題：花錢買帶寬
（3）服務器負載問題：經過top等命令去查看佔用資源較大的進程，具體進程具體分析
（4）代碼問題：這個就須要跟開發協商處理
（5）數據庫瓶頸：建立索引，分庫分表，讀寫分離
（6）總體架構優化：水平擴容，添加負載服務器，使用緩存服務器（如redis等），集羣高可用等

四、要統計訪問網站訪問量的前10個IP地址，具體怎麼實現？
這個能夠用shell或者python結合web服務器日誌去統計，這個網上答案一大把，對於運維老鹹菜的大夥們也應該不是問題。（用awk結合sort和uniq去實現）

五、在這麼多年的運維工做中，給你印象最深的是遇到哪一個難題，怎麼解決的，你在解決問題中起到什麼角色？
六、說下你以前待過兩家公司的架構？
七、代碼更新上線的流程是怎樣的？
八、若是想將業務從阿里雲遷移至騰訊雲，你的方案是怎樣的？
九、你對本身的職業規劃是怎樣的？
十、打算跳槽的緣由？
十、有什麼問題要問的嗎？
A.公司的運維團隊是怎樣分工的？
B.若是我來公司了，個人工做內容？
……

二輪面：HR面試一、自我介紹二、離職的緣由？三、打算跳槽的緣由？四、已經提離職了仍是觀望，最快能夠何時到崗？五、目前薪酬跟薪酬的要求？……雜七雜八扯扯蛋