《DevOps的前世今生（3） DevOps的目標(biāo)和手段》要點(diǎn)：
本文介紹了DevOps的前世今生（3） DevOps的目標(biāo)和手段，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

本文經(jīng)授權(quán)轉(zhuǎn)載簡(jiǎn)書(shū)作者：顧宇

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

前言

在#DevOps的前世今生# 2. Dev和Ops矛盾緣何而來(lái) ?一文中,通過(guò)Dev和Ops的歷史發(fā)展總結(jié)出了Dev和Ops矛盾的歷史淵源,以及 Dev 和 Ops 的核心矛盾：

Dev?和?Ops?的矛盾主要是面向適應(yīng)性的敏捷軟件交付和面向經(jīng)驗(yàn)性的傳統(tǒng)運(yùn)維之間的矛盾.

但這個(gè)矛盾最先?John Allspaw?和 Paul Hammond在 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” 提出,并以“Cooperation”作為整個(gè)演講的核心,講述了他們解決這個(gè)矛盾的實(shí)踐經(jīng)驗(yàn).這個(gè)演講中：

重新定義Ops的工作目標(biāo)

在一個(gè)組織中,如果相關(guān)利益者的利益不一致,在既定流程的進(jìn)行中一定會(huì)碰到諸多阻力.而在這一點(diǎn)上,首先做得就是把 Dev 和 Ops 的利益一致化,從而減少Ops對(duì)軟件交付的阻力.在演講中,John Allspaw 和 Paul Hammond 首先挑戰(zhàn)的是對(duì) Dev 和 Ops 的傳統(tǒng)觀點(diǎn).

傳統(tǒng)的觀點(diǎn)認(rèn)為Dev和Ops的工作是不同的：

Dev的工作是增添新的功能

Ops的工作是保證站點(diǎn)的穩(wěn)定和高性能

他們認(rèn)為,保證站點(diǎn)的穩(wěn)定和高性能不是 Ops 的工作目標(biāo).

Ops的工作目標(biāo)應(yīng)該是激活業(yè)務(wù)(enable the business ),而這一點(diǎn)和Dev是一致的.

理想往往是美好的,現(xiàn)實(shí)往往是殘酷的.激活業(yè)務(wù)會(huì)帶來(lái)更多的變更,而更多的變更會(huì)引起故障!

面對(duì)這樣的問(wèn)題,就需要做出一個(gè)選擇：為了保障穩(wěn)定性減少變更,還是及時(shí)按需變更?

阿拉伯有一個(gè)諺語(yǔ)：“你若不想做,會(huì)找到一個(gè)借口.你若想做,會(huì)找到一個(gè)方法.”

Flicker 并沒(méi)有屈服于壓力,他們選擇讓問(wèn)題向目標(biāo)妥協(xié),而不是目標(biāo)向問(wèn)題妥協(xié).他們的手段是：

構(gòu)建相互合作的工具和文化

降低變更風(fēng)險(xiǎn)的關(guān)鍵就是在于提高可靠性,這不僅僅是Dev在軟件開(kāi)發(fā)中,也需要Ops把可靠性通過(guò)非功能性需求(性能要求,擴(kuò)展性,安全性等)注入到軟件開(kāi)發(fā)過(guò)程中.通過(guò)系統(tǒng)交付過(guò)程中的質(zhì)量?jī)?nèi)建而不是事后檢驗(yàn)來(lái)提升交付質(zhì)量.

而 Dev 和 Ops 的具體矛盾點(diǎn)表現(xiàn)在以下兩方面：

在價(jià)值流下游的 Ops 評(píng)審認(rèn)為價(jià)值鏈上游的 Dev 軟件非功能質(zhì)量不滿足要求,因此阻止變更.

在價(jià)值流上游的 Dev 無(wú)法獲得價(jià)值鏈下游的 Ops 的真實(shí)運(yùn)行環(huán)境,因此無(wú)法提升交付質(zhì)量.

于是,逐漸陷入了“無(wú)法提升質(zhì)量”和“ 非功能質(zhì)量不滿足要求 ”的死循環(huán)中.

由于在 Dev 環(huán)節(jié)關(guān)心的是功能性需求,往往忽略了非功能性需求,而 Ops 更關(guān)注的是非功能性需求.所以通過(guò)質(zhì)量?jī)?nèi)建,把運(yùn)維加入開(kāi)發(fā)反饋環(huán).在開(kāi)發(fā)環(huán)節(jié)中增加非功能性的需求的實(shí)現(xiàn)和驗(yàn)收,讓 Ops 擔(dān)任最終的 QA 的角色.從而提升了交付質(zhì)量,也提升了反饋速度.

首先,他們通過(guò)基礎(chǔ)設(shè)施自動(dòng)化(Automated infrastructure )提升了基礎(chǔ)設(shè)施準(zhǔn)備的質(zhì)量和效率.

其次,他們搭建了Dev和Ops 交付的橋梁：共享版本控制(Shared Version Control )并且通過(guò)功能開(kāi)關(guān)(Feature flags )管理功能發(fā)布.

然后,通過(guò)一步構(gòu)建和部署(One step build and deploy )以及頻繁進(jìn)行小變更(Small frequent changes)提升單向價(jià)值流速度并降低部署風(fēng)險(xiǎn).

最后,采用共享運(yùn)維指標(biāo)(Shared metrics ),和即時(shí)消息工具集成(IRC and IM robots )提升溝通效率以做到及時(shí)反饋并進(jìn)行改進(jìn).

但僅僅有這些是不夠的,還需要構(gòu)建出合作的文化.合作的文化的構(gòu)建關(guān)鍵在 Dev 和 Ops 之間的尊敬,相互信任,以及面對(duì)失敗的改進(jìn)而非指責(zé)的態(tài)度.

第一屆 DevOpsDays 在繼承了這些思想的方向上則走的更遠(yuǎn).第一屆 DevOpsDays 吸引了更多關(guān)注于這一領(lǐng)域的人群,它們甚至都不具備技術(shù)背景.

DevOps的目標(biāo)——提升軟件交付的質(zhì)量?jī)?nèi)建以加速流程

在第一次 DevOpsDays 會(huì)議后,作為 DevOpsDays 活動(dòng)的發(fā)起人和 DevOps 這個(gè)詞的創(chuàng)始人,Patrick Debois 隨后總結(jié)并寫(xiě)下了“Charting out devops ideas”一文,他把第一屆 DevOpsDays 這也成為后續(xù) DevOps 運(yùn)動(dòng)的理念基石.在這篇文章里,Patrick從第一屆DevOps活動(dòng)中有了兩個(gè)重要的觀察,分別是：

1. DevOps 是在業(yè)務(wù)、交付流程和運(yùn)維之間反饋環(huán)中增加了一個(gè)反饋環(huán).

2. 因?yàn)橛辛诉@樣一個(gè)環(huán)節(jié),我們可以提升質(zhì)量以加速流程.

簡(jiǎn)而言之,DevOps 是把運(yùn)維(Ops)加入到了價(jià)值流的反饋環(huán)中.并且通過(guò)提升軟件交付的質(zhì)量?jī)?nèi)建以加速價(jià)值鏈端到端的反饋效率.

而要實(shí)現(xiàn)這一目標(biāo),要通過(guò)一些手段.

DevOps的手段——技術(shù)升級(jí)和流程管理

于此同時(shí),Patrick 發(fā)現(xiàn), DevOpsDays 的所有話題都圍繞著兩條主線：技術(shù)(technologies)和流程管理(process management),而這些話題又相互交織在一起形成了四個(gè)不同的反饋環(huán),如下圖所示.其中藍(lán)色氣泡代表技術(shù),黃色氣泡代表過(guò)程管理：