本文經授權轉載簡書作者：顧宇

原文：http://www.jianshu.com/p/c6573e63c752

前言

在#DevOps的前世今生# 2. Dev和Ops矛盾緣何而來 ？一文中，通過Dev和Ops的歷史發展總結出了Dev和Ops矛盾的歷史淵源，以及 Dev 和 Ops 的核心矛盾：

Dev 和 Ops 的矛盾主要是面向適應性的敏捷軟體交付和麵向經驗性的傳統運維之間的矛盾。

但這個矛盾最先 John Allspaw 和 Paul Hammond在 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” 提出，並以“Cooperation

重新定義Ops的工作目標

在一個組織中，如果相關利益者的利益不一致，在既定流程的進行中一定會碰到諸多阻力。而在這一點上，首先做得就是把 Dev 和 Ops 的利益一致化，從而減少Ops對軟體交付的阻力。在演講中，John Allspaw 和 Paul Hammond 首先挑戰的是對 Dev 和 Ops 的傳統觀點。

傳統的觀點認為Dev和Ops的工作是不同的：

Dev的工作是增添新的功能

Ops的工作是保證站點的穩定和高效能

他們認為，保證站點的穩定和高效能不是 Ops 的工作目標。

Ops的工作目標應該是啟用業務（enable the business ），而這一點和Dev是一致的。

理想往往是美好的，現實往往是殘酷的。啟用業務會帶來更多的變更，而更多的變更會引起故障！

面對這樣的問題，就需要做出一個選擇：為了保障穩定性減少變更，還是及時按需變更？

阿拉伯有一個諺語：“你若不想做，會找到一個藉口。你若想做，會找到一個方法。”

Flicker 並沒有屈服於壓力，他們選擇讓問題向目標妥協，而不是目標向問題妥協。他們的手段是：

構建相互合作的工具和文化

降低變更風險的關鍵就是在於提高可靠性，這不僅僅是Dev在軟體開發中，也需要Ops把可靠性通過非功能性需求（效能要求，擴充套件性，安全性等）注入到軟體開發過程中。通過系統交付過程中的質量內建而不是事後檢驗來提升交付質量。

而 Dev 和 Ops 的具體矛盾點表現在以下兩方面：

在價值流下游的 Ops 評審認為價值鏈上游的 Dev 軟體非功能質量不滿足要求，因此阻止變更。

在價值流上游的 Dev 無法獲得價值鏈下游的 Ops 的真實執行環境，因此無法提升交付質量。

於是，逐漸陷入了“無法提升質量”和“ 非功能質量不滿足要求 ”的死迴圈中。

由於在 Dev 環節關心的是功能性需求，往往忽略了非功能性需求，而 Ops 更關注的是非功能性需求。所以通過質量內建，把運維加入開發反饋環。在開發環節中增加非功能性的需求的實現和驗收，讓 Ops 擔任最終的 QA 的角色。從而提升了交付質量，也提升了反饋速度。

首先，他們通過基礎設施自動化（Automated infrastructure ）提升了基礎設施準備的質量和效率。

其次，他們搭建了Dev和Ops 交付的橋樑：共享版本控制（Shared Version Control ）並且通過功能開關（Feature flags ）管理功能釋出。

然後，通過一步構建和部署（One step build and deploy ）以及頻繁進行小變更（Small frequent changes）提升單向價值流速度並降低部署風險。

最後，採用共享運維指標（Shared metrics ），和即時訊息工具整合（IRC and IM robots ）提升溝通效率以做到及時反饋並進行改進。

但僅僅有這些是不夠的，還需要構建出合作的文化。合作的文化的構建關鍵在 Dev 和 Ops 之間的尊敬，相互信任，以及面對失敗的改進而非指責的態度。

第一屆 DevOpsDays 在繼承了這些思想的方向上則走的更遠。第一屆 DevOpsDays 吸引了更多關注於這一領域的人群，它們甚至都不具備技術背景。

DevOps的目標——提升軟體交付的質量內建以加速流程

在第一次 DevOpsDays 會議後，作為 DevOpsDays 活動的發起人和 DevOps 這個詞的創始人，Patrick Debois 隨後總結並寫下了“Charting out devops ideas”一文，他把第一屆 DevOpsDays 這也成為後續 DevOps 運動的理念基石。在這篇文章裡，Patrick從第一屆DevOps活動中有了兩個重要的觀察，分別是：

1. DevOps 是在業務、交付流程和運維之間反饋環中增加了一個反饋環。

2. 因為有了這樣一個環節，我們可以提升質量以加速流程。

簡而言之，DevOps 是把運維（Ops）加入到了價值流的反饋環中。並且通過提升軟體交付的質量內建以加速價值鏈端到端的反饋效率。

而要實現這一目標，要通過一些手段。

DevOps的手段——技術升級和流程管理

於此同時，Patrick 發現， DevOpsDays 的所有話題都圍繞著兩條主線：技術（technologies）和流程管理（process management），而這些話題又相互交織在一起形成了四個不同的反饋環，如下圖所示。其中藍色氣泡代表技術，黃色氣泡代表過程管理：

開發-測試反饋環（黑色箭頭反饋環）：

技術方面：

由非功能特性(擴充套件性，可用性)驅動的軟體架構：用NO-SQL資料庫或佇列系統（Queue System）增加系統的可擴充套件性，以及混合使用程式語言和memcache這樣的快取系統。

過程管理方面：

拉近軟體開發和系統工程的互動：採用敏捷團隊或者其它形式的多功能團隊跨越不同的部門牆。

開發-運維反饋環（綠色箭頭反饋環）：

技術方面：

系統管理員採用軟體開發技術：使用程式碼倉庫、持續整合、測試工具、設計模式來自動化的處理系統的初始化操作。

部署的配置管理：採用配置管理以及自動化配置工具（Chef，Puppet）用於部署和生產環境的變更。

測試和監控相互輔助：在監控系統中複用自動化測試邏輯（比如：cucumber-nagios），在測試環境中使用監控手段驗證測試場景。

運維團隊開發新的系統管理工具：工具也是技術水平差距的重要體現，很多系統管理員開發新的工具用來處理大規模的部署，變更以及監控。

過程管理方面：

拉近軟體開發和系統工程的互動：敏捷專案或者其他形成多功能團隊的方法替代不同的部門牆。

專案從運維中學習：架構在專案中不斷獲得反饋，從而知道哪些可以用，哪些不能用。這樣可以得到更好的架構設計。

業務-運維反饋環（紅色箭頭反饋環）：

技術方面：

基於雲端計算和敏捷基礎設施的新系統架構：雲端計算和敏捷的基礎設施可以獲得更好和更先進的自動化部署手段和系統初始化手段。

過程管理方面：

業務部門應當同時關注功能和非功能需求：業務應當開始關注停機時間和資料丟失帶來的影響。

運維團隊參與過程上游而不是被動的角色：在運維中採用看板在專案階段進行互動，甚至可以用在專案前的階段（銷售、服務水平管理）。

運維團隊自組織以應對業務挑戰：例如把敏捷引入運維(agile operations)或把精益引入運維(lean operations)。

業務使用運維指標作為反饋：要了解使用者喜歡什麼，如何行動。為了做出更好的業務決策，效能降低或故障中斷正在成為一個重要的反饋迴路。

業務-使用者反饋環（紫色箭頭反饋環）：

過程管理方面：

運維作為使用者問題的第一個響應人：運維人員和銷售人員一樣，都可以作為處理使用者的問題的一線，並反饋給業務部門。

通過以上四個反饋環我們發現兩個關鍵點：

1. DevOps 不僅僅是IT部門的事情，他涉及到IT部門以外的部門，包括終端使用者。在脫離像 Flicker 這樣的網際網路公司這個大背景下。企業級IT部門採用 DevOps 還會遇到更多外部挑戰。

2. 新的技術，尤其敏捷軟體開發觀念的深入和大規模基礎設施（虛擬化，雲端計算，SDN）的不斷髮展讓 Ops 以 Dev 的方式工作成為可能。

總結

第一屆DevOpsDays秉承著Velocity 09中 “Dev and Ops Cooperation”的理念彙集了世界上所有關注於解決 Dev和 Ops 矛盾的有志之士。然而，通過大家的交流，發現軟體交付的問題並不僅僅是 Dev 和Ops合作那麼簡單，通過文章我們發現：

DevOps 本質是一場以提升質量內建為手段，以加速軟體系統價值流反饋為目標的技術提升和管理變革。

但是，DevOps 運動後續的發展卻並不順利：

一方面，由於 DevOps 這個很短的單詞中包含了太多的概念，又缺乏足夠的限定，使得 DevOps 的概念很模糊。讓不同的人對於 DevOps 的理解千差萬別。

另一方面， 來自傳統運維對 DevOps 的批評也讓這種基於社群（集市）而非基於專業性組織（大教堂）產生了質疑。由於缺乏系統化的方法論，使得更多的企業在實踐 DevOps 中處於觀望或低水平的軟體工具升級階段。

然而，DevOps 的實踐者們仍然在不斷總結和完善。使得 DevOps 的文化價值體系漸漸成型，使得大家能夠更好的理解和實踐 DevOps。請期待下篇#DevOps的前世今生# 4. DevOps的文化和原則

感謝ThoughtWorks 高階諮詢師 馬博文，伍斌，黃博文給本文提出的寶貴意見。

參考連結：