DevOps轉(zhuǎn)型應(yīng)該怎么做

DevOps is everywhere，所有人都在說(shuō)在做。DevOps轉(zhuǎn)型的案例和故事很多，有些轉(zhuǎn)型成功了，但也許失敗的例子更多（雖然你沒(méi)有機(jī)會(huì)聽(tīng)到他們出來(lái)分享了）。不同組織面臨的情況和環(huán)境各不相同，其實(shí)很難簡(jiǎn)單的復(fù)制別人的成功。

我經(jīng)常喜歡舉的一個(gè)例子，學(xué)習(xí)DevOps有不同的方式，就像人類(lèi)學(xué)習(xí)飛行時(shí)有鳥(niǎo)飛派和空氣動(dòng)力學(xué)派。人類(lèi)的飛行夢(mèng)想始于古老而又遙遠(yuǎn)的年代，但真正的飛行實(shí)踐起源于仿鳥(niǎo)飛行，即給自己裝上一對(duì)翅膀，學(xué)習(xí)鳥(niǎo)的撲翼動(dòng)作而飛行，但大量長(zhǎng)期的實(shí)踐證明這樣的嘗試都是失敗的。但還有另外一派，英國(guó)的科學(xué)家提出人造飛行器應(yīng)該解決推進(jìn)動(dòng)力和升力等方面的問(wèn)題，需要增強(qiáng)對(duì)空氣動(dòng)力學(xué)理論體系的基本認(rèn)知，這使很多人放棄了單純模仿鳥(niǎo)類(lèi)飛行而逐漸接受和實(shí)踐固定翼飛行器的設(shè)計(jì)思路，并最終由萊特兄弟發(fā)明了完全受控、可持續(xù)飛行的載人飛行器。 

DevOps的實(shí)踐和轉(zhuǎn)型也是一樣，我們很難照搬其他組織的成功，而是應(yīng)該深入理解其背后的原理、原則和實(shí)踐，從正確的方向入手。本文主要內(nèi)容來(lái)自Jez Humble在Devon Summit上的演講《Leading a DevOps Transformation》，重點(diǎn)介紹了DevOps轉(zhuǎn)型的五個(gè)誤區(qū)、五個(gè)實(shí)踐，以及轉(zhuǎn)型實(shí)施的具體建議。因?yàn)槠^長(zhǎng)，我將會(huì)通過(guò)兩篇文章跟大家分享。另外，與之前的文章一樣，我會(huì)結(jié)合我的經(jīng)驗(yàn)和理解進(jìn)行適當(dāng)?shù)膬?nèi)容擴(kuò)展，而不僅限于演講內(nèi)容，核心還是希望幫助大家少走彎路、避免踩坑，能夠更順利的走向DevOps成功之路。 

另外再介紹一下Jez Humble，作為DevOps領(lǐng)域里公認(rèn)的世界級(jí)領(lǐng)軍人物，他既是一位非常有影響力的軟件研究人員，也是一位屢獲殊榮的作家。他與其他作者合著的《持續(xù)交付》(Continuous Delivery) 一書(shū)曾獲Jot大獎(jiǎng)，是學(xué)習(xí)DevOps的必讀書(shū)籍。Jez的其他暢銷(xiāo)書(shū)包括《精益企業(yè)》(LeanEnterprise)，以及DevOps Handbook，其中文譯本《DevOps實(shí)踐指南》將于5月5日在DevOpsDays北京站首發(fā)，大神Jez Humble也會(huì)來(lái)華與大家面對(duì)面暢談DevOps！ 

DevOps能夠幫助我們什么

傳統(tǒng)軟件交付方式的問(wèn)題大家都清楚，比如很長(zhǎng)的交付周期、很差的應(yīng)變能力和低效的價(jià)值交付。所有很多組織進(jìn)行了敏捷轉(zhuǎn)型，但敏捷轉(zhuǎn)型的歷程可能也并不是一帆風(fēng)順。以開(kāi)發(fā)為代表的工程師部門(mén)使用敏捷的方式運(yùn)作，從瀑布轉(zhuǎn)向了Scrum快速迭代，并引入了TDD，做好了架構(gòu)解耦，工作非常開(kāi)心。

但組織里的其他部門(mén)也許就不是這樣想的了。比如運(yùn)維團(tuán)隊(duì)，原來(lái)一年做好幾次發(fā)布就可以了，現(xiàn)在隨時(shí)有上線(xiàn)包扔過(guò)來(lái)，隨時(shí)都需要準(zhǔn)備發(fā)布，這個(gè)實(shí)在太可怕了。遇到這樣的問(wèn)題，很自然的反應(yīng)是建立起一個(gè)屏障，比如"變更管理流程"，而這個(gè)流程的職責(zé)就是限制變更。 

DevOps的出現(xiàn)就是為了解決這樣的問(wèn)題，可能很多人對(duì)DevOps的理解都不同，也可能并沒(méi)有一個(gè)統(tǒng)一的定義。但這并沒(méi)有關(guān)系，我們可以從DevOps的起源來(lái)思考。DevOps運(yùn)動(dòng)始于社區(qū)，一些人試圖解決某些從未被解決的問(wèn)題：如何構(gòu)建大規(guī)模、分布式、可靠、安全的系統(tǒng)，并且可以在持續(xù)、快速變更的情況下，讓系統(tǒng)一直保持安全和可靠。

在過(guò)去的五年時(shí)間中，通過(guò)對(duì)很多高效能企業(yè)的調(diào)研，可以發(fā)現(xiàn)投資于DevOps實(shí)踐所取得的眾多好處，首當(dāng)其沖的就是軟件交付會(huì)對(duì)業(yè)務(wù)發(fā)展產(chǎn)生重大的影響，高效能企業(yè)有兩倍于其他企業(yè)的概率達(dá)到其利潤(rùn)率、市場(chǎng)占有率、生產(chǎn)效率等業(yè)務(wù)目標(biāo)。

接下來(lái)，我們從統(tǒng)計(jì)學(xué)的角度來(lái)分析IT效能，這里設(shè)計(jì)了兩大類(lèi)四個(gè)指標(biāo)。分別是度量吞吐量的指標(biāo)（部署頻率、變更前置時(shí)間），以及度量穩(wěn)定性的指標(biāo)（MTTR、變更失敗率）。這些數(shù)據(jù)來(lái)自每年的DevOps現(xiàn)狀調(diào)查報(bào)告，我在去年也進(jìn)行過(guò)多次線(xiàn)上、線(xiàn)下解讀和分享，這里暫不展開(kāi)說(shuō)明。但值得再次強(qiáng)調(diào)的是，從統(tǒng)計(jì)結(jié)果上來(lái)看，高效能的企業(yè)可以在吞吐量和穩(wěn)定性方面兼得，而不是傳統(tǒng)意義上的為了提升效率而犧牲質(zhì)量，或者為了質(zhì)量而犧牲效率。

之前Facebook有句格言是"Move fast and break things"，意思是公司應(yīng)該快速行動(dòng)、打破陳規(guī)。但我覺(jué)得可以改成"Move fast and don't break things"，即快速交付的同時(shí)必須要確保質(zhì)量和安全性，這正是DevOps可以賦予給我們的能力。

DevOpsDays大會(huì)北京站報(bào)名通道

2018年5月5日，與大神Jez Humble面對(duì)面暢聊DevOps！ 

與大神見(jiàn)面并交流的機(jī)會(huì)難得，趕快掃碼報(bào)名！