2017年度的DevOps最新現狀研究報告最新出爐，這份由Puppet牽頭DORA（DevOps Research Assessment）主導的報告已經成為每年獲取DevOps最新研究現狀的權威資料。今年從這份長達53頁的報告中又能有哪些收穫和感悟，讓我們拭目以待。

Dora

Jez Humble和Gene Kim位列其中，為這份報告的權威加上了足夠的註解。而Dora也正是由這二位和 Dr. Nicole Forsgren共同創立的。

Dora的Sponsor和參與企業有HPE/Splunk/Amazon/Atlassian等

內容概要

如今，作為一種已經被接納和理解的一組文化價值和實踐的集合，DevOps已經被證明能夠幫助各種體量的組織改善軟體釋出以及質量和安全，同時能為產品的開發提供快速的反饋。在過去的六年中通過對超過27000份DevOps調查反饋，有了足夠的證據去證明DevOps實踐推動了IT的更高效能。而更高的效能則改善了生產性，利潤和市場份額。
今年，研究同樣發現了DevOps所能帶來的不僅僅是財務上的改善。所有的組織，不管是盈利組織還是非盈利組織，不管他們的使命是什麼，通過實踐DevOps都能在實現目標的過程中有所改善。
通過對領導者如何高效地影響技術實踐和流程改善以實現更好的IT和組織效能方面進行研究，同時發現自動化是各個組織之間效能不同的關鍵要素。而在應用架構以及組織結構構成是如何影響軟體開發和交付方面同樣也做了更加深入的研究。

六大主要發現

變革型領袖體現出文化塑成的五個維度

在塑成高效能企業文化方面，五個維度的共性要素能夠極其有效地幫助企業文化轉型。 願景, 啟發性溝通, 智慧激發, 支援性的領導力, 相互間的認可：這個五個共性要素與形成高效能企業文化有著緊密的聯絡。高效能團隊在這些要素方面表現都非常好，而這些也是其與低效能團隊的顯著區別。

高效能團隊持續保持更快的速度和更好的穩定性

與去年相比，隨著低效能成員改善部署頻率以及縮短交付實踐的變化，高效能成員和低效能成員在產出方面的差距在縮小。然而，低效能成員在故障的回覆時間和失敗率上明顯偏高。研究認為這是快速部署的壓力更多的造成了低效能者對構建質量的重視不足導致。

自動化給組織帶來巨大福利

相比與其他團隊，高效能成員所在團隊通過自動化顯著地提高了他們地配置管理/測試/部署以及變更審批流程。其結果是更多的時間和創新可以用在反饋迴路中。

DevOps在所有的組織中得到了踐行

今年通過研究組織的財務和非財務的指標，在願意實現這些指標方面高效能者是低效能者的兩倍。去年的研究也表明，不管是COTS（ commercial off-the-shelf software）還是部署在雲端的微服務，都可以進行DevOps實踐來實現更好的效率。而今年，如何在DevOps的世界裡重新審視COTS，更加深入的指導原則被引入了進來。

鬆耦合的架構和團隊在持續交付方面表現更好

為了達到IT高效能之路，在架構上遷移到鬆耦合的服務，組織上轉換為鬆耦合的團隊是一個好的開始。鬆耦合的服務使得服務之間能夠獨立的進行開發部署而不相互影響。而鬆耦合的團隊則能使得對變更對應更加有效。對那些從創意到產品之間需要很多手工處理和審批流程的企業，這種轉變需要不少投資。而鬆耦合的服務和團隊帶來的益處也是顯而易見的：更多的產出和更好的質量與穩定性。

精益產品管理驅動更好的組織效能

精益產品管理實踐幫助團隊更加高頻地交付客戶真正想要的特性。這個快速的交付迴路使得團隊可以進行嘗試，與客戶之間建立一個反饋迴路。而這個結果則是整個組織的收益，可以從利潤/生產性/市場份額上予以衡量。

取樣分佈

過去的六年中，對IT職業從業人員/開發者/決策者等進行了超過27000份的調查問卷，涵括了當今最複雜的DevOps實踐。而今年超過3200人蔘與了這項調查。

區域

取樣的地域多數取於北美和歐洲，二者之和超過80%。

行業與規模

科技與金融撐起半壁江山，而零售/通訊/教育/醫療/政務/健康/保險/製造等主要行業也達到40%左右，整體行業均有涵括。

2000人以上的大型公司佔到41%，100-2000人中等公司佔比35%，100人以下的小型公司22%，另有2%狀況不明。整體來說各種規模構成均有研究。
關於系統規模，2000臺伺服器以上的大型系統佔比29%，100到2000臺伺服器構成的中型系統佔比38%，100臺以下的小型系統佔比20%，各種系統規模也均有涵括。

DevOps團隊

隨著DevOps理念和實踐的不斷推廣，與DevOps團隊相關的工作人員也開始逐年明顯地遞增。

年份	2014	2015	2016	2017
佔比	16%	19%	22%	27%

變革型領導力

變革型領袖所體現出地領導力非常之重要，根據gartner的預測，到2020年，近半數沒有進行團隊能力轉型的CIO都將會被他們組織中的數字化資訊領導團隊所取代。
這是因為領導力確實在發揮著重要的作用與影響。一個好的領導者能夠影響團隊如何更好地交付程式碼，設計好的系統架構，踐行精益原則等。而所有的這些都會直接影響那些肉眼可見的指標比如利潤/生產性/市場份額。而非盈利型的組織不會考慮利潤，但是領導力會影響到客戶的滿意度，效率以及實現組織目標的能力。
而今年令人興奮的一項研究則是聚焦在調查那些幫助驅動高效能的領導力的特性。而這一點是在DevOps中一致被我們所忽視的話題之一，雖然變革型領導力在很多地方都已經體現出其非常重要比如：

• 建立和支援高效和互信的文化規範
• 實施提高開發者生產效率的技術和流程，縮短交付時間，支援更加可靠的硬體裝置
• 支援團隊嘗試與創新，更快地開發更好的產品
• 打破組織壁壘以實現策略協同

而最為共通的一個問題我們所聽到的則是：什麼時候領導才能到位？因為這樣那些必須的變更才能有可能得到執行。每個人都知道，被賦予權利的領導可以調節資源以及預算等才有可能是的大規模的變革成為可能。領導者是為組織設定基調並強化其期待的文化規範的重要人物，取得其支援非常重要。
在今年的研究中我們使用了2004年Rafferty和Griffin所提出的變革型領導力模型的五個維度來分析研究，這個五個維度分別是：

• 願景(Vision): 設立清晰的理念組織在5年之內將何去何從
• 啟發性溝通 （Inspirational communication.）：即使是在一個不確定而且複雜多變的環境中，溝通也是鼓舞和激勵的重要方式。
• 智慧激發（Intellectual stimulation）：激發跟隨者從一個新的角度重新思考問題。
• 支援性的領導力（Supportive leadership）：顯示出對跟隨者的考慮，照顧到他們的個人需求以及感受。
• 相互間的認可（Personal recognition）: 對工作目標的達成以及質量改善的表揚和承認，當別人工作很出色是個人對其進行讚賞。

通過對高中低的領導力在IT團隊中的觀察和研究發現，變革型領導力特質跟IT高效能有密切的關係。高效能團隊這些維度明顯比低效能團隊做的要好。
在研究中觸動較大的是：將變革型領導力進行分級，那些連合格級別的變革型領導者都缺乏的團隊很難成為高效能團隊，甚至成為高效團隊的意願都不強。雖然我們聽到很多來自於底層的DevOps成功的事例，但是有強有力的變革型領導者支援的話，則更加容易獲得成功。
另外一項分析也發現變革型領導力與員工忠誠度指標NPS（ Net Promoter Score ）也緊密關聯。研究發現強的變革型領導所在的團隊成員感到了更多的快樂和使命感，也更加的忠誠。變革型領導者對團隊在技術實踐和產品管理能力方面都有明顯的影響。而這些正面或者負面的影響最終都會體現在組織的整體績效上。
有趣的是，研究同時發現僅僅擁有強有力的變革型領導者還是不夠的。通過對團隊變革型領袖進行評比，在前10%的DevOps實踐中，本來會以為著這團隊整體應該都會表現地非常強勁有力，但是結果卻並非如此，各種效能都有。因此，擁有變革型領導者很重要，但是這並非全部，僅靠這一點還是無法實現DevOps實踐的成功。因為DevOps實踐的成功還依賴於合適的架構，好的技術實踐，精益管理原則的應用，以及其他很多一直在研究的因素。
總的來說，研究發現好的領導者通過使得團隊對系統進行重構以及實施持續交付和精益管理實踐，對建立強大的團隊和組織以及技術產品起到間接的幫助。變革型領導力有助於實施那些與高效產出相關的必要實踐，也能夠協調和幫助不同團隊的成員能夠追逐組織目標時進行有效溝通。而這樣的領導力構成了文化的基礎，而在這中文化的氛圍之中，持續的嘗試和學習則成為了每個人日常工作的一部分。
研究中已然確認變革型領導者對實現價值改善流程和實踐中的重要作用。但是變革型領導力不是孤立存在的行為或者一套新的實踐方式，它只是放大了近些年來一直在研究的那些組織實踐和技術實踐的效果而已。
本次研究所採用的SEM模型（ structured equation model ）如下所示：

有五個維度構成的變革型領導力影響著持續整合和持續交付等實踐不斷實施，驅動精益產品管理實踐進行團隊嘗試和反饋改善，從而正面影響團隊IT高效能，進而預示著各種組織目標的實現。

IT效能和組織效能

如今，不管是為了增加業務利潤還是創造社會效益，幾乎每個組織都依賴與軟體和IT去促進這些目標的實現。各種組織紛紛轉向DevOps因為有越來越多的證據表明DevOps確實能夠幫助軟體更快跟穩更好（更少錯誤）的釋出。
我們使用如下兩個主要的維度來衡量IT效能：

• 吞吐量（throughput ）：用以衡量團隊能夠以一個怎樣的頻率實現從程式碼的提交到部署上線，這個是為了衡量多”快”
• 穩定性（stability）：用以衡量系統服務停止之後多就能夠恢復以及變更成功率，這個是為了衡量多”穩”

這樣DevOps混亂之源的開發(Dev)的”快”與運維(Ops)要求的”穩”都可以得到衡量。
在上一年的報告中，得到了高績效者在吞吐量和穩定性方面都有著非常明顯的優勢。而在2017年，高績效者的整體優勢仍然存在：

• 吞吐量指標：部署頻度：46倍優於低效者
• 吞吐量指標：程式碼提交到部署的交付時間：440倍優於低效者
• 穩定性指標：MMTR（mean time to recover from downtime ）：96倍優於低效者
• 穩定性指標：變更失敗率：低效者的1/5

對比與2016年的研究結果，今年高效能者與低效者之間的吞吐量上的差距縮小,而穩定性指標的差距進一步拉大。研究認為偏重於提高速度而對質量和流程的重視和投入不夠，而高績效者理解而且在實施中兩者兼顧，自然穩定和速度兩者得兼。
2017年的比較資料如下所示：

只有與以前的資料相比進行分析才能真正瞭解到當前DevOps的實踐現狀。相比於2016年，部署頻度的差距收窄，高績效者保持著去年的水平，而低績效者的水平明顯提高。同樣【程式碼提交到部署的交付時間】這項指標也是同樣。這個變化不是說高績效者做的沒有以前好了，而是低績效者在過去的一年中取得了長足的進展，是非常可喜的成績。
與之相對的是穩定性指標，高績效者在過去的一年中，在穩定性方面的優勢不但沒有縮小，反而進一步的擴大。這個優勢使得他們更加地取悅於客戶，能夠花更多的時間在創新上，產品或服務投放市場更快，客戶體驗更好，對市場變化的反映能力更強。

吞吐量指標

部署頻度

高績效者今年與去年持平，而低績效者大幅度提升，部署頻度的差距收窄到46倍。但是值得一提的是像Etsy這樣的公司平均每日部署80次而諸如Amazon和Netflix這樣的公司每日部署上千次之多（生產環境中提供的服務有數百個結合而成）

程式碼提交到部署的交付時間

高績效者今年與去年持平，而低績效者大幅度提升，Lead Time的差距收窄到440倍。

穩定性指標

MMTR

MTTR： mean time to recover from downtime 。高績效者的MTTR少於一個小時，而低績效者則在一天到一週之間。相比去年，低績效者的MTTR表現更差了。

變更失敗率

高績效者的變更失敗率：0-15%，而低績效者則為：31-45%。分貝取中間值分別為7.5%和38.5%，低績效者變更失敗的比率是高績效者的5倍，此項指標的差距也進一步拉大。

自動化

在去年的報告中對重複作業以及計劃外作業所花費時間的比較已經做了分析。今年，研究中又進行了細化，具體的確認了在各種實踐中還有多少是手工作業多少是自動化完成的，比如在如下的實踐中：

• 配置管理
• 測試
• 部署
• 變更評審

在分析中得到了一個很重要的結論，高績效者的手工作業明顯少於低績效者，而自動化程度也明顯高於後者。自動化是組織的一個重要紅利，通過自動化，高績效者的生產力更多地被解放用於實現那些能給組織帶來更多價值的創新上，比如一個很好的例子是惠普公司的實踐，他們通過DevOps實踐，對自動化進行改善達到了非常好的結果。

高/中/低效能者手工作業的比率如下所示：

從中可以清楚地看到，無論是在配置管理和測試，還是在部署和變更審批流程上，高績效者所進行地手工作業明顯都低於低績效者。
但是有一項研究資料稍微有點出乎意料地是中等績效者卻是比低績效者做的手工作業還要多尤其是變更稽核流程環節。而這一點同去年地一項研究資料也非常地合拍：中等績效者比低績效者在重複作業（rework）上花費更多地時間，儘管他們部署頻度更高。到底這是怎麼會發生的呢？
通過分析和研究，結論是：中等績效者在加速自動化的過程中，可能會導致一個臨時性的重複作業和手工作業都會增加的一個過渡性階段。中等績效者對自動化的投入已經很多也能看到效果，但是同時和會發現技術債務的積累也到了很高的程度，而正是這些技術債務在拖慢他們的節奏進入下一個更好的程度。結果就是加入了一些人工評審和手工作業進行彌補，而這些則明顯拖慢了他們的速度。
增加這些非自動化的控制是能夠理解的，但是這種誘惑這是希望組織能夠去抵制的。這個階段的最終目標是為了消除這些非自動環節帶來的瓶頸。不過一旦這些技術債務得到償還，更大程度的自動化便唾手可得。而中等績效者的自動化改善環節自然能夠提升到一個更好的程度。

組織績效的附加衡量指標

多年以來，很多人都一直認為DevOps只是適合像Google/Amazon/Netflix這樣的獨角獸公司，而其他的並不一定合適。通過研究報告的共享，我們已經很大程度的改變了這種認知，現在主流的企業都認為DevOps能給給他們帶來競爭上的優勢。但是仍然有一種觀念認為DevOps只是在那些以盈利為目標的企業（for-profit）中能夠發揮作用，而那些非盈利（ not-for-profit）的機構諸如政府組織等的系統並不能發揮作用。
而今年的調查報告則顯示高效精準地開發和交付軟體的能力對包含非盈利企業地所有組織都是非常重要地一項指標。只要你想交付價值，不管你如何去衡量它，DevOps都是可以幫助到你的方法。
從2014年第一次開始釋出研究報告以來，被問到的最多的問題就是如何把這些實踐應用到諸如國防或者政府機構，大學等非盈利組織中去。因此，今年的調研報告關注更加在組織實現更為寬泛的組織目標上，也就是說，目標不在只限於利潤和財務指標。而不管你是否去獲得利潤，每個組織都需要依靠技術去實現他們的目標：提供更加快速，更加可靠，更加安全的服務或者產品。研究則發現高績效者在如下這些目標上能夠取得兩倍以上的優勢：

• 產品或服務的數量
• 操作的效率
• 客戶滿意度
• 產品或服務的質量
• 組織和目標的實現
• 第三方參與者的衡量指標

研究發現這些不管實在什麼樣的組織和行業中都會發生。對任何型別的組織，不管所處那種行業，DevOps都能夠幫助企業實現他們的目標，這是在今年的研究中所發現的。cloud.gov則提供了一個非盈利組織DevOps實踐的案例。

技術實踐

今天，DevOps已經被視作更快交付軟體，獲得更好的效率以及取得競爭優勢的重要途徑。而一些更加急切的使用者則開始研究他們應該買什麼樣的工具，其實，更加重要的是這些技術上的實踐，而這些實踐才包涵著轉向DevOps的初心所在。
而關於這些更為細緻和共通的專案，研究也一直在繼續：

• 版本控制實踐
• 持續整合
• 基於Trunk的開發
• 自動化

而今年，增加了對技術架構和團隊的結構的關注，同樣會研究它們是如何影響組織開發和交付軟體的能力的。

持續交付

去年，研究發現組成持續交付的實踐：開發自動化，自動化測試，持續整合，基於Trunk的開發，所有構件的版本管理，這些對部署之痛，IT績效以及變更失敗率起到重要的作用。自然，最終會直接影響生產性/市場份額/利潤等重要組織目標。
去年，研究使用上述實踐組成了持續交付的模型。而今年的研究則使用了其產生的結果作為模型，在這個模型中，將會根據團隊獲取如下兩項產出的能力對持續交付進行衡量的：

• 全生命期的按需部署： 團隊能夠在軟體的全生命交付週期對產品或者最終的使用者按需進行部署。
• 快速反饋迴路： 團隊的每一個成員都參與到對質量和系統的部署能力的快速反饋中，而對這些反饋所必須的應對則是最高的優先順位。

而這些可以使得我們做兩件很有意思的事情。第一，我們能夠看出實現這些產出能夠對IT績效和部署之痛所帶來的影響。其次，我們能看到那些要素最為影響這些產出，同時也能夠研究一下諸如鬆耦合架構等所能帶來的影響。

持續交付的五項影響要素

我們希望知道持續交付受那些影響要素的程度，研究發現如下五項要素都正面影響持續交付：

• 綜合版本控制
• 持續整合和基於Trunk的開發
• 安全與軟體交付的融合
• 測試自動化
• 部署自動化

在所有的要素之中，自動化測試則是最大貢獻者。
另外，良好的架構對持續交付的影響也是今年重要的確認點之一，研究的結果也證實了架構對於實現高績效的重要性。

架構

在過去的幾年中，對架構與持續交付/IT績效的關聯已經做過了調查。而今年則進行了更深入的分析研究，發現建立鬆耦合的架構和團隊對於驅動持續交付實踐的能力有非常明顯的作用。
通過如下兩個方面來對服務和元件之間的耦合度進行判斷：

• 可否做測試而不需要額外的整合環境
• 物件應用可否獨立地部署或者釋出而不必考慮其他的應用或服務

對於那些商用關聯的COTS場景，物件環境中也確認了是否包涵COTS。

在2015年的調查報告中，就曾經發現高績效團隊的耦合度明顯對於中低績效團隊。而這些對於應用程式的影響也是一樣的。而今年，如下兩項假定希望在研究中進行驗證：

• 給予了更多權利，能夠自主選擇工具和實現的團隊表現更好
• 鬆耦合的良好封裝的架構能夠驅動IT績效

關於第一項假定，通過研究發現，相比較於強制地集中控制式的工具使用，能夠自主選擇工具的團隊確實表現更佳。沒有人比團隊成員自身更清楚地瞭解什麼樣地工具能給他們帶來更多地效率，給予團隊自主選擇的權利能夠帶來更好結果自然毫無意外。
第二項假定同樣在研究中得到了印證。那些在IT和組織績效上表現強勁的團隊，大都使用了鬆耦合的系統架構，這樣使得交付團隊能夠獨立地進行測試/釋出/系統變更而不必考慮和其他團隊的額外工作/資源協調/審批等待/反覆交流等，架構和團隊的鬆耦合帶來了確確實實的好處。
就像康威定律所描述的那樣（設計系統的組織，其產生的設計和架構等價於組織間的溝通結構），組織機構和軟體架構的關係非常緊密，而在今年的研究之中，更多的則像是”逆向康威定律“：組織和團隊從設計到部署都應該能夠無需和其他團隊進行過多牽扯精力的依賴而能夠獨立地完成他們地功能。
架構實踐通過使用邊界上下文（bounded context)和API作為Domain間解耦地重要策略，面向服務的架構應該注意解耦。實際上，有很多所謂的面向服務的架構都不能允許相互之間獨立的測試和部署服務，因此團隊無法獲得高效率也是意料之中。

解耦非常重要，作為架構設計對持續交付的影響，出了前面提到的五大要素，在架構和團隊解耦上有一些甚至比部署自動化等所起的作用都更大的要素存在，比如確認團隊是否能做到諸如如下的事項：

• 對系統做大規模變更設計不需要團隊外部某個人的批准
• 對系統做大規模變更設計不需要依靠其他系統或者為其他做很多特意的工作
• 無需和團隊外的其他成員做細粒度的溝通和協調工作就能完成自己的工作
• 獨立於其他服務或者產品，可以按需部署和釋出自己的產品和服務
• 可以在業務時間內用可以忽略的系統downtime來完成部署

質量和安全

在去年的介紹中，發現高績效者僅僅在重複作業和計劃外作業就比低績效者少花22%的時間，而他們能在新的特性開發等新的作業上多花29%的時間，而今年這個趨勢和結果已然存在，而且新的作業上能夠投入的時間的優勢進一步加深，這兩個資料分別變成了21%和44%。

基於Trunk的開發

去年，通過研究基於Trunk的開發在持續交付中所扮演的角色，我們的經驗表明高績效團隊更多進行小批量的開發而不是長期存在的特性開發的分支。去年的調查結果表明如下開發實踐對於提升交付績效有好處：

• 每天合併程式碼到Trunk
• 使分支或者fork存在時間變短：通常為一天之內
• 少於三個同時實際進行的分支

同時研究也發現，團隊不存在code lock也會對軟體交付績效有正向的影響。但是使用github推薦的workflow的一些開發者對此也稍微心懷疑慮，因為workflow推薦在分支上進行開發，而只需要階段性的合併回Trunk。但是短時間存在的分支，及時合併回Trunk，至少以每日構件這樣一個頻度能使得持續整合的時間做地更加徹底。

而今天通過調查高中低績效者所在團隊分支存在時間，發現瞭如下情況：

• 高績效者分支生命期最短，持續整合度也最高，分支存在和整合時間以小時計。
• 低績效者分支生命期長，持續整合度也最低，分支存在和整合時間以天計。

而者也驗證了去年地結果，作為推薦性地指導意見：團隊應該避免分支活躍時間超過一天。如果需要花一天時間去合併和整合分支，這就是一個警示了，它提示你需要研究一下你的實踐和架構了。

精益產品管理

去年關於產品管理的調查中，建立了一個從如下兩方面的能力進行衡量精益產品管理模型：

• 將工作拆分為小塊，而且使得其在整個交付流程中可視
• 收集，共享，改善客戶的反饋

今年，研究將模型擴充套件到調查敏捷原則的影響：給予團隊權利去建立和改變開發流程而不需要外部的審批。

將工作拆分為小塊進行反饋和改善

精益產品管理實踐會對IT績效有著很好的促進作用，這其中就包含將工作拆分為小塊，如何進行拆分，最小可用產品（MVP： minimum viable products）就是一個很好的實踐，下面的這篇文章就介紹了相關的概念。

在軟體開發組織中，拆分出最小可用產品非常重要，因為這樣你可以最小的代價，使用諸如A/B測試之類的方法，在最小影響的範圍內最快地進行使用者資訊收集和反饋。提供了軟體進行精益實踐的一個好的手段。

授權開發團隊

很多號稱敏捷開發的團隊實際作業時遵從其他團隊所做的需求而沒有提出自己意見的權利，這個限制可能會帶來很多實際的問題，而最終的結果則可能是產品不會取悅客戶，也無法交付所期待的業務結果。
敏捷開發的一個重要目標是在整個開發的過程中都去尋求客戶的真正需要，這使得開發團隊能夠得到重要的資訊，但是如果不管開發團隊發現了什麼，他們都沒有任何權利對需求進行改變，創新的能力將會被極大地閹割掉。
而今年地研究則發現團隊試圖使用新的Idea的能力是預測組織績效的一個重要因素。
當然，授權不是讓開發這可以做任何他們想做的Idea，而是需要和一直在不斷改善的DevOps實踐相結合才行。

總結

每一年的調查報告都會基於大量的資料給予DevOps的研究者以方向的指引。而在今年的報告中，通過資料，我們瞭解到DevOps不僅對追尋利潤的企業有驅動作用，對政府型等非盈利的企業也同樣有效。
而調查的結果也表明結論的一致和連貫性，在現在這個時代，軟體對每個公司都變得越發地重要，而IT績效也對組織地績效變得愈加地重要，通過DevOps實踐，更好地協調領導力，工具，自動化以及持續學習和改進地企業文化也變得越來越重要。