總結一下：運維工程師面試的經歷及面試相關問題

總結一下麵試註意幾點事項，可能筆者也說得不太對，為了我們運維工作的兄弟們都能拿到高薪，大家一定要指證出來一起進步、一起探討：

第一，你要對自己的簡歷很熟悉，簡歷上的寫的技能自己一定要能說出個一二，因為面試官的很多問題都會挑你簡歷上寫的問。比如你簡歷上寫了這麼一條技能“熟悉mysql資料庫的部署安裝及原理”。你即然寫了這麼一條技能，你在怎麼不熟悉你也要瞭解mysql的原理，能說出個大概意思。萬一面試官問到了你寫的這一條，你都答不上來，那在他心裡你又減分了，基本上這次面試希望不大。

第二，如果面試官問到你不會的問題，你就說這個不太熟悉，沒有具體研究過，千萬別不懂裝懂，還扯一堆沒用的話題來掩飾，這樣只會讓面試官反感你。

第三，準備充分，竟可能多的記住原理性的知識，一般面試問的多的就是原理。很少問具體的配置檔案是怎麼配置的。面試前也要瞭解清楚“職位描述”和“崗位要求”，雖然有時候大多數不會問到崗位要求的問題，但也要瞭解和熟悉。

第四，面試完後一定要總結，儘量記住面試官問的每一個問題，回去記錄下來，如果問到不會的問題，事後要立馬查百度或者找朋友搞清楚、弄明白，這樣你才能記勞，下次面試說不定又問到同樣的問題。

問完之後，面試官就跟我聊薪資待遇了，問我多少錢能達到自己的要求，我就不便透露了，可以私聊，哈哈，後續筆者會陸陸續續更新以前面試的經歷和問題，有需要的朋友可以轉載或者收藏起來一起討論。

基於大家熱情高昂的氣氛，筆者又花了一個下午的時間回憶並整理在2017年2月24號筆者在東三環邊上（快到東四環了，沒有地鐵過去，到了四惠還要轉公交車）的一家傳媒公司的面試經歷，還好筆者有做筆記的習慣，把之前面試的問題都記錄在案，這一次的面試筆者可是記憶猶新，因為這次這家公司都跟筆者發offer了，實在是真心不想去這家公司就找原因推掉了，大家可別學我這麼不靠譜。下麵是這家公司中的崗位要求說明：

崗位職責：
1、負責公司產品的版本控制、構建和釋出管理；
2、負責公司統一配置庫管理工作，許可權管理與分配準確及時，定期完成配置備份；
3、負責公司內部開發/測試伺服器的執行管理工作；
4、負責Linux作業系統的安裝、配置、監控和維護、問題處理、軟體升級、 資料備份、應急響應、故障排除等、保證線上環境的穩定執行；
5、負責支撐平臺24×7穩定執行，併進行前瞻性容量規劃；
6、負責公司機房伺服器日常維護及網路系統安裝、部署、維護工作。

崗位要求：
1、計算機相關專業本科及以上學歷，2年以上運維或配置管理工作經驗；
2、至少熟悉一種監控系統搭建，如Nagios/Zabbix/等；
3、至少熟悉一種叢集管理工具，如Ansible/SaltStack等；
4、有使用整合釋出工具釋出構建經驗優先。比如：bamboo或者Jenkins；
5、熟悉Unix/Linux作業系統，熟悉Weblogic/tomcat等中介軟體，能夠編寫shell指令碼，熟悉軟體開發過程及過程產品，有一定的網路基礎；
6、熟悉rsyslog, flume等日誌收集和處理系統；
7、具有強烈的安全意識及較強的溝通協調和學習能力，良好的團隊合作精神，工作積極主動。

過去之後，前臺美眉把我帶到他們公司的地下室，我掃視了一下週圍的環境，貌似旁邊就是機房，因為我聽到伺服器的聲音。等了幾分鐘，面試官下來了，面試官目測比較瘦，看著跟我身材差不多（應該不到120），他說他是負責運維部的，然後開始就叫我先自我介紹，都是一個套路，免不了介紹的，所以兄弟們一定要把自我介紹練好。然後開始問我問題了，跟面試官聊得還行，問我應該有不下10個以上的問題，我記住了下麵有10個問題：

1、LVS負載的原理，和Nginx負載有啥區別？

筆者回答：這個問題我覺得面試官司沒問好，正常都會這麼問“LVS有哪些負載均衡技術和排程演演算法?”。我回答就是按我說的這種問法回答的，反正他也頻繁點頭，當然，筆者回答的可能沒有下麵我整理出來的那麼詳細，大概意思我都說明白了。

LVS是Liunx虛擬伺服器的簡稱，利用LVS提供的負載均衡技術和linux作業系統可實現高效能、高可用的伺服器叢集，一般LVS都是位於整個集群系統的最前端，由一臺或者多臺負載排程器（Director Server）組成，分發給應用伺服器（Real Server）。它是工作在4層（也就是TCP/IP中的傳輸層），LVS是基於IP負載均衡技術的IPVS模組來實現的，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR，詳述如下：

 VS/NAT： 即（Virtual Server via Network Address Translation）

也就是網路地址翻譯技術實現虛擬伺服器，當使用者請求到達排程器時，排程器將請求報文的標的地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的標的埠也改成選定的Real Server的相應埠，最後將報文請求傳送到選定的Real Server。在伺服器端得到資料後，Real Server傳回資料給使用者時，需要再次經過負載排程器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把資料傳送給使用者，完成整個負載排程過程。

可以看出，在NAT方式下，使用者請求和響應報文都必須經過Director Server地址重寫，當使用者請求越來越多時，排程器的處理能力將稱為瓶頸。

 VS/TUN ：即（Virtual Server via IP Tunneling）

也就是IP隧道技術實現虛擬伺服器。它的連線排程和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，排程器採用IP隧道技術將使用者請求轉發到某個Real Server，而這個Real Server將直接響應使用者的請求，不再經過前端排程器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，排程器將只處理使用者的報文請求，集群系統的吞吐量大大提高。

 VS/DR： 即（Virtual Server via Direct Routing）

也就是用直接路由技術實現虛擬伺服器。它的連線排程和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR透過改寫請求報文的MAC地址，將請求傳送到Real Server，而Real Server將響應直接傳回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載排程機制中效能最高最好的，但是必須要求Director Server與Real Server都有一塊網絡卡連在同一物理網段上。

回答負載排程演演算法，IPVS實現在八種負載排程演演算法，我們常用的有四種排程演演算法（輪叫排程、加權輪叫排程、最少連結排程、加權最少連結排程）。一般說了這四種就夠了，也不會需要你詳細解釋這四種演演算法的。你只要把上面3種負載均衡技術講明白麵試官就對這道問題很滿意了。接下來你在簡單說下與nginx的區別：

LVS的優點：

• 抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體裡的效能最強的；無流量，同時保證了均衡器IO的效能不會受到大流量的影響；

• 工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；

• 應用範圍比較廣，可以對所有應用做負載均衡；

• 配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的機率。

LVS的缺點：

• 軟體本身不支援正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。

• 如果網站應用比較龐大，LVS/DR+Keepalived就比較複雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單一點

Nginx的優點：

• 工作在OSI第7層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；

• Nginx對網路的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；

• Nginx安裝和配置比較簡單，測試起來比較方便；

• 可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的併發量；

• Nginx可以透過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁傳回的狀態碼、超時等等，並且會把傳回錯誤的請求重新提交到另一個節點；

• Nginx不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的Web應用伺服器。LNMP現在也是非常流行的web環境，大有和LAMP環境分庭抗禮之勢，Nginx在處理靜態頁面、特別是抗高併發方面相對apache有優勢；

• Nginx現在作為Web反向加速快取越來越成熟了，速度比傳統的Squid伺服器更快，有需求的朋友可以考慮用其作為反向代理加速器；

Nginx的缺點：

• Nginx不支援url來檢測。

• Nginx僅能支援http和Email，這個它的弱勢。

• Nginx的Session的保持，Cookie的引導能力相對欠缺。

2、redis叢集的原理，redis分片是怎麼實現的，你們公司redis用在了哪些環境？

筆者回答：reids叢集原理：

其實它的原理不是三兩句話能說明白的，redis 3.0版本之前是不支援叢集的，官方推薦最大的節點數量為1000，至少需要3(Master)+3(Slave)才能建立叢集，是無中心的分散式儲存架構，可以在多個節點之間進行資料共享，解決了Redis高可用、可擴充套件等問題。叢集可以將資料自動切分(split)到多個節點，當叢集中的某一個節點故障時，redis還可以繼續處理客戶端的請求。

redis分片：

分片(partitioning)就是將你的資料拆分到多個 Redis 實體的過程，這樣每個實體將只包含所有鍵的子集。當資料量大的時候,把資料分散存入多個資料庫中,減少單節點的連線壓力,實現海量資料儲存。分片部署方式一般分為以下三種：

（1）在客戶端做分片；這種方式在客戶端確定要連線的redis實體，然後直接訪問相應的redis實體；

（2）在代理中做分片；這種方式中，客戶端並不直接訪問redis實體，它也不知道自己要訪問的具體是哪個redis實體，而是由代理轉發請求和結果；其工作過程為：客戶端先將請求傳送給代理，代理透過分片演演算法確定要訪問的是哪個redis實體，然後將請求傳送給相應的redis實體，redis實體將結果傳回給代理，代理最後將結果傳回給客戶端。

（3）在redis伺服器端做分片；這種方式被稱為“查詢路由”，在這種方式中客戶端隨機選擇一個redis實體傳送請求，如果所請求的內容不再當前redis實體中它會負責將請求轉交給正確的redis實體，也有的實現中，redis實體不會轉發請求，而是將正確redis的資訊發給客戶端，由客戶端再去向正確的redis實體傳送請求。

redis用在了哪些環境：

java、php環境用到了redis，主要快取有登入使用者資訊資料、裝置詳情資料、會員簽到資料等

3、你會怎麼統計當前訪問的IP，併排序？

筆者回答：統計使用者的訪問IP，用awk結合uniq、sort過濾access.log日誌就能統計併排序好。一般這麼回答就夠了，當然你還可以說出其它方式來統計，這都是你的加分項。

4、你會使用哪些虛擬化技術？

筆者回答：vmware vsphere及kvm，我用得比較多的是vmware vsphere虛擬化，幾本上生產環境都用的vmware vsphere，kvm我是用在測試環境中使用。vmware 是屬於原生架構虛擬化技術，也就是可直接在硬體上執行。kvm屬於寄居架構的虛擬化技術，它是依託在系統之上執行。vmware vcenter

管理上比較方便，圖形管理介面功能很強大，穩定性強，一般比較適合企業使用。KVM管理介面稍差點，需要管理人員花費點時間學習它的維護管理技術。

5、假如有人反應，調取後端介面時特別慢，你會如何排查？

筆者回答：其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路。我是這麼說的：問清楚反應的人哪個服務應用或者頁面調取哪個介面慢，叫他把頁面或相關的URL發給你，首先，最直觀的分析就是用瀏覽器按F12，看下是哪一塊的內容過慢（DNS解析、網路載入、大圖片、還是某個檔案內容等），如果有，就對症下藥去解決（圖片慢就最佳化圖片、網路慢就檢視內網情況等）。其次，看後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點選測試來訪問介面日誌才會打出來。最後，排除sql，，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要最佳化SQL問題了，expain一下SQL看看索引情況啥的，針對性最佳化。資料量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯程式碼的問題了，一行行審程式碼，找到耗時的地方改造，最佳化邏輯。

6、mysql資料庫用的是主從讀寫分離，主庫寫，從庫讀，假如從庫無法讀取了、或者從庫讀取特別慢，你會如何解決？

筆者回答：這個問題筆者覺得回答的不太好，對mysql比較在行的朋友希望能給點建議。以解決問題為前提條件，先新增從庫數量，臨時把問題給解決，然後抓取slow log ，分析sql陳述句，該最佳化就最佳化處理。慢要不就是硬體跟不上，需要升級；要不就是軟體需要除錯最佳化，等問題解決在細化。

7、cpu單核和多核有啥區別？

筆者回答：很少有面試官會問這樣的問題，即然問到了，也要老實回答。還好筆者之前瞭解過CPU，我是這麼說的：雙核CPU就是能處理多份任務，順序排成佇列來處理。單核CPU一次處理一份任務，輪流處理每個程式任務。雙核的優勢不是頻率，而是對付同時處理多件事情。單核同時只能幹一件事，比如你同時在後臺BT下載，前臺一邊看電影一邊複製檔案一邊QQ。

8、機械磁碟和固態硬碟有啥區別？

筆者回答：我擦，啥年代了，還問磁碟的問題，這面試官有點逗啊。那也要回答啊：

HDD代表機械硬碟，SSD代表固態硬碟。首先，從效能方面來說，固態硬碟幾乎完勝機械硬碟，固態硬碟的讀寫速度肯定要快機械硬碟，因為固態硬碟和機械硬碟的構造是完全不同的（具體的構造就沒必要解釋了）。其次，固態盤幾乎沒有噪音、而機械盤噪音比較大。還有就是，以目前的市場情況來看，一般機械盤容量大，價格低；固態盤容量小，價格偏高。但是企業還是首選固態盤。

9、說一下用過哪些監控系統？

筆者回答：這個監控的問題又問到了，筆者在2018年1月4號也被問到類似這樣的問題，筆者曾經用過zabbix、nagios、 cacit等。但是在這次面試中只說用過zabbix和nagios。說完了之後，面試官就讓我說一下這兩個監控有啥區別：

從web功能及畫圖來講：

Nagios簡單直觀，報警與資料都在同一頁面， 紅色即為問題項。Nagios web端不要做任何配置。  Nagios需要額外安裝外掛，且外掛畫圖不夠美觀。

 Zabbix監控資料與報警是分開的，檢視問題項需要看觸發器，檢視資料在最新資料檢視。而且zabbix有很多其它配置項，  zabbix攜帶畫圖功能，且能手動把多個監控項集在一個圖中展示。

從監控服務來講：

Nagios自帶的監控項很少。對一些變動的如多個分割槽、多個網絡卡進行監控時需要手動配置。

Zabbix自帶了很多監控內容，感覺zabbix一開始就為你做了很多事，特別是對多個分割槽、多個網絡卡等自動發現併進行監控時，那一瞬間很驚喜，很省心的感覺。

從批次配置和報警來講：

Nagios對於批次監控主機，需要用指令碼在server端新增host，並複製service檔案。   Nagios用指令碼來修改所有主機的services檔案，加入新增服務。

Zabbix在server端配置自動註冊規則，配置好規則後，後續新增client端不需要對server端進行操作。  Zabbix只需手動在模板中新增一監控項即可。

總體來講：

Nagios要花很多時間寫外掛，Zabbix要花很多時間探索功能。

Nagios更易上手，Nagios兩天弄會，Zabbix兩周弄會。

Zabbix畫圖功能比Nagios更強大

Zabbix對於批次監控與服務更改，操作更簡潔；Nagios如果寫好自動化指令碼後，也很簡單，問題在於寫自動化指令碼很費神。

10、給你一套環境，你會如何設計高可用、高併發的架構？

筆者回答：如果這套環境是部署在雲端(比如阿裡雲)，你就不用去考慮硬體設計的問題。可直接上阿裡雲的SLB+ECS+RDS這套標準的高可用、高併發的架構。對外服務直接上SLB負載均衡技術，由阿裡的SLB分發到後端的ECS主機；ECS主機部署多臺，應用拆分在不同的ECS主機上，儘量細分服務。資料庫用RDS高可用版本（一主一備的經典高可用架構）、或者用RDS金融版（一主兩備的三節點架構）。在結合阿裡其它的服務就完全OK，業務量上來了，主機不夠用了，直橫向擴容ECS主機搞定。

如果這套環境託管在IDC，那麼你就要從硬體、軟體（應用服務）雙面去考慮了。硬體要達到高可用、高併發公司必須買多套網路硬體裝置（比如負載裝置F5、防火牆、核心層交換、接入層交換）都必須要冗餘，由其是在網路設計上，裝置之間都必須有雙線連線。裝置如果都是跑的單機，其中一個裝置掛了，你整個網路都癱瘓了，就談不上高可用、高併發了。其次在是考慮應用服務了，對外服務我會採用成熟的開源方案LVS+Keepalived或者Nginx+Keepalived，快取層可以考慮redis叢集及Mongodb叢集，中介軟體等其它服務可以用kafka、zookeeper，圖片儲存可以用fastDFS或MFS，如果資料量大、又非常多，那麼可採用hadoop這一套方案。後端資料庫可採用 “主從+MHA”。這樣一套環境下來是絕對滿足高可用、高併發的架構。

●本文編號142，以後想閱讀這篇文章直接輸入142即可

●輸入m獲取到文章目錄

更多推薦《18個技術類公眾微信》