《DevOps的前世今生（3） DevOps的目標和手段》要點：
本文介紹了DevOps的前世今生（3） DevOps的目標和手段，希望對您有用。如果有疑問，可以聯系我們。

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

原文：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),而這些話題又相互交織在一起形成了四個不同的反饋環,如下圖所示.其中藍色氣泡代表技術,黃色氣泡代表過程管理：