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