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

IT運營受益于DevOps。在DevOps出現(xiàn)之前，IT團隊仍然存在一些內在的擔憂。這導致IT團隊面臨某種程度的意外懷疑。

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

以下部分介紹了前20個DevOps面試問題，這些問題將為您下一次DevOps面試做準備：

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

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

• 增加部署頻率
• 縮短修復時間
• 新版本的故障率更低
• 萬一新版本崩潰，請有更快的平均恢復時間

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

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

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

• Ansible?–配置管理和應用程序部署工具
• Chef –配置管理和應用程序部署工具
• Docker –容器化工具
• Git –版本控制系統(tǒng)（VCS）工具
• Jenkins –持續(xù)集成（CI）工具
• Jira –敏捷的團隊協(xié)作工具
• Nagios –連續(xù)監(jiān)控工具
• Puppet –配置管理和應用程序部署工具
• 硒–連續(xù)測試（CT）工具

系統(tǒng)管理員需要執(zhí)行許多重復性任務，尤其是安裝和配置服務器。編寫腳本來自動執(zhí)行此類任務是一種選擇，但是當基礎結構很大時，它變得很忙。為此，配置管理是一個不錯的解決方法。

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

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

• 一個組織需要有一個單獨的DevOps組
• 敏捷等于DevOps
• DevOps是一個過程
• DevOps是開發(fā)驅動的發(fā)布管理
• 由于組織獨特，因此無法進行DevOps
• 無法進行DevOps，因為現(xiàn)有人員不適合
• DevOps意味著開發(fā)人員管理生產(chǎn)
• DevOps將解決所有問題
• 無法在正在進行的DevOps過渡中包含組織的所有方面
• 在DevOps過渡開始時未定義KPI
• 通過一個新的DevOps團隊來減少與其他組織之間的隔離

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

如果檢查代碼的團隊成員遇到編譯失敗，則開發(fā)人員將破壞構建。這樣，其他開發(fā)人員如果不將編譯錯誤引入自己的工作空間中，就無法與共享源代碼存儲庫進行同步。

這破壞了協(xié)作和共享的開發(fā)過程。因此，一旦配置項構建中斷，立即識別并糾正問題就很重要。

通常，配置項流程包括每次編譯成功時都會運行的一組單元測試，集成測試和回歸測試。如果上述任何測試失敗，則CI構建被認為是不穩(wěn)定的（這在開發(fā)正在進行中的敏捷沖刺中很常見）并且沒有損壞。

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

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

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

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

• 文化
• 斷言
• 測量
• 共享

• 應用性能
• 應用程序的使用和流量
• 自動測試通過率
• 可用性
• 改變音量
• 客戶票
• 缺陷逃逸率
• 部署頻率
• 部署時間
• 錯誤率
• 部署失敗
• 交貨時間
• 檢測時間（MTTD）
• 平均恢復時間（MTTR）

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

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

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

git?還原

• 通過修復或刪除新提交中的錯誤文件，然后將其推送到遠程存儲庫。對文件進行必要的更改后，使用以下命令將其提交到遠程存儲庫：

git?commit?-m“提交消息”

配置管理是指控制，識別，計劃和驗證服務中的配置項以支持變更管理的過程。

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

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

這樣就構成了20個重要的DevOps面試問題的清單。除了增加獲得DevOps職位的機會之外，這些絕對可以幫助您評估并提高您對DevOps的當前了解水平。

來源：http://bjbsair.com/it/1307.html

文章轉載：民工哥技術之路

（版權歸原作者所有，侵刪）