什麼是DevOps呢？

先看一下wiki百科給出的定義：

DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

簡單地說，DevOps是一種開發、測試、運營、維護部門之間溝通、協作與整合的軟體過程、方法與系統。

DevOps是一種高度強調人與人間互動的工作方式，不能先入為主地認為參與者瞭解某方面技能，在完成高頻率部署的同時，提高生產環境的可靠穩定和安全行。

DevOps能夠為團隊提供一種極具凝聚力的文化氛圍，DevOps不光是一個方法理念，而且是一個有力的技術手段，人員、文化、流程與工具這幾大要素在DevOps中同樣重要。

為什麼DevOps姍姍來遲

DevOps 的概念在2009年就誕生了，但沒有相關的技術支援，只是出現在教科書和論文裡。然而，近年來所謂DevOps的最佳實踐逐漸越來越多，原因何在？

1. 雲服務的普遍使用，各種雲服務成為IT基礎設施中不可分隔的一部分。運維有一個很重要的概念就是Infrastructure as code。
2. 容器技術開始成熟，特別是Docker技術的大行其道。容器 Container是用來儲存和組織其他物件的物件。Docker是一個開源的應用容器引擎。
3. 微服務架構技術的廣泛使用。
   微服務 MicroService是指一個單純的小型有意義的功能。
   微服務，是支撐DevOps方法的手段，傳統開發是在一個伺服器裡面，把各種元素裝在一起組合成一個程式，但微服務是每一個服務是一個單獨的單元，可以部署在不同的伺服器上，通過SOA的方法，把它連線起來，再提供整個功能。
   微服務是由一個個團隊組成，每團隊有自己的服務，做好後，可以獨立的進行測試、開發、部署，然後整個應用組合到一起。張俠表示，開發運維一體化、微服務和Container是同等的，把它們組合起來，加上雲的手段才成為可能。

4.敏捷開發流程的深入人心。

諸如Scrum, Agile, Kanban等敏捷方式被團隊廣泛使用，TDD、BDD、DDD這些測試驅動設計、行為驅動設計、域驅動設計等設計方式的採納，CI和CD這些持續整合和持續部署等方式的實施，這些都是對DevOps的強烈需求。

DevOps中的技術棧與工具鏈

在全棧眼中，Everything is Code，所以DevOps 是通過技術工具鏈完成持續整合、持續交付、使用者反饋和系統優化的整合，實現跨團隊的無縫協作。

DevOps 中涉及的技術棧與工具鏈如下：

• DevOps 流程門戶： 這是統一操作的web網站，主要是進度看板，Sprint週期等。本著拿來主義，在一定條件下，可以採用類似Trello，worktile等工具代替。
• 身份及訪問管理： 使用者許可權管理的重要組成，可以採用RABC的方式實現，也可以與LDAP服務對接
• 產品管理： 產品的需求，定義，依賴，推廣等產品線的全面管理，confluence 可能是個不錯的選擇，禪道也可以滿足一部分的功能
• 配置管理： 提高產品的配置維護能力，zookeeper 大概是不二之選。
• 持續整合： 提供持續整合任務排程和執行的能力，Jenkins的用武之地，提供產品和元件自動編譯、打包和部署的能力，支援編譯和部署的流程編制，進度跟蹤和日誌檢視
• 環境管理： 提供資源配給和負載均衡的能力，需要配合雲服務的資源管理能力。初級的負載均衡可以選擇nginx或者Haproxy，生產環境的入口最好採用雲服務的SLB負載均衡，以便簡單地解決HA的問題。資源的排程採用雲的彈效能力，輔助指令碼實現。同時，微服務的容器化（docker）管理需要特別關注。
• 質量反饋： 提供產品的質量管理和監控能力，包括測試用例，缺陷跟蹤和質量監控。Jira 是個不錯的選擇，其他的開源工具例如禪道，bugzila，mantis等等，因團隊而異。
• 版本控制： 程式碼庫的建立和維護，分支管理等。Git 幾乎是行業的標準，可以自建Git倉庫的伺服器，也可以使用github 或者bitbucket這樣的第三方服務。
• 自動化測試： 包括客戶端與伺服器端的自動化測試框架，例如Appium，Selenium 以及各種Mock技術和xUnit
• 文件管理：各種開發、運維、部署文件的統一管理，同樣最好放到git上，同時指出文件的自動化生成
• 運營管理：這就是傳說中的OAM 中心，這是廣義的運營，其中還包括運維的部分。OAM 不但提供了業務系統的運營操作，還提供了面向運維的統一Monitor，alarm，fault handling等能力，以及產品的資源使用和執行狀況等，涉及的技術很多，儘量採用雲監控＋指令碼的方式，規模較小時可以嘗zZabbix 實現部分功能。
• 溝通管理： 敏捷的一個原則就是溝通優於文件，IM是團隊必備，微信和QQ可以滿足大部分的需求，但是Slack 因為其強大的web hook 功能顯得更加出色。

DevOps 的雙刃劍

DevOps 的成功與技術、流程和組織的全面支撐是密不可分的。技術棧和工具鏈只是DevOps的一個前提和基礎，技術方面的實踐相對容易，流程較難，組織變革最為艱難。DevOps還是以工程實踐為主，管理實踐這塊，像Scrum成體系的還比較少。DevOps玩得好，可以提高團隊的生產力。若是玩不好，可能還不如傳統的生產模式有效率。

狹義上看，DevOps主要困難點在於開發和運維是兩種完全不同性質的技術工作。很多開發的同事，看著運維人員整天就是玩幾個工具，寫幾個指令碼，覺得蠻簡單，實際上，很多東西要在生產環境下快速穩定應用，並沒有看上去那麼容易。生產系統少出問題（軟體本身bug除外）是運維的績效，多實現業務需求是開發的績效，這一少一多，體現了兩種技術角色的根本性區別。

業務部門壓力往往導致技術部門的任務主要是求“快”，在這種情況下，DevOps必然失衡，因為只追求快，就不需要ops了，只需要dev加班加點即可，不重視ops，結果必然是可悲的，往往業務上線後雞飛狗跳，各種問題不斷。在激烈競爭環境中，出幾次事故就可能對產品形象的傷害很大。

對全棧來說，業務初期到底要不要考慮高可用？從Dev角度看，簡潔明快的實現就行了，從Ops的角度看，高可用、監控、報表這些東西在業務正式上線前就是必須要考慮的。

因此，DevOps實施成功的關鍵，涉及到團隊管理，專案管理，技術管理等諸多方面。DevOps並非治病良藥，如果團隊正能量大，實施起來就相對容易，否則引入DevOps可能也無法改變什麼。對於一個全棧而言，DevOps是一柄必備的雙刃劍。