▌背景

我經(jīng)常喜歡舉的一個(gè)例子，學(xué)習(xí)DevOps有不同的方式，就像人類學(xué)習(xí)飛行時(shí)有鳥飛派和空氣動(dòng)力學(xué)派。人類的飛行夢(mèng)想始于古老而又遙遠(yuǎn)的年代，但真正的飛行實(shí)踐起源于仿鳥飛行，即給自己裝上一對(duì)翅膀，學(xué)習(xí)鳥的撲翼動(dòng)作而飛行，但大量長(zhǎng)期的實(shí)踐證明這樣的嘗試都是失敗的。但還有另外一派，英國(guó)的科學(xué)家提出人造飛行器應(yīng)該解決推進(jìn)動(dòng)力和升力等方面的問(wèn)題，需要增強(qiáng)對(duì)空氣動(dòng)力學(xué)理論體系的基本認(rèn)知，這使很多人放棄了單純模仿鳥類飛行而逐漸接受和實(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í)施的具體建議。與之前的文章一樣，我會(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) 一書曾獲Jot大獎(jiǎng)，是學(xué)習(xí)DevOps的必讀書籍。Jez的其他暢銷書包括《精益企業(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)順。以開發(fā)為代表的工程師部門使用敏捷的方式運(yùn)作，從瀑布轉(zhuǎn)向了Scrum快速迭代，并引入了TDD，做好了架構(gòu)解耦，工作非常開心。

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

DevOps的出現(xiàn)就是為了解決這樣的問(wèn)題，可能很多人對(duì)DevOps的理解都不同，也可能并沒有一個(gè)統(tǒng)一的定義。但這并沒有關(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ì)了兩大類四個(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ò)多次線上、線下解讀和分享，這里暫不展開說(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ī)。但我覺得可以改成”Move fast and don’t break things“，即快速交付的同時(shí)必須要確保質(zhì)量和安全性，這正是DevOps可以賦予給我們的能力。

▌DevOps轉(zhuǎn)型的五個(gè)誤區(qū)

Jez Humble提出了DevOps轉(zhuǎn)型的五個(gè)誤區(qū)：

下面我們來(lái)詳細(xì)分析一下：

1 ▏誤區(qū)一：放棄現(xiàn)有的系統(tǒng)管理員、測(cè)試人員，招聘新的DevOps專家

不得不說(shuō)，這絕對(duì)是一個(gè)糟糕的想法，建議不要這樣做。從經(jīng)驗(yàn)來(lái)看，招聘新的DevOps專家是一件很困難的事情，我身邊的一些朋友都在尋找這樣的人才，但其實(shí)很難找到完美的人選。因?yàn)镈evOps工程師或?qū)＜也皇侵苯幽軌蚺嘤?xùn)出來(lái)的，也沒有一所大學(xué)教授DevOps的課程，這些有經(jīng)驗(yàn)的人都是在工作中不斷遇到和解決問(wèn)題的過(guò)程中逐漸成長(zhǎng)起來(lái)的。

所以問(wèn)題的關(guān)鍵在于，如何建立一個(gè)組織環(huán)境，讓員工可以在工作中學(xué)習(xí)，他們不會(huì)被刻意地限制在各自的角色中，而是被鼓勵(lì)在解決問(wèn)題的過(guò)程中不斷學(xué)習(xí)新技能，并為整個(gè)組織服務(wù)。

2 ▏誤區(qū)二：進(jìn)行大規(guī)模組織結(jié)構(gòu)重組（Re-Org）

有的組織轉(zhuǎn)型很干脆，一上來(lái)就進(jìn)行大規(guī)模的組織結(jié)構(gòu)重組。但經(jīng)驗(yàn)告訴我們，組織結(jié)構(gòu)重組是非常容易引起混亂的活動(dòng)，組織通常會(huì)消耗數(shù)月時(shí)間和巨大的能量，員工需要重新熟悉新的組織結(jié)構(gòu)和工作方式，這對(duì)組織生產(chǎn)力的打擊是非常大的。

值得注意的是，我們并不是說(shuō)不需要對(duì)組織進(jìn)行改進(jìn)。我們都知道，跨職能團(tuán)隊(duì)（比如面向服務(wù)或特性）會(huì)比按職能切分的團(tuán)隊(duì)具有更高的生產(chǎn)力，所以建立跨職能團(tuán)隊(duì)本身是非常有效的。但這里觀點(diǎn)是Re-Org并不是唯一的選擇。我們也可以用其他方式達(dá)到這個(gè)目標(biāo)，比如讓這些不同角色的人員物理地聚在一起；或者下游職能團(tuán)隊(duì)通過(guò)自動(dòng)化的自服務(wù)平臺(tái)，把他們的能力賦予給上游的團(tuán)隊(duì)使用（見下圖）。很多讓人敬佩的DevOps組織也沒有完全形成跨職能團(tuán)隊(duì)（如Etsy，Google和GitHub），但他們的生產(chǎn)率同樣非常高。

3 ▏誤區(qū)三：重新編寫你的應(yīng)用并遷移到云上

DevOps現(xiàn)狀調(diào)查報(bào)告中也顯示，DevOps適用于各種場(chǎng)景，包括Mainframe主機(jī)系統(tǒng)和商業(yè)套裝軟件（COTS）。

在我的上一篇文章 DevOps聽起來(lái)不錯(cuò)，但適合你的企業(yè)么 ，我講到了在大型嵌入式軟件、保險(xiǎn)公司的大型機(jī)系統(tǒng)上進(jìn)行持續(xù)交付的案例。除此之外，在《DevOps Handbook》中也提到在傳統(tǒng)的POS機(jī)上，采用藍(lán)綠部署進(jìn)行快速和低風(fēng)險(xiǎn)發(fā)布的例子。

所以，你不用等待漫長(zhǎng)的應(yīng)用重建并遷移到云上，而是可以在現(xiàn)有系統(tǒng)和組織環(huán)境中使用DevOps的思路進(jìn)行逐步改進(jìn)，最好的轉(zhuǎn)型啟動(dòng)時(shí)間點(diǎn)就是現(xiàn)在！

4 ▏誤區(qū)四：購(gòu)買一攬子DevOps工具

DevOps發(fā)展到今天，已經(jīng)出現(xiàn)了非常多的支撐工具。我們認(rèn)可好的工具可以對(duì)DevOps的實(shí)施提供出非常強(qiáng)有力的支持，但我們的觀點(diǎn)是：如果僅僅是購(gòu)買工具，無(wú)法真正幫助你解決問(wèn)題。

Jez Humble與Dave Farley在2005~2006年進(jìn)行持續(xù)交付的工作時(shí)，并沒有上圖中展示的如此眾多的工具，很多自動(dòng)化的工作都是由Bash腳本完成的，但也同樣獲得了非常顯著的效果。問(wèn)題的關(guān)鍵在于你如何解決問(wèn)題，而不是具體應(yīng)用哪一款的工具。如果組織僅僅是購(gòu)買工具而不改變工作流程，這樣不會(huì)改變?nèi)魏问虑椤?/p>

我就曾經(jīng)見過(guò)有人把Jira用成了管控型的傳統(tǒng)項(xiàng)目管理工具，把Jenkins用成了批處理任務(wù)的手動(dòng)觸發(fā)器，只有工具而沒有方法和實(shí)踐的改變，是無(wú)法走上DevOps成功之路的。

5 ▏誤區(qū)五：給開發(fā)生產(chǎn)環(huán)境的完全訪問(wèn)權(quán)限

有人說(shuō)DevOps就是讓開發(fā)自己進(jìn)行發(fā)布，所以需要給開發(fā)所有生產(chǎn)環(huán)境的權(quán)限。我們認(rèn)為這是一種可怕的想法。理想情況下，任何人都不應(yīng)該有生產(chǎn)環(huán)境的權(quán)限，所有生產(chǎn)環(huán)境的部署應(yīng)該由人工觸發(fā)后，只通過(guò)自動(dòng)化的方式進(jìn)行。

只有在特殊的場(chǎng)景下，比如需要在生產(chǎn)環(huán)境進(jìn)行診斷時(shí)，才可以允許有人登陸到生產(chǎn)環(huán)境。但這種情況下仍然需要特別小心，比如使用一次性的登陸口令，并將任何操作日志都記錄下來(lái)并發(fā)送給系統(tǒng)管理員。

▌DevOps轉(zhuǎn)型的五個(gè)實(shí)踐

以上介紹了DevOps轉(zhuǎn)型的五個(gè)誤區(qū)，那么正確的轉(zhuǎn)型打開方式是怎樣的呢？我們總結(jié)為以下五個(gè)實(shí)踐。

1 ▏實(shí)踐一：習(xí)慣小批量的方式工作（開發(fā)、架構(gòu)、組織文化的演進(jìn)）

持久的變革需要以小批量、持續(xù)的方式進(jìn)行，通過(guò)反復(fù)實(shí)驗(yàn)、根據(jù)反饋循環(huán)快速學(xué)習(xí)，找到最正確的實(shí)施路徑。這樣需要把大的問(wèn)題拆成一系列小的問(wèn)題逐個(gè)、漸進(jìn)式解決，也許這樣沒有Big Bang式的變革令人激動(dòng)，但這才是讓我們成功的正確姿勢(shì)。

找到最重要的工作

最經(jīng)典的例子就是項(xiàng)目管理，傳統(tǒng)上按半年或一年規(guī)劃并申請(qǐng)預(yù)算，這驅(qū)使我們工作在大型復(fù)雜項(xiàng)目上，大量時(shí)間花在特性在待辦清單（Backlog）中等待被分析、估算、批準(zhǔn)和排優(yōu)先級(jí)等事務(wù)性工作上。一份稱為”黑天鵝農(nóng)場(chǎng)”的白皮書顯示，他們分析了3000個(gè)待辦清單中等待開發(fā)的不同需求，使用延遲成本（如果不做這個(gè)需求，每周損失的成本）的優(yōu)先級(jí)決策方式。

他們發(fā)現(xiàn)，在待辦清單中有三個(gè)特性，如果不交付這些特性，每個(gè)特性每周給組織帶來(lái)200萬(wàn)美金的損失。這幾個(gè)特性隱藏在龐大的待辦清單中，但確實(shí)極為關(guān)鍵的。他們意識(shí)到應(yīng)當(dāng)停掉手頭所有工作，以最快的速度交付這三個(gè)特性。從統(tǒng)計(jì)數(shù)據(jù)上看，這種情況符合冪律分布，如下圖所示。

所以我們的工作就是要在多個(gè)項(xiàng)目中間，找到那些真正重要的，這需要更加透明、更加清晰的優(yōu)先級(jí)，以及組織中每個(gè)人的協(xié)作。

架構(gòu)的持續(xù)演進(jìn)

很普遍的情況是，很多組織擁有大量的遺留系統(tǒng)，一些軟件或硬件過(guò)于老舊，可能廠商已經(jīng)不再支持了，有些組織的個(gè)別系統(tǒng)甚至沒有源代碼（可能在乙方手中或已丟失）。這類組織通常選擇通過(guò)長(zhǎng)達(dá)一兩年的架構(gòu)再造解決問(wèn)題，而當(dāng)進(jìn)行到一年的時(shí)候，他們可能會(huì)說(shuō)，系統(tǒng)復(fù)雜度實(shí)在太高，我們還需要額外的兩年！我本人就親歷過(guò)這樣的超大型項(xiàng)目，最后負(fù)責(zé)的CTO都換人了，項(xiàng)目還沒做完。

以上描述的場(chǎng)景，關(guān)鍵的問(wèn)題是，大家的關(guān)注點(diǎn)常常在架構(gòu)的技術(shù)層面而不是需要達(dá)到的結(jié)果上。調(diào)查數(shù)據(jù)顯示，如果以下問(wèn)題的回答都是Yes，那么你更有可能做好持續(xù)交付和DevOps，成為高效能IT組織：

是否無(wú)需團(tuán)隊(duì)外的某人或其他團(tuán)隊(duì)授權(quán)就可以進(jìn)行自身系統(tǒng)大范圍的設(shè)計(jì)變更？

是否無(wú)需與團(tuán)隊(duì)外的其他人員進(jìn)行細(xì)粒度的溝通就可以完成自身的工作？

是否可以獨(dú)立于其他依賴的服務(wù)或產(chǎn)品，按需部署和發(fā)布自身的產(chǎn)品或服務(wù)？

是否無(wú)需依賴復(fù)雜的集成測(cè)試環(huán)境，就可以按需進(jìn)行大多數(shù)自身系統(tǒng)的測(cè)試？

是否可以在日常業(yè)務(wù)時(shí)段，執(zhí)行無(wú)停機(jī)的部署？

你可以在老舊的遺留系統(tǒng)上實(shí)現(xiàn)以上全部這些效果，但也可能在充滿高科技、新技術(shù)的情況下，無(wú)法達(dá)到以上效果的任意一條。所以我們要關(guān)注的是架構(gòu)演進(jìn)的結(jié)果，而不僅僅是使用炫酷的技術(shù)。

關(guān)于演進(jìn)式架構(gòu)的更多內(nèi)容，以及絞殺者模式的思路，我之前的文章也有介紹，其主要原則如下：

從交付業(yè)務(wù)所需的新功能開始（至少在初期是這樣），新功能使用面向服務(wù)的設(shè)計(jì)

不要重寫已有的功能，除非能夠使它持續(xù)簡(jiǎn)化

通過(guò)不斷拆分，更快的進(jìn)行交付

為可測(cè)試性和可部署性進(jìn)行設(shè)計(jì)

新的架構(gòu)運(yùn)行在PaaS平臺(tái)上

組織文化的持續(xù)演進(jìn)

組織和文化的變革同樣應(yīng)用使用持續(xù)演進(jìn)的方式。在組織中有各種各樣的員工，有些人對(duì)新方法和新技術(shù)非常感興趣，有些人則偏于保守，不愿意嘗試進(jìn)行改變。

你不能一刀切地進(jìn)行整個(gè)組織的變革，應(yīng)該從最贊同DevOps的理念、方法和技術(shù)的人群開始。接受一個(gè)新想法，需要跨越鴻溝。我們先找到認(rèn)同DevOps原則和實(shí)踐的團(tuán)隊(duì)，聚焦在有一定風(fēng)險(xiǎn)承受能力的小組上，快速做出轉(zhuǎn)型的標(biāo)桿效果，打好基礎(chǔ)、給人信心。我們不需要在早期花費(fèi)大量時(shí)間用于轉(zhuǎn)化保守的人群，而最重要的是先要把第一槍打響。

2 ▏實(shí)踐二：創(chuàng)建反饋循環(huán)

在小批量工作的基礎(chǔ)上，我們要建立起反饋循環(huán)。反饋循環(huán)讓我們能夠持續(xù)學(xué)習(xí)，基于學(xué)習(xí)進(jìn)行持續(xù)改進(jìn)，這也是敏捷和學(xué)習(xí)型組織的關(guān)鍵原則。

持續(xù)交付流水線就是反饋循環(huán)的具體實(shí)現(xiàn)，可以提供多個(gè)層次、多個(gè)鏈路的反饋信息，并且可以在反饋效率和反饋完整性之間取得平衡。

以下是去年我與朋友合作的全開源持續(xù)交付流水線的設(shè)計(jì)圖和效果圖，充分體現(xiàn)了流水線的遞次晉級(jí)和反饋循環(huán)的原則。

全開源流水線只能滿足中小企業(yè)的需求，在大型企業(yè)中的流水線設(shè)計(jì)和實(shí)現(xiàn)更為復(fù)雜，我后面找時(shí)間再跟大家單獨(dú)介紹。

3 ▏實(shí)踐三：通過(guò)價(jià)值流進(jìn)行跨職能協(xié)作

需求、開發(fā)、測(cè)試、信息安全、運(yùn)維等角色需要在軟件交付價(jià)值流中協(xié)同工作。價(jià)值流圖是促進(jìn)跨職能協(xié)作的關(guān)鍵工具。我們可以通過(guò)開展價(jià)值流梳理的Workshop，識(shí)別支撐價(jià)值流的各種角色以及角色之間的協(xié)作關(guān)系。我們不需要文檔化價(jià)值流中每一步的細(xì)枝末節(jié)，而是理解價(jià)值是如何傳遞的，各角色是如何協(xié)同工作的。

另外，這里還要強(qiáng)調(diào)跨職能協(xié)作時(shí)的質(zhì)量管控部分。不僅僅是自動(dòng)化測(cè)試，還要關(guān)注持續(xù)測(cè)試、持續(xù)安全檢查，讓這些活動(dòng)在日常工作中反復(fù)進(jìn)行，做到內(nèi)建質(zhì)量。

4 ▏實(shí)踐四：建立實(shí)驗(yàn)的組織文化

調(diào)查表明，組織文化是可以被度量的，而且組織文化對(duì)IT效能和組織績(jī)效都有可度量的影響。我們使用Westrum模型來(lái)度量組織文化。該模型中有三種類型：

病態(tài)型組織（Pathological）的特征是存在大量恐懼和威脅。人們通常處于政治因素而隱藏或者壓制信息，甚至為了讓自己表面上看起來(lái)更好而扭曲事實(shí)。

官僚型組織（Bureaucratic）的特征是各部門自保。每個(gè)部門都想維護(hù)自己的一畝三分地兒，堅(jiān)持自己的規(guī)則，通常會(huì)依照自己的章程按部就班地行事。

生機(jī)型組織（Generative）專注于自身的使命以及如何達(dá)到目標(biāo)。任何因素都要讓位于高績(jī)效，團(tuán)隊(duì)間高度合作、風(fēng)險(xiǎn)共擔(dān)、鼓勵(lì)聯(lián)結(jié)。面對(duì)失敗時(shí)需要嘗試發(fā)現(xiàn)系統(tǒng)中的問(wèn)題根因，而不是尋找替罪羊或相互推諉。

根據(jù)統(tǒng)計(jì)結(jié)果發(fā)現(xiàn)，一個(gè)高度信任的生機(jī)型文化不僅對(duì)創(chuàng)造一個(gè)安全的工作環(huán)境非常重要，更是打造高績(jī)效組織的基礎(chǔ)。

以上模型不僅停留在理論層面，更可以應(yīng)用在實(shí)踐領(lǐng)域。

1 ▏案例一. Google的災(zāi)難恢復(fù)測(cè)試

Google在幾年之前進(jìn)行過(guò)一項(xiàng)研究，如何打造一個(gè)優(yōu)秀的團(tuán)隊(duì)。他們調(diào)研了來(lái)自180個(gè)Google團(tuán)隊(duì)的200位受訪者，觀察了超過(guò)250項(xiàng)不同的因素，比如團(tuán)隊(duì)中有人取得博士學(xué)位、有性格外向的人，有人著迷于AngularJS等等。但他們最終發(fā)現(xiàn)打造高效能IT組織，排在第一位的因素是：心理上的安全感，即可以在團(tuán)隊(duì)中承擔(dān)風(fēng)險(xiǎn)而不會(huì)感到不安全或者受到傷害。

我們需要構(gòu)建一個(gè)安全的環(huán)境，讓失敗是可以接受的，并且作為組織學(xué)習(xí)的基礎(chǔ)。Google和Amazon都會(huì)在線上進(jìn)行災(zāi)難恢復(fù)測(cè)試，確保在發(fā)生嚴(yán)重故障時(shí)，故障恢復(fù)策略真正有效，系統(tǒng)仍然可以正常運(yùn)轉(zhuǎn)。

Google有一整個(gè)團(tuán)隊(duì)專注于計(jì)劃和實(shí)施災(zāi)難恢復(fù)測(cè)試，甚至有一年模擬外星人侵入硅谷的場(chǎng)景，他們斷開山景城與外界的光纜連接、關(guān)閉數(shù)據(jù)中心并對(duì)基礎(chǔ)設(shè)施施加真實(shí)的影響，但要求團(tuán)隊(duì)必須要維護(hù)服務(wù)級(jí)別目標(biāo)。他們?cè)O(shè)計(jì)的災(zāi)難恢復(fù)測(cè)試，需要由來(lái)自很多不同組、平時(shí)不在一起工作的工程師相互協(xié)作，那么在大規(guī)模災(zāi)難真正來(lái)臨的時(shí)候，他們已經(jīng)建立起了很強(qiáng)的工作關(guān)系。

2 ▏案例二. Etsy的”三只袖毛衣”獎(jiǎng)勵(lì)

Etsy每年舉辦開發(fā)者大會(huì)，會(huì)發(fā)給過(guò)去一年中生產(chǎn)環(huán)境最大中斷的制造者一件”三只袖毛衣”作為獎(jiǎng)勵(lì)。那么為什么獎(jiǎng)勵(lì)是三只袖毛衣呢？因?yàn)镋tsy的404頁(yè)面中有一張三只袖毛衣的圖片。

圖中這位身穿毛衣的同學(xué)就是Etsy去年最大故障的制造者Ryn，她把故障的過(guò)程記錄在了博客中，包括何時(shí)、什么原因造成了生產(chǎn)環(huán)境中斷。發(fā)生故障時(shí)，她馬上在Slack上尋求幫助，然后立即得到了身邊很多人的回復(fù)，然后他們一起蜂擁而上快速解決了問(wèn)題。之后，他們開展了免責(zé)的事后故障分析會(huì)議，并給出了防止再次失敗、優(yōu)化系統(tǒng)的具體措施。Ryn也因此獲得去年的獎(jiǎng)勵(lì)，因?yàn)樗龠M(jìn)了組織學(xué)習(xí)，讓系統(tǒng)的恢復(fù)能力變得更強(qiáng)。

3 ▏案例三. Netflix的Chaos Monkey和Simian Army

Netflix的這個(gè)工具不斷在生產(chǎn)環(huán)境上制造破壞，驗(yàn)證系統(tǒng)是否具備良好的恢復(fù)能力，并幫助工程師構(gòu)建更加健壯的系統(tǒng)。

4 ▏實(shí)踐四：持續(xù)消除浪費(fèi)，優(yōu)化價(jià)值流

DevOps需要持續(xù)改進(jìn)，移除浪費(fèi)，讓價(jià)值流動(dòng)變得更加順暢。我近期輔導(dǎo)了一些團(tuán)隊(duì)使用價(jià)值流圖的方式進(jìn)行流程和問(wèn)題梳理，發(fā)現(xiàn)這的確對(duì)組織認(rèn)知和優(yōu)化現(xiàn)有軟件交付過(guò)程非常有幫助。

我們可以邀請(qǐng)來(lái)自產(chǎn)品、開發(fā)、測(cè)試、運(yùn)維、安全等不同部門的Leader參加價(jià)值流梳理活動(dòng)，其實(shí)最難的部分是讓這些人在同一時(shí)間聚在一間會(huì)議室中。我們逐個(gè)梳理從需求提出到編碼、測(cè)試驗(yàn)證再到部署、發(fā)布的過(guò)程，過(guò)程中會(huì)發(fā)現(xiàn)大家的認(rèn)知并不一致，尤其是對(duì)前置時(shí)間、等待時(shí)間和C/A%（完整且準(zhǔn)確比例）的估算。

讓所有人達(dá)成對(duì)整個(gè)價(jià)值流的理解和認(rèn)知非常重要，但更重要的是確定未來(lái)如何改進(jìn)的具體措施和預(yù)期目標(biāo)。在不同的角色對(duì)目標(biāo)達(dá)成一致意見的基礎(chǔ)上，定期（如一個(gè)月）進(jìn)行回顧和持續(xù)的改進(jìn)。在改進(jìn)的過(guò)程中，并不是事無(wú)巨細(xì)的告訴團(tuán)隊(duì)具體如何開展工作，而是明確目標(biāo)并讓團(tuán)隊(duì)深度參與、自主思考，通過(guò)不斷實(shí)驗(yàn)和學(xué)習(xí)想辦法達(dá)到目標(biāo)。（這映射了我們之前提到的誤區(qū)一）

▌DevOps轉(zhuǎn)型實(shí)施的具體建議

在過(guò)去五年對(duì)高效能企業(yè)的研究中，總結(jié)出了DevOps轉(zhuǎn)型的關(guān)鍵能力要素，如下圖所示。圖中共有四大領(lǐng)域，分別是軟件開發(fā)實(shí)踐、精益產(chǎn)品開發(fā)、精益管理、變革領(lǐng)導(dǎo)力，這些領(lǐng)域又細(xì)化出了20多個(gè)能力項(xiàng)。這些能力項(xiàng)的建設(shè)可以作為DevOps轉(zhuǎn)型實(shí)施的主要參照系，強(qiáng)烈推薦大家持續(xù)關(guān)注。

DevOps的轉(zhuǎn)型并不簡(jiǎn)單，想要走上成功之路，這里還有幾個(gè)Tips：

對(duì)可度量的業(yè)務(wù)目標(biāo)達(dá)成一致。制定”跳一跳可以達(dá)到”的目標(biāo)，比如減少10%嚴(yán)重缺陷數(shù)、提升20%服務(wù)可用時(shí)長(zhǎng)、達(dá)到2倍的發(fā)布頻率，或者其他混合的結(jié)果指標(biāo)。

給團(tuán)隊(duì)資源進(jìn)行實(shí)驗(yàn)并對(duì)學(xué)習(xí)進(jìn)行激勵(lì)。團(tuán)隊(duì)無(wú)法在日常工作照舊的前提下，”加班”進(jìn)行改進(jìn)的探索。改進(jìn)是要有真實(shí)工作量投入的，這應(yīng)當(dāng)與開發(fā)新功能、修復(fù)缺陷以同樣的方式進(jìn)行優(yōu)先級(jí)排序。具體來(lái)講，可以使用看板管理WIP，指派專職的團(tuán)隊(duì)全職做改進(jìn)工作，或者每周給團(tuán)隊(duì)一個(gè)特定時(shí)間用于做改進(jìn)工作。

與其他團(tuán)隊(duì)溝通，鼓勵(lì)協(xié)作。很多人經(jīng)常提及合規(guī)、安全、治理等團(tuán)隊(duì)，認(rèn)為他們是改進(jìn)的阻礙。但其實(shí)如果與這些團(tuán)隊(duì)進(jìn)行友好的溝通，你可能會(huì)發(fā)現(xiàn)他們非常期望討論獲得雙贏的具體措施。

取得速贏。你需要在一到兩個(gè)月做出改進(jìn)的效果。具體來(lái)講有三個(gè)關(guān)鍵點(diǎn)：首先，通過(guò)價(jià)值流圖或約束理論，找到一個(gè)影響最大的、并且可以快速解決和可被度量效果的問(wèn)題；其次，限制首次進(jìn)行改進(jìn)的范圍，最小化改進(jìn)工作；然后，與對(duì)改進(jìn)有興趣并有充足容量和能力的團(tuán)隊(duì)合作，取得速贏。

分享成功經(jīng)驗(yàn)。為了獲得其他人的支持，你需要做好成功經(jīng)驗(yàn)的宣傳工作，吸引更多的人加入到改進(jìn)工作中來(lái)。比如有的企業(yè)組織內(nèi)部的DevOpsDays大會(huì)，跨部門進(jìn)行經(jīng)驗(yàn)的推廣，這非常有效。另外午餐學(xué)習(xí)會(huì)、內(nèi)部博客、郵件列表、Slack或HipChat頻道都是獲得參與者最好的渠道。還要對(duì)其他嘗試的人提供幫助，就像DevOps教練應(yīng)該做的工作那樣。

持續(xù)改進(jìn)。高效能的組織永遠(yuǎn)追求改進(jìn)的機(jī)會(huì)。就像豐田管理系統(tǒng)的締造者大野耐一所說(shuō)的：”Kaizen [improvement] opportunities are infinite”，改進(jìn)的機(jī)會(huì)是無(wú)窮無(wú)盡的。百度集團(tuán)總裁兼COO陸奇在去年的一次演講中也講過(guò)：”Engineering Excellence 是一個(gè)永無(wú)止境的、個(gè)人的、團(tuán)隊(duì)的，能力的追求和工具平臺(tái)的創(chuàng)新，綜合在一起可以帶給我們帶來(lái)的長(zhǎng)期的、核心的競(jìng)爭(zhēng)力”。Relentless pursuit of excellence，這是我們應(yīng)該堅(jiān)持的態(tài)度。

▌總結(jié)

今天我們從鳥飛派和空氣動(dòng)力學(xué)派的類比說(shuō)起，DevOps的轉(zhuǎn)型不能照搬其他組織的實(shí)施過(guò)程，而是應(yīng)該深入理解其背后的原理、原則和實(shí)踐。

我們分別介紹了DevOps轉(zhuǎn)型的五個(gè)誤區(qū)、五個(gè)實(shí)踐，以及轉(zhuǎn)型實(shí)施的具體建議。

五個(gè)誤區(qū)。放棄現(xiàn)有人員而招聘新的DevOps專家、進(jìn)行大規(guī)模組織結(jié)構(gòu)重組、重新編寫應(yīng)用并上云、購(gòu)買一攬子DevOps工具、給開發(fā)生產(chǎn)環(huán)境完全訪問(wèn)權(quán)限；

五個(gè)實(shí)踐。習(xí)慣小批量的工作方式（開發(fā)、架構(gòu)、組織文化的演進(jìn)）、創(chuàng)建反饋循環(huán)（流水線建設(shè)）、通過(guò)價(jià)值流進(jìn)行跨職能協(xié)作、建立實(shí)驗(yàn)的組織文化、持續(xù)消除浪費(fèi)并優(yōu)化價(jià)值流；

轉(zhuǎn)型實(shí)施具體建議。關(guān)注DevOps轉(zhuǎn)型的關(guān)鍵能力要素，對(duì)可度量的業(yè)務(wù)目標(biāo)達(dá)成一致、給團(tuán)隊(duì)資源進(jìn)行實(shí)驗(yàn)并對(duì)學(xué)習(xí)進(jìn)行激勵(lì)、與其他團(tuán)隊(duì)溝通并鼓勵(lì)協(xié)作、取得速贏、分享成功經(jīng)驗(yàn)、持續(xù)改進(jìn)。

以上這些內(nèi)容都是在很多企業(yè)中總結(jié)出來(lái)，是被證明過(guò)的、對(duì)提升組織效能最有效的方式。我們的目標(biāo)是快速的發(fā)布、更高的可靠性、更好的恢復(fù)能力和更安全的系統(tǒng)，以及更人性化、持續(xù)改進(jìn)和自我增強(qiáng)的組織。

想了解更多IT資訊，請(qǐng)?jiān)L問(wèn)中培偉業(yè)官網(wǎng)：中培偉業(yè)