轉(zhuǎn)載自? ?DevOps通用及版本控制面試題

通用DevOps面試問題

此類別將包含與任何特定DevOps階段無關(guān)的問題。這里的問題旨在測試您對DevOps的理解，而不是關(guān)注特定工具或階段。?

問題一：

DevOps和Agile之間的根本區(qū)別是什么？
兩者之間的差異列于下表中。

?

問題二：

為什么需要DevOps？
據(jù)我所知，這個答案應(yīng)該從解釋一般市場趨勢開始。公司不是發(fā)布大量功能，而是試圖通過一系列發(fā)布列表來查看是否可以將小功能傳輸給客戶。這具有許多優(yōu)點，例如來自客戶的快速反饋，更好的軟件質(zhì)量等，這反過來導(dǎo)致高的客戶滿意度。為實現(xiàn)這一目標(biāo)，公司必須：

• 增加部署頻率

• 降低新版本的故障率

• 修復(fù)之間縮短的提前期

• 新版本崩潰時平均恢復(fù)時間更快

DevOps滿足所有這些要求，有助于實現(xiàn)無縫的軟件交付。您可以舉出像Etsy，Google和亞馬遜這樣的公司的例子，在5年前，這些公司已經(jīng)采用DevOps達(dá)到了無法想象的性能水平。他們每天進行數(shù)十，數(shù)百甚至數(shù)千次代碼部署，同時提供世界級的穩(wěn)定性，可靠性和安全性。

問題三：

DevOps與Agile / SDLC有何不同？

Agile是一套關(guān)于如何生成即開發(fā)軟件的價值觀和原則。示例：如果您有一些想法，并且希望將這些想法轉(zhuǎn)變?yōu)榭捎玫能浖?#xff0c;則可以使用Agile的價值觀和原則來實現(xiàn)這一點。但是，該軟件可能只適用于開發(fā)人員的筆記本電腦或測試環(huán)境。如果您希望以安全，簡單的方式快速，輕松，可重復(fù)地將該軟件移植到生產(chǎn)基礎(chǔ)架構(gòu)中。那么，您需要DevOps工具和技術(shù)。

Agile軟件開發(fā)方法側(cè)重于軟件的開發(fā)，但另一方面，DevOps負(fù)責(zé)開發(fā)以及以最安全和最可靠的方式部署軟件。

問題四：

最頂級的DevOps工具有哪些？

最受歡迎的DevOps工具如下所述：

• Git：版本控制系統(tǒng)工具

• Jenkins：持續(xù)集成工具

• Selenium：連續(xù)測試工具

• Puppet，Chef，Ansible：配置管理和部署工具

• Nagios：持續(xù)監(jiān)控工具

• Docker：容器化工具

問題五：

所有這些工具如何協(xié)同工作？
下面給出了一個通用的邏輯流程，其中所有內(nèi)容都自動進行無縫交付 但是，根據(jù)要求，此流程可能因組織而異。

1.開發(fā)人員開發(fā)代碼，此源代碼由Git等版本控制系統(tǒng)工具管理。

2.開發(fā)人員將此代碼發(fā)送到Git存儲庫，并且代碼中所做的任何更改都將提交到此存儲庫。

3.Jenkins使用Git插件從存儲庫中提取此代碼，并使用Ant或Maven等工具構(gòu)建它。

4.配置管理工具，如puppet部署和配置測試環(huán)境，然后Jenkins在使用selenium等工具進行測試的測試環(huán)境中發(fā)布此代碼。

5.一旦代碼被測試，Jenkins就會將其發(fā)送到生產(chǎn)服務(wù)器上進行部署（甚至生產(chǎn)服務(wù)器也由puppet等工具進行配置和維護）。

6.部署后，Nagios等工具會持續(xù)監(jiān)控。

7.Docker容器提供測試環(huán)境以測試構(gòu)建功能。

?

問題六：

DevOps有哪些優(yōu)勢？

對于這個答案，您可以使用您過去的經(jīng)驗并解釋DevOps如何幫助您完成上一份工作。如果您沒有任何此類經(jīng)驗，那么您可以提及以下優(yōu)勢。

技術(shù)優(yōu)勢：
持續(xù)的軟件交付
修復(fù)不太復(fù)雜的問題
更快地解決問題

商業(yè)利益：

更快速地傳遞功能

更穩(wěn)定的操作環(huán)境
有更多時間可以增加價值（而不是修復(fù)/維護）

問題七：

DevOps幫助我們實現(xiàn)的最重要的事情是什么？
據(jù)我所知，DevOps幫助我們實現(xiàn)的最重要的事情是盡可能快地將更改投入生產(chǎn)，同時最大限度地降低軟件質(zhì)量保證和合規(guī)性的風(fēng)險。這是DevOps的主要目標(biāo)。

但是，您可以添加DevOps的許多其他積極效果。例如，團隊之間更清晰的溝通和更好的工作關(guān)系，即Ops團隊和開發(fā)團隊合作共同提供高質(zhì)量的軟件，從而提高客戶滿意度。

問題八：

DevOps的反模式有哪些？
模式是通常遵循的常見用法。如果其他人普遍采用的模式對您的組織不起作用，并且您繼續(xù)盲目地遵循它，那么您實際上采用的是反模式。有關(guān)于DevOps的謬見。包括下面一些：

DevOps是一個過程
Agile等于DevOps
我們需要一個單獨的DevOps組
Devops將解決我們所有的問題
DevOps意味著開發(fā)人員管理生產(chǎn)
DevOps是開發(fā)驅(qū)動的發(fā)布管理
DevOps不是開發(fā)驅(qū)動的。
DevOps不是IT運營驅(qū)動的。
我們不能做DevOps - 我們是獨一無二的
我們不能做DevOps - 我們遇到了錯誤的人

版本控制系統(tǒng)（VCS）面試問題

下面讓我們看一下關(guān)于VCS的面試問題：

問題一：

什么是版本控制？
這可能是您在面試中將面臨的最簡單的問題。我的建議是首先給出版本控制的定義。它是一個記錄文件或文件集隨時間變化的系統(tǒng)，以便您以后可以調(diào)用特定版本。版本控制系統(tǒng)由一個中央共享存儲庫組成，隊友可以在其中提交對文件或文件集的更改。然后你可以提到版本控制的用途。

版本控制允許您：

將文件還原為以前的狀態(tài)。
將整個項目還原為以前的狀態(tài)。
比較一段時間內(nèi)的變化
查看最后一次修改可能導(dǎo)致問題的內(nèi)容。
誰在何時引入了一個問題。

問題二：

使用版本控制有什么好處？

我建議你包括版本控制的以下優(yōu)點：

使用版本控制系統(tǒng)（VCS），所有團隊成員都可以隨時在任何文件上自由工作。稍后VCS將允許您將所有更改合并到一個通用版本中。

所有過去的版本和變體都整齊地打包在VCS中。當(dāng)您需要它時，您可以隨時請求任何版本，您將獲得完整項目的快照。

每次保存項目的新版本時，VCS都要求您提供已更改內(nèi)容的簡短說明。此外，您還可以查看文件內(nèi)容的確切更改內(nèi)容。這可以讓您知道誰在項目中做了哪些更改。

像Git這樣的分布式VCS允許所有團隊成員擁有項目的完整歷史記錄，因此如果中央服務(wù)器出現(xiàn)故障，您可以使用任何團隊成員的本地Git存儲庫。

問題三：

描述您使用的分支策略。
這個問題被要求測試你的分支經(jīng)驗，告訴他們你在以前的工作中如何使用分支以及它的用途是什么，你可以參考以下幾點：

功能分支：
功能分支模型保留分支內(nèi)特定功能的所有更改。通過自動化測試對功能進行全面測試和驗證后，分支將合并為主服務(wù)器。
任務(wù)分支
在此模型中，每個任務(wù)都在其自己的分支上實現(xiàn)，任務(wù)鍵包含在分支名稱中。很容易看出哪個代碼實現(xiàn)了哪個任務(wù)，只需在分支名稱中查找任務(wù)鍵。

發(fā)布分支：
一旦開發(fā)分支獲得了足夠的發(fā)布功能，您就可以克隆該分支以形成發(fā)布分支。創(chuàng)建此分支將啟動下一個發(fā)布周期，因此在此之后不能添加任何新功能，只有錯誤修復(fù)，文檔生成和其他面向發(fā)布的任務(wù)才能進入此分支。一旦準(zhǔn)備好發(fā)布，該版本將合并到主服務(wù)器并標(biāo)記版本號。此外，它應(yīng)該合并回到開發(fā)分支，自發(fā)布以來可能已經(jīng)取得了進展。
最后告訴他們分支策略因組織而異，所以我知道基本的分支操作，如刪除，合并，檢查分支等。

問題四：

您熟悉哪種VCS工具？

你可以提到你曾經(jīng)使用過的VCS工具：“我已經(jīng)研究過Git，它對SVN等其他VCS工具的一個主要優(yōu)勢就是它是一個分布式版本控制系統(tǒng)。”?
分布式VCS工具不一定依靠中央服務(wù)器來存儲項目文件的所有版本。相反，每個開發(fā)人員都“克隆”存儲庫的副本，并在自己的硬盤上擁有項目的完整歷史記錄。

問題五：

什么是Git？
我建議您首先解釋一下git的體系結(jié)構(gòu)來嘗試這個問題，如下圖所示。您可以參考下面給出的解釋：

Git是一個分布式版本控制系統(tǒng)（DVCS）。它可以跟蹤文件的更改，并允許您恢復(fù)到任何特定的更改。

與SVN等其他版本控制系統(tǒng)（VCS）相比，其分布式架構(gòu)具有許多優(yōu)勢，一個主要優(yōu)點是它不依賴于中央服務(wù)器來存儲項目文件的所有版本。相反，每個開發(fā)人員“克隆”我在下圖中使用“本地存儲庫”顯示的存儲庫副本，并在其硬盤驅(qū)動器上具有項目的完整歷史記錄，以便在出現(xiàn)服務(wù)器中斷時，只需要恢復(fù)所需的全部內(nèi)容是你隊友的本地Git存儲庫之一。

還有一個中央云存儲庫，開發(fā)人員可以在其中提交更改并與其他團隊成員共享，如圖所示，所有協(xié)作者都在提交更改“遠(yuǎn)程存儲庫”。?

?

問題六：

在Git中，您如何還原已經(jīng)推送并公開的提交？
此問題可以有兩個答案，因此請確保包含兩個答案，因為根據(jù)具體情況可以使用以下任何選項：

在新提交中刪除或修復(fù)錯誤文件，并將其推送到遠(yuǎn)程存儲庫。這是修復(fù)錯誤的最自然方式。對文件進行必要的更改后，將其提交到遠(yuǎn)程存儲庫，使用

git?commit?-m?“commit?message”

創(chuàng)建一個新的提交，撤消在錯誤提交中所做的所有更改。為此，我將使用命令

git?revert?<錯誤提交的名稱>

問題七：

你如何將N次提交壓縮成一次提交？

將N個提交壓縮成單個提交有兩種選擇。在您的答案中包括以下兩個選項：
如果要從頭開始編寫新的提交消息，請使用以下命令

git?reset?–soft?HEAD~N?&& git?commit

如果你想用現(xiàn)有提交消息的串聯(lián)開始編輯新的提交消息，那么你需要提取這些消息并將它們傳遞給Git commit，我將使

git?reset?–soft?HEAD~N?&& git?commit?–edit?-m”$(git?log?–format=%B?–reverse?.HEAD@{N})”

問題八：

什么是Git bisect？你怎么用它來確定（回歸）bug的來源？
我建議你先給出一個Git bisect的小定義，Git bisect用于查找使用二進制搜索引入bug的提交。Git bisect的命令是

git?bisect?<子命令>?<選項>

現(xiàn)在你已經(jīng)提到了上面的命令，解釋一下這個命令會做什么，這個命令使用二進制搜索算法來查找項目歷史中的哪個提交引入了一個bug。您可以通過首先告訴它已知包含該錯誤的“錯誤”提交以及在引入錯誤之前已知的“良好”提交來使用它。然后Git bisect在這兩個端點之間選擇一個提交，并詢問您所選的提交是“好”還是“壞”。它繼續(xù)縮小范圍，直到找到引入更改的確切提交。

問題九：

什么是Git rebase以及它如何在合并之前用于解決功能分支中的沖突？

根據(jù)我的說法，您應(yīng)該首先說git rebase是一個命令，它將另一個分支合并到您當(dāng)前正在工作的分支中，并將所有位于重新分支之前的本地提交移到該歷史記錄的頂部。

現(xiàn)在，一旦您為一個示例定義了Git rebase時間，以顯示如何在合并之前使用它來解決功能分支中的沖突，如果從master創(chuàng)建了一個功能分支，從那時起主分支已收到新的提交，Git rebase可用于將要素分支移動到主要提示。

該命令有效地將重放在master的tip處的功能分支中所做的更改，從而允許在該過程中解決沖突。完成后，這將允許功能分支相對容易地合并到主服務(wù)器中，有時作為簡單的快進操作。

問題十：

如何配置Git存儲庫以在提交之前運行代碼健全性檢查工具，并在測試失敗時阻止它們？

我建議你先做一個簡單的檢查，完整性測試或煙霧測試，確定繼續(xù)測試是否合理可行。

現(xiàn)在解釋如何實現(xiàn)這一點，可以通過與存儲庫的預(yù)提交hook相關(guān)的簡單腳本來完成。即使在您需要輸入提交消息之前，也會在提交之前觸發(fā)預(yù)提交hook。在此腳本中，可以運行其他工具，例如linters，并對提交到存儲庫中的更改執(zhí)行完整性檢查。

最后給出一個例子，你可以參考下面的腳本：

#!/bin/sh files=$(git?diff?–cached?–name-only?–diff-filter=ACM?|?grep?‘.go$’) if?[?-z?files?];?then exit?0 fi unfmtd=$(gofmt?-l?$files) if?[?-z?unfmtd?];?then exit?0 fi echo?“Some?.go?files?are?not?fmt’d” exit?1

如果需要通過標(biāo)準(zhǔn)Go源代碼格式化工具gofmt傳遞任何即將提交的.go文件。可以通過非零狀態(tài)退出，使腳本有效地阻止將提交應(yīng)用于存儲庫。

問題十一：

如何找到特定提交中已更改的文件列表？

對于這個問題，答案不僅僅只是告訴命令，解釋這個命令究竟會做什么。
你可以這么說，為了獲得在特定提交中更改的列表文件使用命令

git?diff-tree?-r?{hash}

給定提交哈希，這將列出在該提交中更改或添加的所有文件。-r標(biāo)志使命令列表單個文件，而不是僅將它們折疊到根目錄名稱中。

你也可以包括下面提到的點，雖然它是完全可選的，但有助于給面試官留下深刻的印象。

輸出還將包含一些額外的信息，可以通過包含兩個標(biāo)志來輕松抑制：

git?diff-tree?–no-commit-id?–name-only?-r?{hash}

這里-no-commit-id將禁止提交哈希值出現(xiàn)在輸出中，而-name-only只會打印文件名而不是它們的路徑。

問題十二：

每次存儲庫通過推送接收新提交時，如何設(shè)置腳本運行？

每次存儲庫通過push接收新提交時，有三種方法可以配置腳本運行，需要根據(jù)需要觸發(fā)腳本的時間來定義預(yù)接收，更新或后接收hook。

將提交提交到目標(biāo)存儲庫時，將調(diào)用目標(biāo)存儲庫中的預(yù)接收hook。綁定到此hook的任何腳本都將在更新任何引用之前執(zhí)行。這是一個有用的hook，用于運行有助于實施開發(fā)策略的腳本。

Update hook以類似于預(yù)接收hook的方式工作，并且在實際進行任何更新之前也會觸發(fā)。但是，對于已推送到目標(biāo)存儲庫的每個提交，都會調(diào)用一次update hook。

最后，在將更新接受到目標(biāo)存儲庫后，將調(diào)用存儲庫中的post-receive hook。這是配置簡單部署腳本，調(diào)用一些持續(xù)集成系統(tǒng)，向存儲庫維護人員發(fā)送通知電子郵件等的理想場所。

hook是每個Git存儲庫的本地存儲，并且沒有版本化。腳本可以在“.git”目錄內(nèi)的hooks目錄中創(chuàng)建，也可以在別處創(chuàng)建，并且可以在目錄中放置這些腳本的鏈接。

問題十三：

如果分支已經(jīng)合并為主分支，你怎么知道Git？

我建議你包括下面提到的命令：

git branch -merged ? ? //列出已合并到當(dāng)前分支的分支。 git branch -no-merged ?//列出了尚未合并的分支。

?

總結(jié)

以上是生活随笔為你收集整理的DevOps通用及版本控制面试题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。