DevOps實踐一：DevOps概述

09-10

DevOps實踐一：DevOps概述

歡迎大家關注我的公眾號： OneAndZero

0. 前言

DevOps系列文章包含了本人在工作中的實踐和認知理論，現總結並分享出來，希望能夠給「迷你型」團隊在DevOps上的實踐提供一個「反面教材」和可行性建議。

本系列主要包含以下文章(過程中可能也會有所更改)：

DevOps實踐一：DevOps概述
DevOps實踐二：持續集成、持續交付和持續部署
DevOps實踐三：如何構建面嚮應用的CMDB系統
DevOps實踐四：如何打造持續交付系統
DevOps實踐五：監控系統與持續交付系統的聯動
DevOps實踐六：運維標準化體系的建設
DevOps實踐七：微服務架構與DevOps

1. DevOps 的產生

人類曾有長達250萬年的時間靠採集及狩獵維生，並不會特別干預動植物的生長情形。直立人、匠人或是尼安德特人都會採集野無花果、獵捕野綿羊，但不會去管究竟無花果樹該長在哪，羊該在哪片草地吃草，又或是哪只公羊該跟母羊交配。

這段話摘錄自《人類簡史》，之所以引入這段話，是因為運維技術的發展也可以類比到人類的發展史。運維在很長的時間內，都是在靠「人肉」來提供運維能力，即使是發展到現在，依然如此。雖然國內外有很多大公司，在這方面已經走在前沿並且輸出了一些實踐經驗，但是運維進化的過程還有很長一段路要走。畢竟這世界上，更多的是小公司、小團隊。

2009年，Patrick Debois發起了一個名為DevOpsDays的會議，始於比利時，現已經傳播到多個國家。術語DevOps現在已經在多種情況下使用。Bass, Weber和Zhu提出的定義是：

DevOps是一組旨在保證高質量的同時，減少將更改提交到系統和將更改放入正常生產之間的時間的實踐。

通俗點來說，DevOps的目的在保證高質量的同時減少發布流程的總耗時。然而，這一點真的這麼重要嗎？

2. 為什麼需要DevOps？

我相信幾乎所有的開發、測試、運維都聽過敏捷軟體開發，有的公司也是採用這種模式來進行產品的快速迭代，以此驗證產品的可行性，快速搶佔市場、拿到更多投資；或提供更多的功能給用戶使用；或修復軟體Bug解決用戶的抱怨。快速迭代意味著產品需要頻繁的部署上線，這也就意味著研發、測試、運維團隊必須克服這種頻繁上線帶來的諸多問題：研發質量低；測試不充分，上線後Bug層出不窮；運維上線部署慢、跟不上研發的節奏，經常由於環境、配置等問題導致應用不能正常提供服務等等等等。

一方面公司希望快速將產品交付給用戶使用，另一方面技術人員又害怕這種快速交付，畢竟越快越容易出問題，而且壓力大(身上背了很多鍋)。

正是在這種背景下，DevOps應運而生。為研發、測試、運維團隊提供了理論性指導。

3. DevOps模式定義

AWS對DevOps模式做了一個完整的定義，我個人也是傾向於此：

DevOps集文化理念、實踐和工具於一身。可以提高組織交付應用程序和服務的能力。與使用傳統軟體和基礎設施管理流程相比，能夠幫助組織更快的發展和改進產品。這種速度使組織更好的服務其客戶，並在市場上高效的參與競爭。

DevOps文化的宗旨就是為了消除團隊之間的壁壘。因此，DevOps的文化理念決定了開發、測試、運維團隊不再是一個孤立的團隊。彼此之間需要增強合作，成為一個高效的團隊。

通過DevOps的定義我們可以一窺其優勢：

快速交付
可靠性
增強團隊合作
規模

這些優勢會在後續文章中不斷地體現出來。

4. 應用發布流程

在介紹DevOps實踐時，我們需要先探討一下應用發布流程。我簡單的畫了一個圖：

有的公司可能還有預發布環境，但是該圖應該能反應大部分公司的整個發布流程。

5. DevOps實踐

由於DevOps是一種跨職能(開發、測試、運維)的工作模式，不是一個單獨的DevOps工具，因此DevOps作為工具時，它包含了多個工具，形成了一個完整的工具鏈。結合個人經驗，這裡先做一個簡單的概括，後續文章會將這些進行詳解介紹。

對照上面的發布流程中，我舉出每個環節所使用的常用工具：

代碼倉庫，用於存儲程序源文件的地方。如：GitLab，Github
構建，這是一個持續集成工具，用於編譯、打包程序，運行單元測試如：Jenkins
測試，提供有關業務風險反饋的連續測試工具。如：Selenium
發布，快速上線部署，自動化發布。這裡我是自研，後續文章會做一個介紹。
配置，基礎架構配置和管理。如 SaltStack
監控，應用監控、基礎監控，幫助運維快速定位問題。如：Zabbix, OpenFalcon

上面這些工具，結合業內提出的概念，按照發布流程進行組合，可以概括為以下四點：

持續集成

軟體發布流程的構建和單元測試階段。這是由開發者提交變更到代碼倉庫後自動觸發。

持續交付

對持續集成的補充，在單元測試完成後，自動部署到測試環境/生產環境。持續交付的中心模式是部署流水線，本質上講就是一個應用程序從構建、測試、到發布這整個過程的自動化實現。

持續部署

持續交付在最後上線階段需要人工干預，持續部署不需要。持續部署就是在沒有明確批准的情況下自動發生。

監控

實時獲取應用狀態和環境狀態，異常發生後運維能作出快速反應。

如果對持續集成和持續交付不太理解的，可以參考下面這種圖，再對照我上面的應用發布流程圖，應該能很快理解：

如果理解了持續交付，可能會有一種持續交付和DevOps是同一個事物的錯覺，實則不是。引用維基百科的一段描述作此說明：

Continuous delivery and DevOps have common goals and are often used in conjunction, but there are subtle differences.
While continuous delivery is focused on automating the processes in software delivery, DevOps also focuses on the organization change to support great collaboration between the many functions involved.
持續交付和DevOps有共同的目標，並且經常結合使用，但存在細微差別。雖然持續交付的重點是自動化軟體交付流程，但DevOps還專註於組織變更，以支持所涉及的眾多功能之間的良好協作。

對此我解讀為：持續交付是DevOps的一個子集，是DevOps的一個實踐經驗。

備註：DevOps於2009年提出，持續交付於2010年提出。

6. 總結

本章主要講述了DevOps的產生背景，以及一個基本的概念。最後概述性的介紹了DevOps的實踐，並列舉了一些工具。本章只是開端，一篇理論性的文章也很難讓人明白到底什麼是DevOps。後面會將個人的一些實踐經驗進行一個總結，希望能夠讓讀者大致明白我所理解的DevOps。之所以稱之為「我所理解的DevOps」，是因為在實踐中，我並不是完全遵循了這些理論性指導，個中緣由我會在後面的文章中進行闡述。但我們的重點是在於讓軟體快速交付、解決運維工作中的痛點，不是嗎？我一直堅信，理論是對我們行為模式的指導，並不一定需要完全遵從。

——————————————————分割線————————————————————歡迎大家關注我的公眾號： OneAndZero

http://weixin.qq.com/r/0i5OVh-ERUI6rVs193vA (二維碼自動識別)