20 個(gè)最重要的 DevOps 面試題
DevOps 代表開發(fā)和運(yùn)營。這是一種新的軟件開發(fā)形式，徹底改變了軟件產(chǎn)品的開發(fā)和分發(fā)方式。DevOps方法論著眼于提供頻繁的較小升級，而不是罕見的大型功能集。
IT運(yùn)營受益于DevOps。在DevOps出現(xiàn)之前，IT團(tuán)隊(duì)仍然存在一些內(nèi)在的擔(dān)憂。這導(dǎo)致IT團(tuán)隊(duì)面臨某種程度的意外懷疑。
但是，隨著DevOps的加入，這一切都發(fā)生了變化，這使IT運(yùn)營部門可以與組織的其他部門共享這些問題，從而提高了透明度，并提高了IT運(yùn)營部門與其他團(tuán)隊(duì)之間的協(xié)調(diào)性。
以下部分介紹了前20個(gè)DevOps面試問題，這些問題將為您下一次DevOps面試做準(zhǔn)備：
答 ：盡管DevOps與敏捷方法（這是最流行的SDLC方法之一）有一些相似之處，但兩者都是軟件開發(fā)的根本不同的方法。以下是兩者之間的各種基本差異：
-
敏捷方法–敏捷方法僅適用于敏捷開發(fā)，而敏捷方法則適用于DevOps中的開發(fā)和運(yùn)營。 -
實(shí)踐和流程–敏捷涉及敏捷Scrum和敏捷看板等實(shí)踐，而DevOps涉及CD（持續(xù)交付），CI（持續(xù)集成）和CT（持續(xù)測試）等流程。 -
優(yōu)先級–敏捷優(yōu)先考慮及時(shí)性，而DevOps優(yōu)先考慮及時(shí)性和質(zhì)量。 -
發(fā)布周期– DevOps提供較小的發(fā)布周期并提供即時(shí)反饋，而Agile僅提供較小的發(fā)布周期而沒有立即反饋。 -
反饋源–敏捷依賴于客戶的反饋，而DevOps涉及到自身（監(jiān)控工具）的反饋。 -
工作范圍–對于敏捷，工作范圍僅是敏捷，而對于DevOps，這是敏捷和對自動(dòng)化的需求。
答 ：如今，組織正在嘗試通過一系列發(fā)布方式將小功能傳遞給客戶，而不是發(fā)布大功能集。這樣做有很多好處，包括更好的軟件質(zhì)量和快速的客戶反饋。
所有這些好處導(dǎo)致更高的客戶滿意度，這是任何產(chǎn)品開發(fā)項(xiàng)目的最重要目標(biāo)。為此，公司需要：
-
增加部署頻率 -
縮短修復(fù)時(shí)間 -
新版本的故障率更低 -
萬一新版本崩潰，請有更快的平均恢復(fù)時(shí)間
DevOps有助于滿足所有這些要求，從而實(shí)現(xiàn)無縫的軟件交付。像Amazon，Etsy和Google這樣的成熟組織已采用DevOps方法，從而實(shí)現(xiàn)了以前未知的性能水平。
通過采用DevOps方法，組織可以在一天之內(nèi)完成數(shù)以萬計(jì)的部署。此外，這樣做還可以提供一流的可靠性，安全性和穩(wěn)定性。
答 ：DevOps為該表帶來了很多業(yè)務(wù)和技術(shù)優(yōu)勢。下面列出了一些最重要的參數(shù)：
-
商業(yè)利益 -
增強(qiáng)的操作環(huán)境穩(wěn)定性 -
更快地交付功能 -
更多時(shí)間為產(chǎn)品增值
-
-
技術(shù)優(yōu)勢 -
持續(xù)交付軟件 -
更快地解決問題 -
較小的復(fù)雜問題
-
答 ：以下是一些使用最廣泛的DevOps工具的列表：
-
Ansible?–配置管理和應(yīng)用程序部署工具 -
Chef –配置管理和應(yīng)用程序部署工具 -
Docker –容器化工具 -
Git –版本控制系統(tǒng)（VCS）工具 -
Jenkins –持續(xù)集成（CI）工具 -
Jira –敏捷的團(tuán)隊(duì)協(xié)作工具 -
Nagios –連續(xù)監(jiān)控工具 -
Puppet –配置管理和應(yīng)用程序部署工具 -
硒–連續(xù)測試（CT）工具
答 ：硒用于DevOps中的連續(xù)測試。該工具專門從事功能和回歸形式的測試。
答 ：這是一個(gè)配置管理工具，用于自動(dòng)執(zhí)行管理任務(wù)。Puppet利用主從結(jié)構(gòu)，其中兩個(gè)實(shí)體通過加密通道進(jìn)行通信。
系統(tǒng)管理員需要執(zhí)行許多重復(fù)性任務(wù)，尤其是安裝和配置服務(wù)器。編寫腳本來自動(dòng)執(zhí)行此類任務(wù)是一種選擇，但是當(dāng)基礎(chǔ)結(jié)構(gòu)很大時(shí)，它變得很忙。為此，配置管理是一個(gè)不錯(cuò)的解決方法。
Puppet幫助配置，部署和管理服務(wù)器。這不僅使此類冗余任務(wù)變得更加容易，而且節(jié)省了總工作時(shí)間的很大一部分。成熟的配置管理工具：
-
持續(xù)檢查主機(jī)所需的配置是否到位。如果更改，配置將自動(dòng)還原 -
為每個(gè)主機(jī)定義不同的配置 -
對機(jī)器進(jìn)行動(dòng)態(tài)縮放（上下縮放） -
提供對所有已配置計(jì)算機(jī)的控制，以便可以將集中更改自動(dòng)傳播到所有這些計(jì)算機(jī)
答 ：當(dāng)其他組織通常采用的DevOps模式在特定上下文中不起作用而組織仍在繼續(xù)使用它時(shí)，它將導(dǎo)致采用反模式。換句話說，反模式是關(guān)于DevOps的神話。一些著名的反模式是：
-
一個(gè)組織需要有一個(gè)單獨(dú)的DevOps組 -
敏捷等于DevOps -
DevOps是一個(gè)過程 -
DevOps是開發(fā)驅(qū)動(dòng)的發(fā)布管理 -
由于組織獨(dú)特，因此無法進(jìn)行DevOps -
無法進(jìn)行DevOps，因?yàn)楝F(xiàn)有人員不適合 -
DevOps意味著開發(fā)人員管理生產(chǎn) -
DevOps將解決所有問題 -
無法在正在進(jìn)行的DevOps過渡中包含組織的所有方面 -
在DevOps過渡開始時(shí)未定義KPI -
通過一個(gè)新的DevOps團(tuán)隊(duì)來減少與其他組織之間的隔離
答 ：DevOps中的CI代表持續(xù)集成。CI是一種開發(fā)實(shí)踐，開發(fā)人員可以在一天內(nèi)多次將代碼集成到共享存儲庫中。
開發(fā)和測試的持續(xù)集成提高了軟件的質(zhì)量，并減少了交付所需的總時(shí)間。
如果檢查代碼的團(tuán)隊(duì)成員遇到編譯失敗，則開發(fā)人員將破壞構(gòu)建。這樣，其他開發(fā)人員如果不將編譯錯(cuò)誤引入自己的工作空間中，就無法與共享源代碼存儲庫進(jìn)行同步。
這破壞了協(xié)作和共享的開發(fā)過程。因此，一旦配置項(xiàng)構(gòu)建中斷，立即識別并糾正問題就很重要。
通常，配置項(xiàng)流程包括每次編譯成功時(shí)都會運(yùn)行的一組單元測試，集成測試和回歸測試。如果上述任何測試失敗，則CI構(gòu)建被認(rèn)為是不穩(wěn)定的（這在開發(fā)正在進(jìn)行中的敏捷沖刺中很常見）并且沒有損壞。
答 ：當(dāng)在紙上畫圖時(shí)，傳統(tǒng)的軟件開發(fā)生命周期有左右兩邊。圖的左側(cè)包括設(shè)計(jì)和開發(fā)，而右側(cè)包括生產(chǎn)階段，壓力測試和用戶接受度。
在DevOps中向左移動(dòng)僅意味著需要在右側(cè)執(zhí)行盡可能多的任務(wù)，即通常在應(yīng)用程序開發(fā)過程的結(jié)尾發(fā)生，并將其納入DevOps方法的早期階段。
有幾種方法可以完成DevOps中的操作，最值得注意的是：
-
在每個(gè)敏捷沖刺結(jié)束時(shí)創(chuàng)建準(zhǔn)備就緒的工件 -
在每個(gè)版本中都包含靜態(tài)代碼分析例程
正確執(zhí)行DevOps的級別直接取決于盡可能左移的程度。
答 ：首字母縮寫詞CAMS通常用于描述DevOps方法論的核心信條。它代表：
-
文化 -
斷言 -
測量 -
共享
答 ：關(guān)鍵績效指標(biāo)是關(guān)鍵績效指標(biāo)的一種合同形式。為了衡量DevOps流程的成功，可以使用幾個(gè)KPI。一些最受歡迎的是：
-
應(yīng)用性能 -
應(yīng)用程序的使用和流量 -
自動(dòng)測試通過率 -
可用性 -
改變音量 -
客戶票 -
缺陷逃逸率 -
部署頻率 -
部署時(shí)間 -
錯(cuò)誤率 -
部署失敗 -
交貨時(shí)間 -
檢測時(shí)間（MTTD） -
平均恢復(fù)時(shí)間（MTTR）
答 ：以下是實(shí)現(xiàn)DevOps自動(dòng)化的主要好處：
-
從CD方程式中消除人為錯(cuò)誤的可能性（核心收益） -
隨著任務(wù)變得更加可預(yù)測和可重復(fù)，當(dāng)出現(xiàn)問題時(shí)，很容易識別和糾正。因此，它可以產(chǎn)生更可靠，更強(qiáng)大的系統(tǒng) -
消除CI管道的瓶頸。這會導(dǎo)致部署頻率增加和失敗的部署數(shù)量減少。它們都是重要的DevOps KPI
答 ：容器是一種輕量級虛擬化形式，有助于在進(jìn)程之間提供隔離。容器比chroot重，但比管理程序輕。
答 ：有幾種Java框架允許創(chuàng)建微服務(wù)。但是，Eclipse MicroProfile和Spring Boot作為DevOps中用于創(chuàng)建微服務(wù)的兩個(gè)主要Java開發(fā)框架而脫穎而出。
答 ：版本控制系統(tǒng)或VCS是一種能夠記錄一段時(shí)間內(nèi)對一個(gè)文件或一組文件所做的更改的系統(tǒng)。Git和Mercurial是兩個(gè)最受歡迎的版本控制系統(tǒng)。VCS的重要用途是：
-
檢查什么引起了問題的最后修改 -
比較隨著時(shí)間的變化 -
確定誰介紹了新問題以及什么時(shí)候提出的 -
將一個(gè)或多個(gè)文件還原到某個(gè)較早的狀態(tài) -
將整個(gè)項(xiàng)目還原到以前的狀態(tài)
答 ：有兩種方法可以這樣做：
-
通過創(chuàng)建新的提交來撤消已被推送并公開的提交所做的所有更改。執(zhí)行以下命令：
git?還原
-
通過修復(fù)或刪除新提交中的錯(cuò)誤文件，然后將其推送到遠(yuǎn)程存儲庫。對文件進(jìn)行必要的更改后，使用以下命令將其提交到遠(yuǎn)程存儲庫：
git?commit?-m“提交消息”
答 ：很多時(shí)候需要討論在DevOps流程中出了什么問題。為此，安排了驗(yàn)后會議。這些會議產(chǎn)生了應(yīng)該采取的步驟，以避免將來安排會議時(shí)遇到的相同或一組失敗。
答 ：監(jiān)視和維護(hù)實(shí)體或組的有價(jià)值的東西的過程稱為資產(chǎn)管理。
配置管理是指控制，識別，計(jì)劃和驗(yàn)證服務(wù)中的配置項(xiàng)以支持變更管理的過程。
答 ：連續(xù)測試的各種關(guān)鍵要素包括：
-
高級分析–用于預(yù)測和預(yù)測未知的未來事件 -
策略分析–旨在改善測試過程的手段 -
需求可追溯性–指描述需求以及從需求的起源到部署的整個(gè)過程的能力 -
風(fēng)險(xiǎn)評估–識別可能造成潛在損害的危害和風(fēng)險(xiǎn)因素的方法或過程 -
服務(wù)虛擬化–允許使用虛擬服務(wù)代替生產(chǎn)服務(wù)。仿真軟件組件以進(jìn)行簡單測試 -
測試優(yōu)化–改善整體測試流程
答 ：在開發(fā)和基礎(chǔ)架構(gòu)方面，DevOps的核心運(yùn)營是：
-
應(yīng)用程序開發(fā)–開發(fā)能夠滿足所有客戶要求并提供卓越質(zhì)量水平的產(chǎn)品 -
代碼覆蓋率–衡量在運(yùn)行自動(dòng)測試時(shí)執(zhí)行的代碼的塊，線或弧的總數(shù) -
代碼開發(fā)–準(zhǔn)備產(chǎn)品開發(fā)所需的代碼庫 -
配置–以最佳方式使用產(chǎn)品 -
部署–安裝要由最終用戶使用的軟件 -
編排–安排一些自動(dòng)化任務(wù) -
打包–準(zhǔn)備發(fā)布時(shí)涉及的活動(dòng) -
調(diào)配–確?；A(chǔ)結(jié)構(gòu)更改隨需要的代碼及時(shí)到達(dá) -
單元測試–測試單個(gè)單元或組件的方法
這樣就構(gòu)成了20個(gè)重要的DevOps面試問題的清單。除了增加獲得DevOps職位的機(jī)會之外，這些絕對可以幫助您評估并提高您對DevOps的當(dāng)前了解水平。
來源：http://bjbsair.com/it/1307.html
文章轉(zhuǎn)載：民工哥技術(shù)之路
（版權(quán)歸原作者所有，侵刪）