2020年企業運維研發經典面試題彙總（二）

防僞碼：春風釀成蜜桃酒，萬物不及你溫柔。

1、將來你想成爲一個什麼樣的人？在以後2年，你準備在哪些方面努力？

生活：

一、再優秀一點，碰到喜歡的人就能夠名正言順的心動了

二、就行安安靜靜作好本身，而後在一些方面偶爾發一點點光

三、有錢人：純粹一點，幸運一點，俗氣一點

四、若是快樂是一種本領，那麼我但願你是那個最厲害的人

五、若是你愛着山河，生活必定比誰都清楚

七、努力經營當下，直至將來明朗

八、多認識本身一點，多喜歡本身一點

九、天再高又怎樣，踮起腳尖就更接近陽光

十、接受普通，努力出衆，誠實的去生活，餓的時候吃飯，愛的時候不撒謊

技術：

一、IT基礎設施運維自動化

因爲企業要求IT基礎設施可以作到高可靠、低延時、大容量、零故障等，那就須要IT運維人員對底層硬件設備進行用心維護，硬件不出故障才能保證上層業務系統的穩定、高效地運行。

二、IT基礎設施之上在線業務系統上線

企業在線業務系統是企業對內或對外提供服務的重要途徑，IT運維人員在業務系統開發後，可以準確及時上線業務系統是對其業務能力的重要考覈標準之一。

三、IT基礎設施及在線業務系統監控自動化

對企業IT基礎設施及在線業務系統進行有效監控，可以IT運維人員及時獲知硬件或業務系統狀態，以此判斷硬件或業務系統有效服務能力，對硬件或業務系統故障作到即時反饋，即時處理，不影響企業對內或對外提供服務。

四、IT基礎設施及在線業務系統日誌處理自動化

對企業IT基礎設施及IT在線業務系統進行日誌處理（收集、分析、監控、趨勢圖展現等），獲知硬件使用或業務系統中用戶行爲，以此預測下一週期內硬件或業務系統資源可用狀況，及時應對用戶訪問波峯。

五、在線業務系統發佈自動化

使用業界先進工具實如今線業務系統代碼發佈自動化，打破傳統IT運維 &34;，實現真正的一鍵式發佈業務系統，加快系統部署速度，實現用戶無感知升級或回滾操做等。

六、IT基礎設施平臺升級

傳統的企業IT基礎設施平臺對企業在線業務系統須要底層硬件平臺的高響應、高可靠、大容量等能力反應不及時或不完全的狀況時有發生，這就須要咱們IT運維人員可以對傳統的企業IT基礎設施平臺進行升級，把傳統的企業IT基礎設施平臺升級爲雲平臺，由雲平臺的高響應、高速度、低延時、大容量等能力爲業務系統穩定運維保駕護航。

七、在線業務系統遷移至雲平臺

傳統的企業IT基礎設施平臺升級爲雲平臺後，須要IT運維人員可以把運行在傳統的企業IT基礎設施平臺之上的業務系統遷移至雲平臺。

八、雲平臺運行維護（升級）

雲平臺運行過程當中，須要IT運維人才時刻進行監控、對於雲平臺突發狀況進行處理。

九、IT運維自動化系統開發

因爲企業IT基礎設施運維過程當中，涉及多業務、多場景、多平臺等，IT運維人員在運維過程當中亟需一套本企業的IT運維管理系統，可是因爲每家企業的IT基礎設施異樣性，致使市場上沒法採購標準化系統進行應用，大多數狀況下由本企業IT運維人員根據企業自身狀況進行開發。

十、業務系統海量數據分析及展現

企業在運營過程當中產生大量的業務類數據，而且此類數據對於生產、運營等有利於決策，所以IT運維人員須要對企業內部或行業內的數據進行收集、分析、展現等，最終爲企業運營提供決策參考依據。

2、如何對開源工具進行二次開發？你的開發思路是什麼？

爲何要作二次開發：確定是由於工具包或第三方框架不知足本公司個性化需求，主要能夠採用從簡單到複雜能夠作：給予框架提供可擴展api進行擴展，對已有代碼進行二次封裝，修改源代碼並替換從新打包發佈。

3、Java web服務部署在多臺服務器上，一臺服務load飆升如何處理？

一、首先定位是因爲瞬間請求過多形成的load仍是程序自己運行出現問題，經過請求數，請求日誌，tcp鏈接數等對比正常業務量等大體

能夠判斷。

二、若是是請求過多而其餘同類服務都正常，考慮是否是遭受了dos***，其次是負載均衡策略是否是有問題，致使幾臺服務器被分配到的

請求不均勻，再極端一點，可能其餘幾臺服務都出了問題，致使所有請求打到了這臺機器

三、若是是程序自己出現了問題，我會去考慮是否是服務器自己某些資源成了瓶頸，致使沒法及時處理正常業務量業務，致使程序齊了過多線程或者鏈接，滾雪球同樣滾崩了程序，可能主要是經過日誌去排查。

4、測試在服務穩定性上能作什麼？怎麼落地？

一、功能測試：準備一份通過多方評審的，確保高覆蓋度（99.5%）的測試用例，確保系統功能複合需求且無誤，此爲前提。

二、接口測試：編寫通過多方評審的接口測試用例，鋪設各類數據場景，用數據驅動接口測試，驗證接口的功能和相應的正確性

三、安全測試：先後端檢驗一致，sql防注入，漏洞掃描等，確保服務安全符合行業標準甚至優於行業標準，保證服務不被行業排斥。

四、性能測試：編寫性能測試腳本，或者使用jmeter、lr等工具進行測試，不斷加併發數或者數據量，找到性能拐點，進而分析是服務

層、中間件、應用層仍是數據庫存在問題致使的，而後給出調優方案，促進服務性能優化，此爲重點

五、壓力測試：模擬線上環境，大數據量且高併發地連續測試數天，測試系統在高負荷下的穩定性，此爲重中之重。

5、入職第一天，你須要接手離職同窗的代碼，並立刻開始一個重要需求，你將怎麼安排一天的工做？

上午：

一、找領導瞭解需求

二、對比一下需求在原功能上實現的複雜度和難度

三、找領導確認一下是否必定要基於原框架或者架構實現，若是不用，直接瞭解一下數據庫結構和業務，看看可否用面向切面的方法快速搞定，若是公司比較注重代碼的風格一致性和可維護性，須要進一步瞭解代碼現狀。

中午：

請離職的兄弟吃個飯送送溫暖，增進一下感情，順便互換手機號，防止後續項目有問題跟不上。

下午：

一、找離職的同窗要軟件開發的代碼庫、架構文檔、數據庫結構文檔

二、和離職兄弟一塊兒過一遍代碼，主要涉及代碼增刪改查的方法類、權限控制、打包發佈方式、版本管理方法、協同做業規範、多業務交叉說明，並作好記錄

三、對下個需求工做量作簡單評估，並作出彙報。

6、說明狀況下須要進行jvm調優？你以爲最好的調優策略是什麼？

一、就考慮jvm須要的內存總大小，好比tomcat的內存給分多了用不了，分少了內存不夠，致使頻繁的GC，內存溢出

二、各塊內存的分配（新生代、老年代、存活區）

三、選擇合適的垃圾回收算法，控制GC停頓次數和時間

四、解決內存泄露的問題

五、檢查哪些對象在系統中數量最大

六、死鎖檢查

七、dump線程的詳細信息

八、檢查哪些方法佔用了大量cpu時間

7、用戶在瀏覽器輸入一個地址到頁面渲染完成，經歷了哪些過程？

一、瀏覽器會開啓一個線程處理請求，對RUL分析判斷若是是http協議就按照Web方式來處理

二、調用瀏覽器內核中的對應方法，好比WebView中的loadurl方法

三、經過DNS解析獲取網址的IP地址，設置UA等信息發出第二個GET請求

四、進行HTTP協議會話，客戶端發送請求報頭

五、進入到web服務器上的Web Server，如Apache，tomcat，node.js等服務器

六、進入部署好的後端應用，如php、java、JavaScript、python等，找到對應的請求處理。

七、處理結束回饋報頭，此處若是瀏覽器訪問過，緩存上有對應的資源，會與服務器最後修改時間對比，一直則返回302

八、瀏覽器開始下載html文檔（相應報頭、狀態碼200），同時使用緩存

九、文檔樹創建，根據標記請求所需指定MIME類型的文件（好比css、js），同時使用緩存

十、頁面開始渲染DOM，JS根據DOM API操做DOM，執行事件綁定等，頁面顯示完成。

8、你會經過什麼樣的方式快速鎖定目標公司的決策人

帶幾個性格不一樣體能不一樣的男女和這我的一塊兒登山。半天內你們都能開心到達山頂，這人就是高手

9、若是核心線程數、最大線程數、等待隊列長度都是10，此時來了15個任務，會出什麼問題？

5個線程進入等待隊列

10、在web頁面中，如何檢測用戶從點擊到頁面響應的延遲時間？

後端在頁面生成時植入JS代碼記錄服務端時間戳，前端也計算download到ready到rendered時間，再考慮本機與服務器的時間差，就能夠計算出並ajax提交用戶從點擊連接打開頁面直到元素渲染出來的全部時間段的耗時。這個能夠用圖表查詢。

11、線程池中的線程的生命週期是怎樣的？如何安全的關閉？

週期的六種狀態：新建——可運行——被阻塞——等待——計時等待——被終止

12、在產品快速迭代和試錯的過程當中，研發應該如何保證和提高工做效率，有什麼好辦法？

一、使用符合業務開發的敏捷的開發模式，規範開發和部署流程

二、按照以上流程一切能自動化都儘量自動化，一切能協同化儘量協同化。包括產品設計共享、UI設計共享、代碼、測試、部署、儘量實現CI/CD，貫徹devops、實踐最佳的投入和產出平衡點

三、基礎設施「資源化」，直接調配而不是搭建，能用成熟技術就用成熟技術

四、一個符合業務發展軌跡的有預見性的架構規劃。最大化架構思考，最小化架構實現

五、貼近業務、理解業務、關注用戶的體驗、在質量效率成本方向找一個均衡，以技術導向爲優先

六、造成知識庫，把一些公共的問題或者重要的問題記錄，好比wiki、confluence，能夠供人員查找，以便快速解決問題

七、按期覆盤。針對每一個迭代的內容，能夠作如下緣由分析及缺陷分析，查找如何解決問題及緣由。以便後續能夠規避這些問題

十3、若是讓你本身實現分佈式鎖，你會重點關注哪些方面？爲何？

常見的分佈式鎖：

一、基於數據庫實現分佈式鎖

二、基於緩存（redis）實現分部鎖

三、基於zookeeper實現分佈鎖

鎖的佔用時間限制：redis就有佔用時間限制，而zookeeper則沒有，最主要緣由是redis目前沒有辦法知道已經獲取鎖的客戶端狀態，是已經掛了呢仍是正在執行耗時較長的業務邏輯。而zookeeper經過臨時節點就能清晰的知道。若是臨時節點不存在說明已經執行完畢釋放鎖或者掛了。由此看來redis若是能像zookeeper同樣添加一些與客戶端綁定的臨時鍵，也是一件好事。

是否單點故障：redis自己有不少種玩法，如客戶端一致性hash，服務端sentinel方案或者cluster方案，很難作到一種分佈式鎖方式能應對全部這些方案。而zookeeper只有一種玩法，多臺機器的節點數據是一致的，沒有redis的那麼多麻煩因素考慮

整體來講，zookeeper實現分佈式鎖更簡單，可靠性更高。可是鎖這個問題仍是後期測試的方案比較重要

十4、如何解決在商品庫存秒殺場景下，單行數據頻繁更新帶來的行熱點問題？

一、前端層面

a、前端是整個流量的入口，正常業務訪問時系統表現平穩，可是當有人惡意請求時，須要加上流控措施，好比常見的

須要用戶回答問題，填寫驗證碼，移動圖形等，防止或者減小有機器人來惡意請求。

b、頁面上採用機防止機器人的判斷 兩秒之內的請求一概拒絕

c、經過設置nginx，對同一個ip源的請求次數作限制，防止機器人來申請

二、應用層

應用層序接收前端請求，進行一系列的數據庫操做，在咱們規避了惡意請求以後若是仍是有大量的數據寫訪問請求，咱們須要

a、對業務作降級，選擇不更新請求次數，弱化該商品申請次數的展示

b、經過異步更新來避免直接寫數據庫

應用使用分佈式緩存(好比tair)來存儲某項商品的申請次數或者某人的申請次數，以商品id/user_id爲key，申請試用人數爲value,有用戶申請成功則更新申請試用人數。不須要查詢和實時寫數據庫，每隔必定時間/次數將結果寫入數據庫。

三、數據庫層

前面介紹

a、將熱點數據拆分，分在不一樣的庫不一樣的表中，分散熱點數據，減輕數據庫併發更新熱點帶來的RT升高和應用鏈接等待時能保證業務可以正常訪問其餘商品表,損失局部可用性。

優勢:實時讀寫數據庫，前端展現數據的準確性。缺點:業務邏輯稍顯複雜。

b、限流補丁

針對某些特定的sql語句從MySQL層面加以限制,當系統thread_ _running 達到必定值或者某個sql執行時間超過一-定閾值則拒絕該sql的執行。(阿里內部已經實現限流版本)

c、使用MySQL的thread pool功能,在併發較大時，會引發Innodb的mutex鎖爭用。當前解決方法是經過innodb_ _thread_ concurrency 參數，可是該參數自身也存在鎖爭用，一樣影響了MySQL的性能。在咱們的優化歷程中，也嘗試經過優化該參數,來解決併發狀況下,性能下降的問題。

優勢: Thread pool主要從四個方面考慮:減小SQL併發,使得有足夠的資源:使用線程組獨立管理:使用優先級隊列,限制併發執行的事務:避免死鎖。

缺點:在測試過程當中發現，會有大量的鏈接等待

kernel mutex鎖,可是持續的壓力會致使MySQL的thread running,最終致使mysql不可用。

十5、使用關係型數據庫如mysql和文檔型數據庫如MongoDB時，數據模型設計有哪些區別？

mysql爲表結構，並且操做時必須嚴格按照表結構執行，適合存儲和用於關係很是強的數據項目上，好比說班級對應的學生個數，學生姓名，性別等

MongoDB表型形式爲文本流，數據表之間基本上沒啥聯繫。他這個形式就是你用word文本文檔有序或者有類名的事物和事項，並且你想怎麼加新均可以（mysql不能夠），而若是加的事項已存在，他就會合並

十6、什麼是緩存穿透？怎麼解決？

緩存穿透又稱緩存擊穿，是指在高併發場景下緩存中(包括本地緩存和redis緩存)的某一個key被高併發的訪問並無命中，此時會去db中訪問數據，致使數據庫併發的執行大量查詢操做，對db形成巨大，壓力。

1.對緩存失效的key加分佈式鎖，當-個key在本地緩存以及redis緩存中未查詢到數據，此時對key加分佈式鎖訪問db，若是取到數據反寫到緩存中，避免大量請求進入db;若是取不到數據則緩存一個空對象，這樣能夠保證db不會被大量請求直接打掛，從而引發緩存顛簸，更甚者緩存雪崩效應。

2.在本地緩存一個set集合，存儲對應數據爲空的key的集合，在請求前作攔截，此種方式牽涉到數據變動還要校驗set集合的問題，通常適用 於數據更新較少的場景

3.使用布隆過濾器

十7、https和http的區別是什麼？

傳輸信息安全性不一樣

一、http協議:超文本傳輸協議，信息明文傳輸。若是***者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息

二、https協議:具備安全性的ssI加密傳輸協議，爲瀏覽器和服務器之間的通訊加密，確保數據傳輸的安全。

鏈接方式不一樣

一、http協議: http的鏈接很簡單，是無狀態的。二、https協議:是由SSL + HTTP協議構建的可進行加密傳輸、身份認證的網絡協議。

端口不一樣

一、http協議:使用的端口是80。

二、https協議:使用的端口是443.

4、證書申請方式不一樣

一、http協議: 免費申請。

二、https協議:須要到ca申請證書，-般免費證書不多，須要交費。

十8、Cookie的工做原理是什麼？

HTTP協議是無狀態的，沒法記住客戶端身份，cookie被設計用來解決無狀態的問題，服務端在上一次請求往客戶端寫入cookie，下一次請求客戶端帶上cookie，服務端解析內容即可知道客戶端身份

十9、一個好的技術總監應該作到哪些事？

技術團隊的規模不一樣，技術總監的要求也不一樣，以50人左右，包含大數據team, java服 務器team，運維team，前端team和測試team的技術團隊爲例， 說說本身的體會:

一、技術能力，技術總監的核心競爭力仍是本身的技術能力。技術能力要廣，也要儘量的精，要精通大數據和java服務器段的技術，由於這兩塊的開發工做量最大，涉及的人員也最多。只有精通相關技術，才能作出各種(例如進度的把控，架構方案的拍板)正確決定。對於運維，前端和測試的工做，也要可以作到，瞭解他們使用什麼樣的技術，這個技術能給工做效率帶來哪些提高。

二、基於技術的判斷力，可以獨立的準確判斷儘量多,同事的技術能力(若是 你有比較強的review代碼的能力，這件事就不是很難)。 這樣既有利於把關鍵的任務分配給正確的人，也有利於團隊的同事把本身的精力更多的放在提升本身的技術能力，上。

三、持續學習的能力，這是個技術持續更新的時代,新的技術在不停的出現，你的下屬同事也在不停的進步，這就要求你本身也要不斷的學習新的技術，並儘量把新的技術引入到實際應用中。

四、保持團隊的良好風氣，實現正向循環，要創建良好的評價，獎勵機制和選拔機制，杜絕劣幣驅逐良幣,給專心工做的技術人員一個良好的工做環境。這就要求技術總監不斷提升我的的業務能力，我的修養，職業素養。

五、讓領導保持信任你，你帶着這麼多技術員，能夠算是「手握重兵」，你的領導必定會格外關注你，這個時候，該這麼作，個人總結是：作好本職工做，低調謙和，公平公正，不拉幫結派，心態開放，服從直屬領導（不盲從有原則），不瞎摻和。固然每一個領導的性格，格局和最終利益都不同。因此最根本的工做仍是作好本職工做

六、作一個長期主義者

二10、若是請你給運維新人幾個忠告，你會說什麼？

一、不懂就問、想好再問、問完確認、確認上報、工做留痕。

二、多搞linux，別走網工方向，國內網工只能走安全可是不走路由交換，安全走不通、因此多搞搞、自動化、python、k8s，Prometheus等

三、學會甩鍋，作好異地備份，不要使用root操做，危險的操做必定收到郵件才幹活

四、缺錢了能夠幹半年外包，不能幹時間太長。

五、多看書，多關注行業動態，儘可能去大廠。