【51CTO.com原創稿件】什么是 DevOps?“DevOps”是“開發”development 和“運維”operations 兩者的組合。

[[338947]]
圖片來自 Pexels

 

DevOps 可看作一種文化風向標，在該文化引領下，能促進項目團隊中開發，測試，運維，產品等成員間的無縫協作。

它通過有效的自動化及可重復的方式更快地將代碼部署到生產環境中，提高企業交付應用程序或服務的速度，從而更好地為客戶提供高質量的產品，并在市場上獲取更強有力地競爭優勢。

因此，DevOps 可視為企業項目團隊中一條持續優化，密切配合，協同運轉的“隱形生產鏈”。

 

為什么需要 DevOps?

在那些沒有 DevOps 實踐的日子里，項目團隊都經歷了什么：

• 項目內部開發團隊和運維團隊是完全獨立的。
• 當開發團隊針對需求進行代碼設計/構建后，測試任務和部署任務也是完全孤立彼此的活動，往往導致整體項目實際周期比預期構建耗時更長。
• 團隊成員各自花費大量時間用于設計，開發，測試，部署，而非匯聚于整體項目構建本身(即，分而不合)。
• 手動部署代碼往往不可避免出現人為錯誤，即便通過 Jenkins 持續集成，這僅僅是構建中的一部分而已。
• 產品，開發，測試，運維團隊有各自的時間軸，并不同步，將導致累計延遲的情況。

持續提升團隊產品的交付率，在確保產品質量的前提下縮短交付時間，是每個項目團隊共同的目標，然而理想與現實間總會橫著一道難以逾越的鴻溝。

全球知名研究機構 Forrester 曾指出：只有 17% 的團隊能在足夠快地時間內交付客戶所需產品。

在無 DevOps 文化引入及實踐的情況下，從以上列出的 5 大痛點不難得出團隊生產力低下，協同工作效率不盡如人意的原因所在。

DevOps 與傳統 IT 的區別

為了清晰認識到 DevOps 引入給項目運作帶來的變化， 以下將結合一則場景對比“傳統研發模式” VS “DevOps”的相異之處。

假設當前項目團隊工作進展如下：

 

“傳統研發模式” VS “DevOps”對比圖如下：

 

DevOps 的價值

在敏捷項目研發大規模盛行的當下，DevOps 有助于敏捷團隊更好地實行持續集成和持續交付，進而幫助項目團隊更快地將他們所研發的產品/系統/平臺投放市場。

此外 DevOps 的優勢不僅局限于此，它還有其他值得關注的因素：

• 可預測性：DevOps 有效降低了新版本的故障率。
• 可重復性：DevOps 可將所有項目中的內容進行版本控制，便于隨時還原早期版本。
• 可維護性：在新版本崩潰或當前系統不可用的情況下，通過 DevOps 可輕松執行恢復過程。
• 上市時間：DevOps 通過簡化的軟件交付程序，大大縮短了產品上市時間(保守估計至少可縮短 50% 的時間)，這搶占市場先機的數據對當下的移動應用程序來說絕對是一大亮點。
• 更高的質量：DevOps 中的基礎設施建設有助于團隊提高應用程序開發的質量。
• 降低風險：DevOps 將安全因素納入到軟件交付的生命周期中，這大大減少了整個生命周期中的缺陷。
• 將較大的代碼庫分成小段：DevOps 基于敏捷編程方法，將較大的代碼庫分解為較小的可管理模塊。

DevOps 生命周期

DevOps 在開發和運營間構建了一座深度集成橋梁，只有全面了解 DevOps 生命周期才能進一步體會到持續集成持續部署(CI/CD)的實際意義。

以下羅列出 DevOps(CI/CD)生命周期中各階段的核心任務：

①開發(Development)

DevOps 實踐中會將整個軟件開發過程分為若干個小的開發周期，這有益于 DevOps 團隊通過小規模迭代來加快軟件開發和軟件交付的過程。

②測試(Testing)

QA 團隊通過自動化手段輔助測試，協助開發人員識別和修復新代碼中的錯誤。

③持續集成(Continues Integration)

在此階段，新增功能將集成進之前的代碼中，進行集成測試;言下之意，我們順理成章地得出：持續開發只有通過持續集成和持續測試才能有效驗證，從而確保能夠順利進入下一階段的迭代。

④持續部署(Continues Deployment)

在 DevOps 中，除了強調持續集成(CI)外，部署過程也是持續進行的，在持續部署(CD)過程中，必須確保代碼在任何時間所做的任何更改都不會影響到當前網站/系統已上線的功能(尤其是那些高流量的網站)。

⑤監控(Monitoring)

在此階段，運維團隊將密切關注系統/平臺中的錯誤，Bug 等任何異常行為，實時反饋一切異常情況。

DevOps VS 敏捷

項目利益干系人和溝通鏈是 IT 流程中典型的核心要素，如果說敏捷模式的引入是為了解決客戶方與研發團隊溝通中的空白，那么 DevOps 的植入則填補了研發團隊與 IT 運維團隊間的空白。

“敏捷” VS “DevOps”對比圖如下：

 

DevOps 原則

DevOps 有以下六大不可缺少的原則：

• 以客戶為中心：DevOps 團隊必須采取以客戶為中心的原則，客戶才是產品和服務的投資者。
• 端到端的責任：DevOps 團隊需要持續提供性能支持。
• 持續改進：DevOps 注重持續改進以最大程度地減少資源浪費，不斷加快產品研發/服務提供的改進速度。
• 自動化一切：自動化是 DevOps 流程的重要原則，不僅適用于軟件研發，同樣適用于整個基礎架構設施。
• 團隊合作：DevOps 定義了設計，開發，測試，運維的角色，整個團隊全面配合，協同工作。
• 監視一切，測試一切：對于 DevOps 團隊來說，擁有可靠的監視和測試流程尤為重要。

DevOps 自動化工具

DevOps 提倡將一切過程自動化，并對其進行配置，在大型 DevOps 團隊中，維護大型 IT 基礎架構所面臨的困難可以簡單地分為以下六類：

• 基礎設施自動化
• 配置管理
• 自動化部署
• 性能管理
• 日志管理
• 監控管理

基于以上六大類，DevOps 實踐中都有與之對應的工具/服務來解決各自的難題，下面逐一為大家介紹。

①基礎設施自動化

Amazon Web Services(AWS)：亞馬遜公司旗下的云計算服務平臺，幾乎能夠在云中運行一切應用程序，沒有前期硬件成本，易按需擴展，為全世界用戶提供了一整套基礎設施和云解決方案，包括彈性計算、存儲、數據庫、應用程序在內的整套云計算服務，有效幫助企業降低 IT 投入成本和維護成本，實現輕松在云上部署一切。

②配置管理

Chef：這是一個非常有用的 DevOps 工具，可實現速度提升，大規模擴展以及保障整體一致性。

借助該工具，DevOps 團隊可以避免在多臺服務器之間進行更改的情況，只需要在一個地方進行更改，相應的變更將會自動同步到其他服務器中。

③自動化部署

Jenkins：可促進持續集成和持續測試，在持續集成后定時觸發自動化測試，這有助于更輕松地將變更有效集成于現有項目中。

④性能管理

App Dynamic：一款 DevOps 工具，可提供實時性能監控，該工具收集的數據有助于開發人員在問題出現時及時調試。

⑤日志管理

Splunk：是一款非常優秀的日志分析軟件，能處理常規的日志格式，比如 apache、squid、系統日志、mail.log 等。

它支持日志索引，交叉查詢，復雜的查詢語句等，并能通過非常直觀的方式展現出來。

日志可以通過文件方式傳送到 Splunk 服務器，也可通過網絡實時傳輸，或者是分布式日志收集方式，總之它支持多種日志收集方法，是一個匯總，存儲和分析所有日志的大本營。

⑥監控管理

Nagios：確保基礎架構和相關服務出現故障時，相關人員能及時獲悉該消息，并能實時響應并著手處理，Nagios 能夠協助 DevOps 團隊發現并及時糾正產品/系統/服務中存在的問題。

Nagios DevOps 監控管理

亞馬遜 CTO Werner Vogels 曾提及在 DevOps 實踐中，他們的研究著眼于“有多少團隊在運行應用程序/基于產品提供的服務”，無論是由研發團隊、運營團隊還是軟件發布成員或其他項目利益干系人，都有權定義監控指標。

基于上述提及的一系列用于 DevOps 實踐的自動化輔助工具，我們以 Nagios 事件管理為例簡單展示其在自動化監控管理中的優勢。

Nagios 事件管理器是一款企業級，基于 Web 的事件管理應用程序，它允許團隊或個人通過其強大的 Web 應用程序更快地跟蹤和解決問題，該應用程序除了具備安全性和移動性外，還擁有與第三方集成協作的功能。

Nagios 事件管理器中主要包的菜單有: 智能儀表盤(Dashboard)、事件(Incidents)、報告(Reports)、管理(Admin)和幫助菜單。

以下我們逐一描述事件管理器的基本用法，包括但不限于創建、管理和關閉事件、跟蹤統計數據等。

智能儀表盤(Dashboard)

 

如上圖：

事件摘要(Incident Summary)：顯示當前需要引起注意的事件數量，直接點擊鏈接，進入到對應的事件頁面。

最近操作(Recent Actions)：顯示最近的 5 個操作。可以通過事件名(鏈接)來查看對應事件上的操作。

在智能儀表盤(Dashboard)頁面中，可以通過單擊右上角的“new incident”創建一個新的事件。

事件(Incidents)

在事件(Incidents)頁面中，我們可以創建新的事件，管理已存在的事件。

①事件篩選：當單擊 Incidents 菜單時，默認情況下會顯示所有 open Incidents。可以通過單擊頁面頂部選項卡(打開“open”、關閉“closed”、已解決“resolved”、新建“new”或全部“all”)來篩選不同狀態的事件。

 

還可以通過單擊每列的標題，按名稱“Title”、創建“Created”或更新日期“Last Updated”、事件類型“Type”、事件狀態“Status”和優先級“Priority”對當前事件列表進行排序。

 

②事件管理：選擇想要處理的事件(復選框)，單擊“Delete Selected”，可以批量刪除事件;單擊“Update Selected”，可以批量更改事件的優先級、狀態或類型。

 

 

③創建新事件：單擊右上角的“new incident”可以創建一個新的事件;填寫必要的事件信息后，單擊頁面底部的“Save Incident”保存新建的事件。

 

④事件編輯：通過單擊某個事件名稱，來到事件編輯頁面，在該頁面添加關于該事件的更新消息，輸入對應的消息后，點擊發布消息“Post Message”即可。

可以通過單擊“edit Details”或“delete incident”來查看、編輯或刪除特定事件。

報告(Reports)

 

在 Reports 頁面中，通過單擊報告名稱，可以指定開始和結束日期/時間，單擊“Update”來生成對應的報告。

報告包含以下四類數據：

• 統計報告(General Statistics)：概述性報告，包括其他三個報告的數據，即：平均解決時間(MTTR)、首次響應時間和關閉的事件。
• 平均解決時間(MTTR)：包含解決每個事件所花費的平均時間，MTTR 總量也會在頁面底部顯示。
• 首次響應時間(First Response Times)：包含對每個事件首次響應的平均時間，首次響應的平均時間總量也會在頁面底部顯示。
• 已關閉事件(Closed Incident)：已關閉事件的總數。

 

管理(Admin)

管理頁面由四個部分組成：

• 用戶和團隊(Users&Teams)
• 事件(Incidents)
• 服務器設置(Server Settings)
• 系統備份(System Backups)

下面分別對每部分所負責的任務進行展示：

①用戶和團隊(Users & Teams)

 

創建用戶：點擊左上角的添加用戶“Add User”，輸入所需的信息，保存后即可生效。

 

創建團隊：點擊添加團隊“Add Team”，輸入所需的信息，保存后即可生效。

 

②事件(Incidents)

這個板塊專門用于管理事件類型、回調 API、查看每個事件當前上傳的文件;單擊左上角的“new Type”添加新的事件類型;通過單擊右邊的“Delete Incident Type”按鈕來刪除事件類型。

 

在“Callback API”頁面可以添加新的回調函數，編輯或刪除現有的回調函數;點擊右上角的“New Callback”來新建回調 API，填寫所需信息，選擇“Enable this callback”復選框來啟用此回調，保存后即可生效。

 

③服務器設置(Server Settings)

 

服務器設置中涉及到通用服務設置、LDAP/AD 集成、許可證設置、郵件設置及檢查更新;在“郵件設置”頁面，可以更改使用的郵件協議，PHP 郵件是默認設置的。

 

總結

對比傳統 IT 項目研發流程，DevOps 能夠幫助企業將其產品部署周期從數年轉移到數月和數周，在此過程中提供各個環節的可維護性，可預測性，確保更高的質量成本，工作效率及上市時間。

DevOps 正在成為 IT 人員的重要技能，例如，在 Linux 招聘中進行的一項調查發現，受訪者中有 25% 的求職者是 DevOps 專業人士。

總而言之，面對更加復雜的項目，多變的環境及基礎設施，傳統企業及個人必須對此做出改變，DevOps 工程師應具有解決問題的能力，并能快速學習，唯有如此，才能在確保品質的前提下，持續優化，快速發展，與個人企業都應當如是。

作者：羅小羅

簡介：英國 TOP10 計算機專業，計算機科學與技術碩士，先后就職于匯豐，JPMorgan，HP，交行，阿里等國內外知名企業。涉及項目領域主要有：互聯網金融，電商，教育，醫療等。現任就職于某世界 500 強公司，擔任測試開發團隊負責人，帶領團隊構建并持續優化自動化測試框架，研發自動化測試輔助類工具;擅長領域：單元/接口/性能/安全/自動化測試/CD/CI/DevOps;個人持續研究領域：自動化測試模型/數據分析/算法/機器學習等。

編輯：陶家龍

征稿：有投稿、尋求報道意向技術人請聯絡 editor@51cto.com

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】