▌背景

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

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

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

▌DevOps能夠幫助我們什么

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

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

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

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

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

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

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

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

下面我們來詳細分析一下：

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

不得不說，這絕對是一個糟糕的想法，建議不要這樣做。從經(jīng)驗來看，招聘新的DevOps專家是一件很困難的事情，我身邊的一些朋友都在尋找這樣的人才，但其實很難找到完美的人選。因為DevOps工程師或?qū)＜也皇侵苯幽軌蚺嘤柍鰜淼模矝]有一所大學教授DevOps的課程，這些有經(jīng)驗的人都是在工作中不斷遇到和解決問題的過程中逐漸成長起來的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

▌DevOps轉(zhuǎn)型的五個實踐

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

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

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

找到最重要的工作

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

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

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

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

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

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

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

是否無需與團隊外的其他人員進行細粒度的溝通就可以完成自身的工作？

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

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

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

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

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

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

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

通過不斷拆分，更快的進行交付

為可測試性和可部署性進行設計

新的架構(gòu)運行在PaaS平臺上

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

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

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

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

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

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

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

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

3 ▏實踐三：通過價值流進行跨職能協(xié)作

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

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

4 ▏實踐四：建立實驗的組織文化

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

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

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

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

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

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

1 ▏案例一. Google的災難恢復測試

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

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

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

2 ▏案例二. Etsy的”三只袖毛衣”獎勵

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

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

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

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

4 ▏實踐四：持續(xù)消除浪費，優(yōu)化價值流

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

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

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

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

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

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

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

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

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

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

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

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

▌總結(jié)

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

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

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

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

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

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

想了解更多IT資訊，請訪問中培偉業(yè)官網(wǎng)：中培偉業(yè)