DevOps （Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。
它是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發佈軟件能夠更加地快捷、頻繁和可靠。
技術革新
在以前的系統中業務單一、邏輯簡單、用戶量少，項目團隊的規模一般在 10~30人。而現在的系統要面對不同用戶的定製化推薦等，互聯網連接着人與人、人與物、以及物與物，業務也變得越來越複雜，功能越來越多，如果整個系統耦合在一起，則必定會牽一髮而動全身，導致系統維護起來相當困難。
因此IT技術架構也隨着系統的複雜化而不斷地變化革新，從早期所有服務的All In One發展到現在的微服務架構、從純手動操作到全自動化流程、從單臺物理機到雲平臺，下圖展示了IT技術革新的變化：
現在DevOps已經成爲發展的趨勢了，那它又是怎麼實現落地的呢？
如何實現DevOps的落地
知之真切篤實處即是行，行之明覺精察處即是知 —— 明•王守仁《傳習錄》
在些我引用了聖賢王陽明的一句名言，他提倡“知行合一”，通俗的講就是做事情要理論與實踐相結合。我們在實現DevOps落地時也一定要遵循“理論與實踐相結合”的方式進行，理論就是我們做事的指導思想，而實踐就是具體做事的方法，接下來我就從我在公司中是如何按照理論與實踐相結合來推動DevOps落實地。
落實DevOps的指導思想
首先我們還是要回到什麼是DevOps，如果大家忘記了可以回到之前再溫故一下，包括我總結的DevOps公式。
其實DevOps核心思想就是：“快速交付價值，靈活響應變化”。其基本原則如下：
-
高效的協作和溝通；
-
自動化流程和工具；
-
快速敏捷的開發；
-
持續交付和部署；
-
不斷學習和創新。
然而這些基本原則又是如何與項目研發息息相關的呢，也就是它們在我們的開發過程中的各個環節是如何體現的？請看下面一張來自《success with enterprise dev-ops - whitepaper》的介紹圖：
-
敏捷管理：一支訓練有素的敏捷開發團隊是成功實施DevOps的關鍵。
根據康威定律：軟件團隊開發的產品是對公司組織架構的反映。
所以根據公司情況調整組織結構是首要條件，它將直接影響到需求、設計和開發階段的效率、以及溝通的成本。
關於團隊的溝通成本在《人月神話》中有個很好的計算公式：溝通成本 = n(n-1)/2，其中n爲人數，所以溝通成本將隨着組織人員的增加而呈指數級增長。而小而快的敏捷團隊如何劃分，我將在後面“DevOps的具體實施方法”一節中詳細介紹。
-
持續交付部署：實現應用程序的自動化構建、部署、測試和發佈。
通過技術工具，把傳統的手工操作轉變爲自動化流程，這不僅有利於提高產品開發、運維部署的效率，還將減少人爲因素引起的失誤和事故，提早發現問題並及時地解決問題，這樣也保證了產品的質量。下圖展示了DevOps自動化的流程：
-
此圖來自我的新書《分佈式服務架構：原理、設計與實戰》，書中也有具體介紹持續交付部署的細節內容。
-
IT服務管理：可持續的、高可用的IT服務是保障業務正常的關鍵要素，它與業務是一個整體。
IT服務管理（ITSM）直接影響產品運營的整個生命週期，傳統的IT服務管理（像ITIL）在生產中做的非常好了，但是它對於DevOps來說又顯得過於繁瑣，所以有必要爲DevOps創建一個只關注業務持續性的ITMS，它只需要很少的必要資源來爲相應的業務提供服務，ITMS更多地從業務角度考慮了。
注：白話解釋下什麼是IT服務管理（ITSM），它是傳統的“IT管理”轉向爲“IT服務”爲主的一種模式，前者可能更關注具體服務器管理、網絡管理和系統軟件安裝部署等工作；而後者更關注流程的規範化、標準化，明確定義各個流程的目標和範圍、成本和效益、運營步驟、關鍵成功因素和績效指標、有關人員的責權利，以及各個流程之間的關係等，比如建立線上事故解決流程、服務配置管理流程等；
而光有流程還不夠，因爲流程主要是IT服務提供方內部使用的，客戶對他們並不感興趣，所以還需將這些流程按需打包成特定的IT服務，然後提供給客戶使用，比如在雲平臺上購買一臺虛擬雲主機一樣。 -
精益管理：建立一個流水線式的IT服務鏈，打通開發與運維的鴻溝，實現開發運維一體化的敏捷模式。
精益生產主要來源於豐田生產方式 (TPS)的生產哲學，它以降低浪費、提升整體客戶價值而聞名，它主要利用優化自動化流程來提高生產率、降低浪費。所以精益生產的精髓是即時制（JIT）和自動化（Jidoka）。
JIT（Just In time）：JIT用一句話描述就是消耗最少的必要資源，以正確的數量，生產和運送正確的零件。在這種模式下工作，可以最大程度上降低庫存，防止過早或者過度生產。大多數公司更傾向用庫存來避免潛在的停線風險，而豐田卻反其道而行之。通過減少庫存“逼迫”對生產中產生的問題做及時且有效的反應。當然JIT這一模式對解決問題的能力是相當大的考驗，在能力不足的情況下，會有相當大的斷線風險。
Jidoka（Build in quality）：自動化，日語表示爲“自働化”，字面含義是自動化，日語裏表示爲“自動化”，而在豐田TPS系統裏，特意給“動”字加上了“人”字旁變成了“働”，換句話說，TPS/精益生產渴望生產的過程控制能像“人”一樣智能，在第一時間就異常情況下自動關閉。這種自動停機功能可以防止壞件流入下游，防止機器在錯誤的生產狀態下造成損壞，也可以讓人更好的在當前錯誤狀態下進行故障分析。當設備能夠做到自動分析故障時，就可以將監管機器的“人”真正解放出來，做到對人力成本的節省。
——來自知乎
下圖展示了豐田TPS（Toyota Production System）手冊中的精益小屋：
而精益軟件開發是精益生產和實踐在軟件開發領域的應用，總結爲如下七條原則：
-
消除浪費
-
增強學習
-
儘量延遲決定
-
儘快發佈
-
下放權力
-
嵌入質量
-
全局優化
精益管理貫穿於整個DevOps階段，它鼓勵主動發現問題，不斷的優化流程，從而達到持續交付、快速反饋、降低風險和保障質量的目的。接下來讓我們看看DevOps具體的實現方法。
實施DevOps的具體方法
-
建立快速敏捷團隊
根據之前介紹的康威定律，我們可以看下目前公司中的項目團隊結構是怎麼的，如下圖所示：
![傳統的組織結構和系統架構]()
我相信這不僅僅是我們公司這樣的結構，而是目前大多數IT互聯網公司普遍的分層結構吧，它們一般分爲七大部門：產品策劃、設計美術、前端工程師、後端工程師、測試工程師、運維&DBA和市場運營等。各部門之間天然的形成了溝通障礙牆，相互之間主要以郵件和會議的形式溝通，效率低下、需求變更困難、很難快速響應市場變化和持續交付高品質的產品。
那麼如何調整組織結構，建立一個Scrum團隊呢？（什麼是Scrum請參考維基百科）
我們會按照業務功能劃分團隊，建立溝通羣組，設置產品負責人（一個策劃人員）、Scrum Master（我們一般選擇測試人員擔任，測試驅動開發模式）和開發者團隊（前端工程師、後端工程師、測試各一名），最後的組織結構和系統架構如下圖所示：
一個高效的敏捷團隊是DevOps能落地的保障，那麼自動化流程就是保證產品快速交付和持續部署的有效機制，接下來爲大家介紹我們是如何實現自動化流程的？
-
實現自動化的流程
直接看圖說話吧，以下爲一個完整DevOps的Pipeline：
![]()
-
提交：工程師將代碼在本地測試後，提交到版本控制系統，如 Git代碼倉庫中。
-
構建：持續整合系統（如Jenkins CI），在檢測到版本控制系統更新時，便自動從Git代碼倉庫里拉取最新的代碼，進行編譯、構建。
-
單元測試：Jenkins完成編譯構建後，會自動執行指定的單元測試代碼。
-
部署到測試環境：在完成單元測試後，Jenkins可以將應用程序部署到與生產環境相近的測試環境中進行測試。
-
預生產環境測試：在預生產測試環境裏，可以進行一些最後的自動化測試，例如使用Appium自動化測試工具進行測試，以及與實際情況類似的一些測試可由開發人員或客戶人員手動進行測試。
-
部署到生產環境：通過所有測試後，便可以使用灰度更新將最新的版本部署到實際生產環境裏。
-
而實現DevOps自動化流水線所需要哪些技術，它們又是如何配合使用的？帶着這些問題，我將在DevOps的技術棧一節中詳細爲大家介紹。接下來讓我們看看DevOps在遊戲項目中實施所遇到的問題吧。
技術棧
本節內容如果展開的話涉及太多，我將概略地爲大家介紹下目前常見的一些開源DevOps技術工具，大家可以根據自己的需求選擇使用，當然也可以使用像VSTS（Visual Studio Team Services）這樣的集成團隊環境。
其中有些內容在我的新書中有詳細介紹，如代碼倉庫管理、虛擬機與容器化、持續集成&持續部署工具Jenkins、配置管理工具SaltStack。
敏捷管理工具
-
Trello
-
Teambition
-
Worktile
-
Tower
以上工具使用大同小異，選擇一款適合自己團隊的就好。我們公司主要使用的是Teambition，截張效果圖如下：
產品&質量管理
-
confluence
-
禪道
-
Jira
-
Bugzila
其中confluence和禪道主要是產品的需求、定義、依賴和推廣等的全面管理工具；而Jira和Bugzilla是產品的質量管理和監控能力，包括測試用例、缺陷跟蹤和質量監控等。目前我們使用Jira較多。
代碼倉庫管理
-
Git
-
Gitlab
-
Github
Git是一個開源的分佈式版本控制系統；Gitlab和Github是用於倉庫管理系統的開源項目，它們使用Git作爲代碼管理工具，並在此基礎上搭建起來的web服務。我們主要使用的是Git和Gitlab。
開發流程規範
-
Git Flow
Git Flow是構建在Git之上的一個組織軟件開發活動的模型，是在Git之上構建的一項軟件開發最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行爲規範和簡化部分Git操作的工具。Git Flow模型如下圖：
![Git Flow模型]()
-
Github Flow
Github Flow是Git Flow的一個更簡單的替換方案，它只有一個feature分支和一個master分支，簡單而乾淨。Github Flow模型如下圖：
![Github Flow模型]()
-
Gitlab Flow
GitHub Flow認爲你可以通過合併feature分支直接把代碼部署到線上。Gitlab Flow模型如下圖：
![Gitlab Flow模型]()
自動化構建腳本
-
Gradle
-
Maven
-
SBT
-
ANT
我目前主要使用Gradle和Maven，而Gradle是一個基於Apache Ant和Apache Maven概念的項目自動化構建工具。它使用一種基於Groovy的特定領域語言(DSL)來聲明項目設置，拋棄了基於XML的各種繁瑣配置。面向Java應用爲主。當前其支持的語言限於Java、Groovy、Kotlin和Scala。
虛擬機與容器化
-
VMware
-
VirtualBox
-
Vagrant
-
Docker
VMware和VirtualBox是最常用的虛擬機，支持非常多的平臺，而Vagrant是構建在虛擬化技術之上的虛擬機運行環境管理工具。通過Vagrant可以方便實現的對虛擬機的管理，包括建立和刪除虛擬機、配置虛擬機運行參數、管理虛擬機運行狀態、自動化配置和安裝開發環境必須的各類軟件、打包和分發虛擬機運行環境等。
Docker是一個開源的應用容器引擎，它讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然後發佈到任何流行的Linux機器上，也可以實現虛擬化。
持續集成（CI）&持續部署（CD）
-
Jenkins
-
Hudson
-
Travis CI
-
CircleCI
Jenkins是一個開源軟件項目，是基於Java開發的一種持續集成工具，用於監控持續重複的工作，旨在提供一個開放易用的軟件平臺，使軟件的持續集成變成可能，它的前身爲Hudson。
Travis CI 是目前新興的開源持續集成構建項目，它與jenkins很明顯的區別在於採用yaml格式，簡潔清新獨樹一幟。
CircleCI是一個爲web應用開發者提供服務的持續集成平臺，主要爲開發團隊提供測試，持續集成，以及代碼部署等服務。
自動化測試
-
Appium
Appium是一個移動端的自動化框架，可用於測試原生應用，移動網頁應用和混合型應用，且是跨平臺的。可用於IOS和Android以及firefox的操作系統。
-
Selenium
Selenium 測試直接在瀏覽器中運行，就像真實用戶所做的一樣。Selenium 測試可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中運行。
-
Mock測試
Mock測試就是在測試過程中，對於某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創建以便測試的測試方法。這個虛擬的對象就是Mock對象，Mock對象就是真實對象在調試期間的代替品。Java中的Mock框架常用的有EasyMock和Mockito等。
-
消費者驅動契約測試
契約測試是一種針對外部服務的接口進行的測試，它能夠驗證服務是否滿足消費方期待的契約。當一些消費方通過接口使用某個組件的提供的行爲時，它們之間就產生了契約。這個契約包含了對輸入和輸出的數據結構的期望，性能以及併發性。而PACT是目前比較流的消費者驅動契約測試框架。
自動化運維工具
-
Ansible
-
Puppet
-
Chef
IT運維自動化是指將IT運維中日常的、大量的重複性工作自動化，把過去的手工執行轉爲自動化操作。自動化是IT運維工作的昇華，IT運維自動化不單純是一個維護過程，更是一個管理的提升過程，是IT運維的最高層次，也是未來的發展趨勢。下圖爲常用自動化運維工具對比：
監控管理工具
-
Zabbix
Zabbix是一個基於WEB界面的提供分佈式系統監視以及網絡監視功能的企業級開源解決方案。
-
ELK Stack日誌分析系統
ELK Stack是開源日誌處理平臺解決方案，背後的商業公司是Elastic。它由日誌採集解析工具 Logstash、基於 Lucene 的全文搜索引擎 Elasticsearch、分析可視化平臺 Kibana三部分組成。
-
雲監控（如Amazon CloudWatch）
Amazon CloudWatch 是一項針對 AWS 雲資源和在 AWS 上運行的應用程序進行監控的服務。您可以使用 Amazon CloudWatch 收集和跟蹤各項指標、收集和監控日誌文件、設置警報以及自動應對 AWS 資源的更改
備註: 根據自身系統實地的情況，文章做了相關調整.