DevOps 代表開(kāi)發(fā)和運(yùn)營(yíng)。這是一種新的軟件開(kāi)發(fā)形式，徹底改變了軟件產(chǎn)品的開(kāi)發(fā)和分發(fā)方式。DevOps方法論著眼于提供頻繁的較小升級(jí)，而不是罕見(jiàn)的大型功能集。

IT運(yùn)營(yíng)受益于DevOps。在DevOps出現(xiàn)之前，IT團(tuán)隊(duì)仍然存在一些內(nèi)在的擔(dān)憂。這導(dǎo)致IT團(tuán)隊(duì)面臨某種程度的意外懷疑。

但是，隨著DevOps的加入，這一切都發(fā)生了變化，這使IT運(yùn)營(yíng)部門可以與組織的其他部門共享這些問(wèn)題，從而提高了透明度，并提高了IT運(yùn)營(yíng)部門與其他團(tuán)隊(duì)之間的協(xié)調(diào)性。

以下部分介紹了前20個(gè)DevOps面試問(wèn)題，這些問(wèn)題將為您下一次DevOps面試做準(zhǔn)備：

問(wèn)題1：您能告訴我們DevOps和Agile之間的根本區(qū)別嗎？

答 ：盡管DevOps與敏捷方法（這是最流行的SDLC方法之一）有一些相似之處，但兩者都是軟件開(kāi)發(fā)的根本不同的方法。以下是兩者之間的各種基本差異：

•  敏捷方法–敏捷方法僅適用于敏捷開(kāi)發(fā)，而敏捷方法則適用于DevOps中的開(kāi)發(fā)和運(yùn)營(yíng)。
•  實(shí)踐和流程–敏捷涉及敏捷Scrum和敏捷看板等實(shí)踐，而DevOps涉及CD（持續(xù)交付），CI（持續(xù)集成）和CT（持續(xù)測(cè)試）等流程。
•  優(yōu)先級(jí)–敏捷優(yōu)先考慮及時(shí)性，而DevOps優(yōu)先考慮及時(shí)性和質(zhì)量。
•  發(fā)布周期– DevOps提供較小的發(fā)布周期并提供即時(shí)反饋，而Agile僅提供較小的發(fā)布周期而沒(méi)有立即反饋。
•  反饋源–敏捷依賴于客戶的反饋，而DevOps涉及到自身（監(jiān)控工具）的反饋。
•  工作范圍–對(duì)于敏捷，工作范圍僅是敏捷，而對(duì)于DevOps，這是敏捷和對(duì)自動(dòng)化的需求。

問(wèn)題2：為什么我們需要DevOps？

答 ：如今，組織正在嘗試通過(guò)一系列發(fā)布方式將小功能傳遞給客戶，而不是發(fā)布大功能集。這樣做有很多好處，包括更好的軟件質(zhì)量和快速的客戶反饋。

所有這些好處導(dǎo)致更高的客戶滿意度，這是任何產(chǎn)品開(kāi)發(fā)項(xiàng)目的最重要目標(biāo)。為此，公司需要：

•  增加部署頻率
•  縮短修復(fù)時(shí)間
•  新版本的故障率更低
•  萬(wàn)一新版本崩潰，請(qǐng)有更快的平均恢復(fù)時(shí)間

DevOps有助于滿足所有這些要求，從而實(shí)現(xiàn)無(wú)縫的軟件交付。像Amazon，Etsy和Google這樣的成熟組織已采用DevOps方法，從而實(shí)現(xiàn)了以前未知的性能水平。

通過(guò)采用DevOps方法，組織可以在一天之內(nèi)完成數(shù)以萬(wàn)計(jì)的部署。此外，這樣做還可以提供一流的可靠性，安全性和穩(wěn)定性。

問(wèn)題3：使用DevOps有哪些重要的業(yè)務(wù)和技術(shù)優(yōu)勢(shì)？

答 ：DevOps為該表帶來(lái)了很多業(yè)務(wù)和技術(shù)優(yōu)勢(shì)。下面列出了一些最重要的參數(shù)：

•  商業(yè)利益
  •   增強(qiáng)的操作環(huán)境穩(wěn)定性
  •   更快地交付功能
  •   更多時(shí)間為產(chǎn)品增值
•  技術(shù)優(yōu)勢(shì)
  •   持續(xù)交付軟件
  •   更快地解決問(wèn)題
  •   較小的復(fù)雜問(wèn)題

問(wèn)題4：您能否列舉一些最常用的DevOps工具？

答 ：以下是一些使用最廣泛的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ù)測(cè)試（CT）工具

問(wèn)題5：硒的作用是什么？

答 ：硒用于DevOps中的連續(xù)測(cè)試。該工具專門從事功能和回歸形式的測(cè)試。

問(wèn)題6：您對(duì)DevOps中的Puppet有什么了解？

答 ：這是一個(gè)配置管理工具，用于自動(dòng)執(zhí)行管理任務(wù)。Puppet利用主從結(jié)構(gòu)，其中兩個(gè)實(shí)體通過(guò)加密通道進(jìn)行通信。

系統(tǒng)管理員需要執(zhí)行許多重復(fù)性任務(wù)，尤其是安裝和配置服務(wù)器。編寫(xiě)腳本來(lái)自動(dòng)執(zhí)行此類任務(wù)是一種選擇，但是當(dāng)基礎(chǔ)結(jié)構(gòu)很大時(shí)，它變得很忙。為此，配置管理是一個(gè)不錯(cuò)的解決方法。

Puppet幫助配置，部署和管理服務(wù)器。這不僅使此類冗余任務(wù)變得更加容易，而且節(jié)省了總工作時(shí)間的很大一部分。成熟的配置管理工具：

•  持續(xù)檢查主機(jī)所需的配置是否到位。如果更改，配置將自動(dòng)還原
•  為每個(gè)主機(jī)定義不同的配置
•  對(duì)機(jī)器進(jìn)行動(dòng)態(tài)縮放（上下縮放）
•  提供對(duì)所有已配置計(jì)算機(jī)的控制，以便可以將集中更改自動(dòng)傳播到所有這些計(jì)算機(jī)

問(wèn)題7：您對(duì)DevOps的反模式有什么了解？

答 ：當(dāng)其他組織通常采用的DevOps模式在特定上下文中不起作用而組織仍在繼續(xù)使用它時(shí)，它將導(dǎo)致采用反模式。換句話說(shuō)，反模式是關(guān)于DevOps的神話。一些著名的反模式是：

•  一個(gè)組織需要有一個(gè)單獨(dú)的DevOps組
•  敏捷等于DevOps
•  DevOps是一個(gè)過(guò)程
•  DevOps是開(kāi)發(fā)驅(qū)動(dòng)的發(fā)布管理
•  由于組織獨(dú)特，因此無(wú)法進(jìn)行DevOps
•  無(wú)法進(jìn)行DevOps，因?yàn)楝F(xiàn)有人員不適合
•  DevOps意味著開(kāi)發(fā)人員管理生產(chǎn)
•  DevOps將解決所有問(wèn)題
•  無(wú)法在正在進(jìn)行的DevOps過(guò)渡中包含組織的所有方面
•  在DevOps過(guò)渡開(kāi)始時(shí)未定義KPI
•  通過(guò)一個(gè)新的DevOps團(tuán)隊(duì)來(lái)減少與其他組織之間的隔離

問(wèn)題8：DevOps有一個(gè)稱為CI的東西。它是什么，目的是什么？

答 ：DevOps中的CI代表持續(xù)集成。CI是一種開(kāi)發(fā)實(shí)踐，開(kāi)發(fā)人員可以在一天內(nèi)多次將代碼集成到共享存儲(chǔ)庫(kù)中。

開(kāi)發(fā)和測(cè)試的持續(xù)集成提高了軟件的質(zhì)量，并減少了交付所需的總時(shí)間。

如果檢查代碼的團(tuán)隊(duì)成員遇到編譯失敗，則開(kāi)發(fā)人員將破壞構(gòu)建。這樣，其他開(kāi)發(fā)人員如果不將編譯錯(cuò)誤引入自己的工作空間中，就無(wú)法與共享源代碼存儲(chǔ)庫(kù)進(jìn)行同步。

這破壞了協(xié)作和共享的開(kāi)發(fā)過(guò)程。因此，一旦配置項(xiàng)構(gòu)建中斷，立即識(shí)別并糾正問(wèn)題就很重要。

通常，配置項(xiàng)流程包括每次編譯成功時(shí)都會(huì)運(yùn)行的一組單元測(cè)試，集成測(cè)試和回歸測(cè)試。如果上述任何測(cè)試失敗，則CI構(gòu)建被認(rèn)為是不穩(wěn)定的（這在開(kāi)發(fā)正在進(jìn)行中的敏捷沖刺中很常見(jiàn)）并且沒(méi)有損壞。

問(wèn)題9：我們經(jīng)常聽(tīng)到DevOps中的左移。它是什么？

答 ：當(dāng)在紙上畫(huà)圖時(shí)，傳統(tǒng)的軟件開(kāi)發(fā)生命周期有左右兩邊。圖的左側(cè)包括設(shè)計(jì)和開(kāi)發(fā)，而右側(cè)包括生產(chǎn)階段，壓力測(cè)試和用戶接受度。

在DevOps中向左移動(dòng)僅意味著需要在右側(cè)執(zhí)行盡可能多的任務(wù)，即通常在應(yīng)用程序開(kāi)發(fā)過(guò)程的結(jié)尾發(fā)生，并將其納入DevOps方法的早期階段。

有幾種方法可以完成DevOps中的操作，最值得注意的是：

•  在每個(gè)敏捷沖刺結(jié)束時(shí)創(chuàng)建準(zhǔn)備就緒的工件
•  在每個(gè)版本中都包含靜態(tài)代碼分析例程

正確執(zhí)行DevOps的級(jí)別直接取決于盡可能左移的程度。

問(wèn)題10：DevOps中的CAMS代表什么？

答 ：首字母縮寫(xiě)詞CAMS通常用于描述DevOps方法論的核心信條。它代表：

•  文化
•  斷言
•  測(cè)量
•  共享

問(wèn)題11：用于評(píng)估DevOps成功的幾個(gè)KPI是什么？

答 ：關(guān)鍵績(jī)效指標(biāo)是關(guān)鍵績(jī)效指標(biāo)的一種合同形式。為了衡量DevOps流程的成功，可以使用幾個(gè)KPI。一些最受歡迎的是：

•  應(yīng)用性能
•  應(yīng)用程序的使用和流量
•  自動(dòng)測(cè)試通過(guò)率
•  可用性
•  改變音量
•  客戶票
•  缺陷逃逸率
•  部署頻率
•  部署時(shí)間
•  錯(cuò)誤率
•  部署失敗
•  交貨時(shí)間
•  檢測(cè)時(shí)間（MTTD）
•  平均恢復(fù)時(shí)間（MTTR）

問(wèn)題12：您認(rèn)為實(shí)施DevOps自動(dòng)化的主要好處是什么？

答 ：以下是實(shí)現(xiàn)DevOps自動(dòng)化的主要好處：

•  從CD方程式中消除人為錯(cuò)誤的可能性（核心收益）
•  隨著任務(wù)變得更加可預(yù)測(cè)和可重復(fù)，當(dāng)出現(xiàn)問(wèn)題時(shí)，很容易識(shí)別和糾正。因此，它可以產(chǎn)生更可靠，更強(qiáng)大的系統(tǒng)
•  消除CI管道的瓶頸。這會(huì)導(dǎo)致部署頻率增加和失敗的部署數(shù)量減少。它們都是重要的DevOps KPI

問(wèn)題13：您對(duì)容器了解什么？

答 ：容器是一種輕量級(jí)虛擬化形式，有助于在進(jìn)程之間提供隔離。容器比chroot重，但比管理程序輕。

問(wèn)題14：微服務(wù)是DevOps的核心部分。您可以命名兩個(gè)流行的Java開(kāi)發(fā)框架來(lái)創(chuàng)建微服務(wù)嗎？

答 ：有幾種Java框架允許創(chuàng)建微服務(wù)。但是，Eclipse MicroProfile和Spring Boot作為DevOps中用于創(chuàng)建微服務(wù)的兩個(gè)主要Java開(kāi)發(fā)框架而脫穎而出。

問(wèn)題15：您對(duì)版本控制系統(tǒng)（VCS）了解什么？定義其用途。

答 ：版本控制系統(tǒng)或VCS是一種能夠記錄一段時(shí)間內(nèi)對(duì)一個(gè)文件或一組文件所做的更改的系統(tǒng)。Git和Mercurial是兩個(gè)最受歡迎的版本控制系統(tǒng)。VCS的重要用途是：

•  檢查什么引起了問(wèn)題的最后修改
•  比較隨著時(shí)間的變化
•  確定誰(shuí)介紹了新問(wèn)題以及什么時(shí)候提出的
•  將一個(gè)或多個(gè)文件還原到某個(gè)較早的狀態(tài)
•  將整個(gè)項(xiàng)目還原到以前的狀態(tài)

問(wèn)題16：Git是流行的DevOps工具。告訴我們您將如何還原已經(jīng)推送并公開(kāi)的提交。

答 ：有兩種方法可以這樣做：

•  通過(guò)創(chuàng)建新的提交來(lái)撤消已被推送并公開(kāi)的提交所做的所有更改。執(zhí)行以下命令：

git 還原 

•  通過(guò)修復(fù)或刪除新提交中的錯(cuò)誤文件，然后將其推送到遠(yuǎn)程存儲(chǔ)庫(kù)。對(duì)文件進(jìn)行必要的更改后，使用以下命令將其提交到遠(yuǎn)程存儲(chǔ)庫(kù)： 

git commit -m“提交消息” 

問(wèn)題17：什么是post mortem會(huì)議？

答 ：很多時(shí)候需要討論在DevOps流程中出了什么問(wèn)題。為此，安排了驗(yàn)后會(huì)議。這些會(huì)議產(chǎn)生了應(yīng)該采取的步驟，以避免將來(lái)安排會(huì)議時(shí)遇到的相同或一組失敗。

問(wèn)題18：在資產(chǎn)管理和配置管理之間進(jìn)行比較。

答 ：監(jiān)視和維護(hù)實(shí)體或組的有價(jià)值的東西的過(guò)程稱為資產(chǎn)管理。

配置管理是指控制，識(shí)別，計(jì)劃和驗(yàn)證服務(wù)中的配置項(xiàng)以支持變更管理的過(guò)程。

問(wèn)題19：您能否陳述和解釋連續(xù)測(cè)試的各個(gè)關(guān)鍵要素？

答 ：連續(xù)測(cè)試的各種關(guān)鍵要素包括：

•  高級(jí)分析–用于預(yù)測(cè)和預(yù)測(cè)未知的未來(lái)事件
•  策略分析–旨在改善測(cè)試過(guò)程的手段
•  需求可追溯性–指描述需求以及從需求的起源到部署的整個(gè)過(guò)程的能力
•  風(fēng)險(xiǎn)評(píng)估–識(shí)別可能造成潛在損害的危害和風(fēng)險(xiǎn)因素的方法或過(guò)程
•  服務(wù)虛擬化–允許使用虛擬服務(wù)代替生產(chǎn)服務(wù)。仿真軟件組件以進(jìn)行簡(jiǎn)單測(cè)試
•  測(cè)試優(yōu)化–改善整體測(cè)試流程

問(wèn)題20：請(qǐng)從開(kāi)發(fā)和基礎(chǔ)結(jié)構(gòu)方面說(shuō)明DevOps的核心操作。

答 ：在開(kāi)發(fā)和基礎(chǔ)架構(gòu)方面，DevOps的核心運(yùn)營(yíng)是：

•  應(yīng)用程序開(kāi)發(fā)–開(kāi)發(fā)能夠滿足所有客戶要求并提供卓越質(zhì)量水平的產(chǎn)品
•  代碼覆蓋率–衡量在運(yùn)行自動(dòng)測(cè)試時(shí)執(zhí)行的代碼的塊，線或弧的總數(shù)
•  代碼開(kāi)發(fā)–準(zhǔn)備產(chǎn)品開(kāi)發(fā)所需的代碼庫(kù)
•  配置–以最佳方式使用產(chǎn)品
•  部署–安裝要由最終用戶使用的軟件
•  編排–安排一些自動(dòng)化任務(wù)
•  打包–準(zhǔn)備發(fā)布時(shí)涉及的活動(dòng)
•  調(diào)配–確保基礎(chǔ)結(jié)構(gòu)更改隨需要的代碼及時(shí)到達(dá)
•  單元測(cè)試–測(cè)試單個(gè)單元或組件的方法

這樣就構(gòu)成了20個(gè)重要的DevOps面試問(wèn)題的清單。除了增加獲得DevOps職位的機(jī)會(huì)之外，這些絕對(duì)可以幫助您評(píng)估并提高您對(duì)DevOps的當(dāng)前了解水平。