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

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

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

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

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

DevOps能夠幫助我們什么

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

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

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

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

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

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

DevOpsDays大會北京站報名通道

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

與大神見面并交流的機(jī)會難得，趕快掃碼報名！