編者按：從軟件工程初期發展的獨立主義到90年代開始強調了軟件工程化到今天完全進化成為一個產業鏈，這就是我們現在談的DevOps。本文從DevOps的起源和發展歷程，到DevOps的變遷及其關鍵使能技術，以及如何選擇適合自己的DevOps系統等三個方面詳解了系統的變遷過程。作者微博是：@fit2cloud，如果有對DevOps感興趣的朋友可以跟進行討論。

一、DevOps的起源和發展歷程

在過去的幾十年里，為了按時交付軟件產品和服務，大家越來越意識到，對于傳統把開發和運營割裂開的做法，不適合現代產品和服務開發的需求。于是，把開發和運營作為整體來看待的DevOps工程思想逐步深入人心，隨之也逐步有了對DevOps系統的需求，希望能有個平臺或工具來統一支持開發和運營的交付工作及之后的環境管理工作，即需要一系列的持續集成，持續交付，自動化部署，自動化測試監控，自動化伸縮，自動化恢復系統，以提升開發測試運營過程中的部署效率，簡化開發測試運維過程的管理，降低交付風險，降低溝通成本及運營成本。

從廣義來講，不管是云管理平臺工具(比如RightScale)，還是各種PaaS平臺(CloudFoundry，Heroku etc.)，還是自動化部署工具比如Chef、Puppet和Ansible等，其本質上都是DevOps系統的一部分，都是為了解決在開發過程的交付環節問題和交付后的運營管理問題，即

• 在開發和測試過程中，幫助開發測試人員搭建和管理環境，以便在變更后部署變更以測試;
• 在運營和支持過程中，幫助運營支持人員升級系統，擴展重建恢復系統，在升級后能夠持續地掌握系統整體和各個棧的狀態，從各個層面監控系統，伸縮系統，恢復系統。

這些年，隨著云計算和容器技術的進步，以及產品業務對IT能力的需求推動，DevOps系統發展越來越快，其角色和概念也越來越清晰和獨立。回顧其發展的路徑和變遷的過程，我們認為基本可以分為三代：基于物理機或獨立虛擬機的部署時代，基于IaaS可編程資源的部署時代和基于容器的部署時代。隨著這三代的改進，DevOps系統的整體能力越來越強。下面我們首先看一下各代DevOps系統的特點和能力，之后再對DevOps系統進行更進一步的分類，以幫助我們選擇合適的DevOps系統。

二、DevOps的變遷及其關鍵使能技術

1. 基于物理機/獨立虛機的部署時代

這是第一代DevOps系統，特點是靜態配置 + 人工協調 + 僅應用部分自動部署。

在搭建整個應用系統的過程中，首先需要在DevOps系統外創建運行應用所需的資源環境(如主機，網絡，存儲等)，DevOps系統對這部分沒有控制，只負責在資源環境搭建好后自動化部署應用，資源環境的搭建與之后的應用部署過程是割裂開來的，需要人為的手工協調控制，即等資源環境搭建好后，由人控制時機，等待資源環境準備好后再手工修改配置（如各種主機IP地址，登陸密碼Key信息），然后手工運行自動化腳本工具，如Shell，Python，Ruby腳本，進行應用的安裝部署升級，而且之后當增加或減少節點后，也由人來手工運行自動化腳本來配置系統，不能實現包括資源環境創建或節點變更到應用部署的整個過程的一鍵部署，即集群感知 + 自動協調控制 + 動態配置 + 全棧自動化。

目前，可以說大多數的DevOps系統仍然停留在這個階段，由于DevOps系統沒有實現資源環境創建的自動化與基于集群感知的協調自動化，那么這個階段的DevOps系統的能力會造成以下幾個影響和后果:

• 創建系統資源環境效率低、耗時、風險高，特別是創建復雜的系統組件多結構復雜時;
• 創建系統資源環境過程需要專門的網絡工程師、系統工程師，不能夠實現開發測試運維人員自助服務，系統越復雜，溝通成本越大，開發運維過程管理也越復雜;
• 創建整個系統需要網絡工程師，系統工程師，開發人員的共同參與和合作，系統組件越多結構越復雜，溝通成本越大，開發運維過程管理也越復雜，費時費力，協調麻煩，風險高且易出錯;
• 當系統資源環境變更時，如在增加減少主機后，由人來手工協調控制，人為手工靜態配置部署升級所需IP，登陸密碼或Key等信息，造成變更過程風險高且效率低，特別是系統龐大和復雜時;
• 交付過程風險高，開發測試產品各個環境不統一，經常出現在一個環境里運行正常，另外一個環境不正常的現象

這里需要提的一點就是，盡管很多組織已經在使用IaaS（如阿里云）創建虛擬機搭建應用系統所需資源環境，但是并沒有實現集群感知，系統整套環境創建的自動化，仍然停留在半自動化的階段（例如，先啟動一組包年包月虛擬機后，然后手工配置部署腳本所需IP地址，登陸密碼，登陸密鑰等信息，然后手工運行自動化腳本部署），所以這種方式仍然屬于第一代的DevOps系統。同時，這也是國內大多數組織DevOps的現狀，其自動化和效率的改進空間巨大。

2. 基于IaaS的部署時代

這是第二代DevOps系統，特點是集群感知 + 自動協調控制 + 動態配置 + 全棧自動化。

借助于云計算IaaS資源的可編程特性，這一代的DevOps系統實現了集群感知，自動協調控制，動態配置，全棧自動化，即實現了從創建環境到部署安裝應用組件整個過程的一鍵創建和部署，并且在創建后的階段，能夠實現集群感知(Cluster-Aware)，即自動根據環境的變更，自動部署和配置系統。舉個例子，某網站業務量增長需要擴容時，當人為添加Web計算節點后，能夠自動在新添加Web虛擬機啟動后安裝Web組件，并將各個虛擬機Web服務注冊配置到負載均衡服務中，當收縮時，自動移除，這個過程不需要人為的協調控制，DevOps系統能夠根據集群的變化自動地配置集群。

目前，做到這個層面DevOps系統還是比較少的，由于這個階段的DevOps系統自動化管理覆蓋了環境的創建變更，應用組件部署自動化，以及環境創建，集群感知和應用組件部署的各個過程自動化協調控制，那么這個階段的DevOps系統相比第一代會給開發和運維工作帶來以下非常巨大的改進:

• 開發測試運維人員能夠自助創建環境和部署系統，系統越復雜，溝通成本減少越多，開發運維過程管理復雜性風險減少越多，比如只能由有專門知識的工程師做，如果工程師在需要的時候不可用，就很麻煩;
• 創建環境和部署效率高，自動化，快速，所需時間少，風險低;
• 當系統資源環境變更時，如伸縮時，在增加減少主機后，能夠實現集群感知，動態配置集群，提高變更過程效率且降低風險，特別是系統組件多龐大和復雜時;
• 能夠按需快速創建環境滿足各種測試，演示，上線擴容需要
• 能夠按需創建啟動關閉開發測試環境，節約成本
• 能夠提高開發測試和交付的效率

3. 基于容器的部署時代

這是第三代DevOps系統，特點是在第二代基礎上，又增加了應用跨云可遷移性。(基于容器技術)。

借助于云計算IaaS資源的可編程特性以及Linux容器技術，不僅實現了集群感知，自動化協調，動態配置和全棧自動化，而且實現了應用跨云可遷移性和彈性伸縮，消除了開發，測試，生產環境的不一致，使應用不會被鎖定在某個IaaS上，讓所有的基礎設施服務IaaS及物理機都變成通用的資源池，還可以提高資源利用率，這給IT的開發建設和運營帶來了更多更大的想象空間，這也是Docker，Kubernetes現在很火的原因。

舉個例子: 如果我們想把一套服務從AWS遷移到Azure上，那么，我們將不得不從頭開始創建一組虛擬機鏡像及虛擬機，并配置安裝系統或應用的組件，如果系統復雜龐大的話，這個過程仍然會耗費很多的時間和人工，并且依賴于某些具備這個知識的工程師，但是如果有容器技術及相關容器工具的支持，那么這個過程會變成一個非常快速簡單的過程，變成在目標云如Azure上自動啟動需要的標準虛擬機，然后下載容器鏡像，配置啟動容器，配置相關DNS等，真正實現方便的跨云遷移，和彈性動態的伸縮服務。

再舉個例子，目前Google開源的容器管理系統Kubernetes可以說得到了工業界的廣泛認同和支持，當我們已經做好應用系統的Docker images后，那么只要在各個不同的IaaS上有支持Docker的環境，如Kubernetes集群，那么我們就能在不同的IaaS上快速方便的遷移應用系統，或者擴容，下圖展示了基于FIT2CLOUD的跨云部署和管理解決方案，我們希望未來用戶可以使用FIT2CLOUD在多個不同的IaaS上創建Kubernetes集群，通過Kubernetes管理和部署應用系統。之后，我們會有新文章來分享FIT2CLOUD是如何創建和運維Kunerbetes集群的。

上面這一節中我們介紹了不同時代的DevOps系統的特點和能力，那么是不是我們直接選擇能力最強的第三代DevOps系統就可以了嗎? 是不是選一種DevOps系統就通殺了呢? 答案是否定的，每種DevOps系統都不是銀彈，都需要我們根據要管理的系統的需求來選擇合適的DevOps系統或工具，在接下來的一節，我們來回答這個問題。

三、如何選擇適合自己的DevOps系統？

目前DevOps系統可以說五花八門非常多，功能上差別大，適用場景也不同，那么我們究竟該如何選擇合適的DevOps系統呢? 這里我們建議一種基于目標系統分類的選擇方法。我們根據要管理的目標應用或系統類型來分類，對于目標系統，我們可以將其首先分為三大類，即IaaS服務系統，PaaS服務系統，應用系統，應用系統又可以分為簡單的Web應用系統，復雜的分布式系統，那么有了這個分類，我們選擇DevOps系統和工具就會相對容易和明確一些。

1. IaaS服務系統

由于IaaS系統的創建，本身就是基于物理機創建的，所以對于這類的系統，其適用的DevOps系統或工具就是Shell，Chef， Puppet及IaaS服務提供商自身開發的自動化運維管理系統，只能選用第一代的基于物理機的DevOps系統。

2. PaaS服務系統

如果一個PaaS不是部署在IaaS之上，從本質上說這不是一個PaaS，因為其不具備彈性和自動伸縮。真正的PaaS系統是部署在IaaS上，為開發測試運維人員來提供服務，那么其適用的DevOps工具就可以選用RightScale，Scalr，Cloudformation，Opsworks和FIT2CLOUD這類第二代基于IaaS可編程資源的DevOps系統，當然也可以選擇第三代基于容器的DevOps系統，只是第三代的目前還在發展中，還不如第二代成熟。

3. 簡單的Web應用系統

對于簡單的Web應用系統，突出的特點就是應用的結構簡單，比如只包含一個Web組件及數據庫，緩存，或一些常見的中間件服務等，沒有包含非常多的分布式組件，那么對于這類的系統可以選擇容器類的傳統PaaS，即CloudFoundry，Heroku，OpenShift等。

4. 復雜的分布式應用系統

對于復雜的分布式應用系統，無法使用容器類PaaS來管理，只能通過自定義的DevOps工具或系統，或者使用云管理RightScale，Scalr，Cloudformation，Opsworks，FIT2CLOUD這類工具的某種或某種組合，即第二代基于IaaS可編程資源的DevOps系統，也可以選擇第三代基于容器的DevOps系統。因為這類工具給用戶提供了對IaaS主機更大的控制權，且提供了各個部署過程中的回調接口，實現了集群感知及各個部署過程的自動協調控制，即全棧自動化。

本文出自：http://blog.fit2cloud.com/2014/12/14/devops-system-evolution.html