總結一下：運維工程師面試的經歷及面試相關問題（會持續更新）

2018年1月4號面試

    筆者其實沒有想到去面試，只是在智聯上更新了一下簡歷，就陸陸續續接到不少獵頭的郵件和電話，實在是沒準備好要去面試，就推掉了幾家公司的面試了。正由於筆者也好久沒有面試了，筆者也想去面試學習一下，閒話少說，下面就分享給你們筆者在2018年1月4號上午10點30分的面試經歷：

    首先，獵頭或者公司人資會把公司的介紹及崗位要求發到你郵箱（或者QQ、微信），下面這份是獵頭髮給個人崗位說明，爲了職業道德操守，公司的介紹和麪試通知信息我就不貼出來了，我就把崗位要求貼出來：

            

職位描述：

一、 負責應用服務器的安裝、配置、優化與維護；

二、 負責應用系統的日誌信息備份、管理、維護與分析；

三、 負責應用系統的平常監測於維護、故障處理、性能分析與優化；

四、 負責應用部署系統、環境配置系統、監控系統的開發、部署、升級與維護，建設高性能的運維平臺。

崗位要求:

一、 熟悉Linux操做系統的基礎知識，熟練使用Linux經常使用操做命令；

二、 熟練配置Nginx、HAproxy 等應用相關軟件的部署、配置與優化維護；

三、 熟悉網絡基礎知識、熟悉TCP/IP的工做原理，會配交換機或路由器，能熟練的對網絡狀況進行分析

四、 熟悉shell/perl/python中的一種或多種進行運維程序的開發；

五、 熟悉Nagios,Ganglia等監控軟件

看着上面的要求你們是否是以爲要求也不高啊，你要細看就會發現，這家公司要求的還挺多，不只要會網絡知識（熟悉TCP/IP好像是每家單位的都會寫這樣的要求），還要會開發技能。相信不少作運維的兄弟在網絡這一塊是個頭疼的事情，都對交換機和路由器不怎麼會配置和管理。

    而後，筆者詳細瞭解他們公司，瞭解崗位要求，在突擊複習一下可能會問到的知識點和技術點。到了面試的這天時間，早早的起牀，把牙必定要刷乾淨，特別是有口臭的兄弟，最好準備點口香糖，到達面試公司前嚼塊口香糖，以避免由於口氣的緣由薰到面試官，讓你在面試官內心減分。早點要記得吃，若是你是下午面試的話也要吃午餐，吃早點了精氣神就有了。還要注意，帶上你的簡歷和一支筆，雖然他們那邊也會有你的簡歷，爲了以防萬一仍是準備好簡歷。

    

    最後，關鍵點來了，就是和麪試官溝通了，有筆試的公司會讓你作些面試題，沒有筆試就直接和麪試官聊了，下面是我和麪試官溝通完以後記住的一些問題，分享給你們看一下，筆者一共記住了7個問題，好像還有兩個問題實在想不起來了，若是你們有更恰當的回答必定要貼出來一塊兒探討和進步：

一、介紹下本身？（幾乎每家公司首先都會讓你作個自我介紹，好像是必修課同樣）

筆者回答：此處省略筆者的自我介紹，筆者建議介紹本身的時間不宜過長，3-4分鐘爲宜，說多了面試官會以爲你太囉嗦了。說太少了也不行，那樣會讓人感受你的經歷太簡單了、太空了。正常狀況下，通常你在作自我介紹的同時，面試官這個時候在看你的簡歷，他須要一邊看簡歷、一邊聽你介紹本身，若是你說個幾句話就把本身介紹完了，他確定還沒緩過神來，對你的映像會減分的。在介紹的同時思惟要清晰，邏輯要清楚，最好是根據你簡歷上寫的經從來介紹，這樣能夠把面試官的思路帶到你這裏來，讓他思路跟着你走。不要東扯一句，西扯一句。竟量少介紹本身的性格、愛好（最好能不說就不說），你能夠簡單羅列幹過幾家公司（最多羅列3家公司/也包含目前所在的公司，注意順序不要亂），都在那幾家公司負責什麼工做，都用過什麼技術，在着重介紹一下你目前所在的公司是負責哪些工做的，能夠稍微詳細一點介紹，不要讓面試官聽着暈頭轉向的感受。

二、灰度發佈如何實現？

筆者回答：其實對這個問題筆者也答的很差，就不寫出來誤導你們了。你們有好的方法能夠共享出來。不過筆過後在知呼上看到了一位網友的建議以爲不錯，你們能夠參考看一下 ：https://www.zhihu.com/question/20584476

三、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的原理，能說出個大概意思。萬一面試官問到了你寫的這一條，你都答不上來，那在他內心你又減分了，基本上此次面試但願不大。

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

    第三，準備充分，竟可能多的記住原理性的知識，通常面試問的多的就是原理。不多問具體的配置文件是怎麼配置的。面試前也要了解清楚「職位描述」和「崗位要求」，雖然有時候大多數不會問到崗位要求的問題，但也要了解和熟悉。

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

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

---

2017年2月24號面試

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

崗位職責：
一、負責公司產品的版本控制、構建和發佈管理；
二、負責公司統一配置庫管理工做，權限管理與分配準確及時，按期完成配置備份；
三、負責公司內部開發/測試服務器的運行管理工做；
四、負責Linux操做系統的安裝、配置、監控和維護、問題處理、軟件升級、 數據備份、應急響應、故障排除等、保證線上環境的穩定運行；
五、負責支撐平臺24×7穩定運行，並進行前瞻性容量規劃；
六、負責公司機房服務器平常維護及網絡系統安裝、部署、維護工做。

崗位要求：
一、計算機相關專業本科及以上學歷，2年以上運維或配置管理工做經驗；
二、至少熟悉一種監控系統搭建，如Nagios/Zabbix/等；
三、至少熟悉一種集羣管理工具，如Ansible/SaltStack等；
四、有使用集成發佈工具發佈構建經驗優先。好比：bamboo或者Jenkins；
五、熟悉Unix/Linux操做系統，熟悉Weblogic/tomcat等中間件，可以編寫shell腳本，熟悉軟件開發過程及過程產品，有必定的網絡基礎；
六、熟悉rsyslog, flume等日誌收集和處理系統；
七、具備強烈的安全意識及較強的溝通協調和學習能力，良好的團隊合做精神，工做積極主動。

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

一、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的引導能力相對欠缺。

二、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，主要緩存有登陸用戶信息數據、設備詳情數據、會員簽到數據等

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

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

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

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

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

五、假若有人反應，調取後端接口時特別慢，你會如何排查？

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

六、mysql數據庫用的是主從讀寫分離，主庫寫，從庫讀，假如從庫沒法讀取了、或者從庫讀取特別慢，你會如何解決？

筆者回答：這個問題筆者以爲回答的不太好，對mysql比較在行的朋友但願能給點建議。以解決問題爲前提條件，先添加從庫數量，臨時把問題給解決，而後抓取slow log ，分析sql語句，該優化就優化處理。慢要不就是硬件跟不上，須要升級；要不就是軟件須要調試優化，等問題解決在細化。

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

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

八、機械磁盤和固態硬盤有啥區別？

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

HDD表明機械硬盤，SSD表明固態硬盤。首先，從性能方面來講，固態硬盤幾乎完勝機械硬盤，固態硬盤的讀寫速度確定要快機械硬盤，由於固態硬盤和機械硬盤的構造是徹底不一樣的（具體的構造就不必解釋了）。其次，固態盤幾乎沒有噪音、而機械盤噪音比較大。還有就是，以目前的市場狀況來看，通常機械盤容量大，價格低；固態盤容量小，價格偏高。可是企業仍是首選固態盤。

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

筆者回答：這個監控的問題又問到了，筆者在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若是寫好自動化腳本後，也很簡單，問題在於寫自動化腳本很費神。

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

筆者回答：

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

若是這套環境託管在IDC，那麼你就要從硬件、軟件（應用服務）雙面去考慮了。硬件要達到高可用、高併發公司必須買多套網絡硬件設備（好比負載設備F五、防火牆、核心層交換、接入層交換）都必需要冗餘，由其是在網絡設計上，設備之間都必須有雙線鏈接。設備若是都是跑的單機，其中一個設備掛了，你整個網絡都癱瘓了，就談不上高可用、高併發了。其次在是考慮應用服務了，對外服務我會採用成熟的開源方案LVS+Keepalived或者Nginx+Keepalived，緩存層能夠考慮redis集羣及Mongodb集羣，中間件等其它服務能夠用kafka、zookeeper，圖片存儲能夠用fastDFS或MFS，若是數據量大、又很是多，那麼可採用hadoop這一套方案。後端數據庫可採用 「主從+MHA」。這樣一套環境下來是絕對知足高可用、高併發的架構。

---

對了，在下週一（2018年1月8號）有個海外的電話面試、還有下週二（2018年1月9號）有個網絡運維經理崗位的面試，其實這個網絡運維經理職位的面試有點不太想去，主要是想了解一下都會問些啥問題，能夠爲你們分享出來，因此請你們敬請期待吧。。。

持續更新中......

這篇文章實在是有點長，擠不下了，你們看後期更新的內容能夠跳轉到   總結一下：運維工程師面試的經歷及面試相關問題（續2）

喜歡個人文章，請點擊最上方右角處的《關注》支持一下！