2018年度的DevOps最新研究現狀姍姍來遲，但最終還是來了，讓我們來看一下這份報告今年會給我們帶來那些啟示。

研究人員

鐵打的營盤，流水的Dora（DevOps Research and Assessment）。參與其中Jez Humble和Gene Kim一直是這份報告最大的看點，他們的離去雖然是一種遺憾，新的加入也會從其他角度帶給我們不同的思考。2018年度的報告的作成主要由splunk和puppet引導給出。

內容概要

DevOps實踐之路，成功的方法很多，但是失敗的方式更多

DevOps實踐對任意個一個組織來說，都不是一帆風順的，會有很多起起落落，而這些會使得早期來之不易的上升勢頭受到打擊。
而將DevOps的成功經驗進行復制也是一個非常挑戰的事情，如何才能順利推進？一旦碰到挫折，如何才能重回正軌？
雖然DevOps實踐是一個不會結束的長期過程，但是還是有方法可以幫助它，這份報告中整理出了其中的五個重要階段和關鍵實踐內容以幫助DevOps實踐之旅的順利展開。

企業最高管理層比團隊成員對DevOps進展更加樂觀

在很多DevOps的實踐中，Job title以C打頭的最高級別的管理層往往都會過於樂觀，這是因為他們的訊息來源是自下而上傳遞而來，這個過程中往往有過濾和"消毒"，導致阻礙程序的問題以及瓶頸都無法被完整看到，由於他們對現狀的認識是不完整的，所以在資料上顯示出了和團隊成員之間的gap。
比如在關於安全團隊是否在設計和部署的過程中介入了的問題上，管理層有64%持肯定看法，而團隊成員則只有39%持相同看法。

總結：
使得每個人對實踐的狀況有相同的認知這點非常重要，而實現的方法則可以強化自動化和衡量指標資訊的共享上。

跨團隊分享是DevOps成功經驗能複製的重要因素

DevOps的關鍵要素C（文化）A（自動化）M（指標）S（分享），在研究中發現分享對於DevOps經驗的擴充套件中具有最為重要的作用。很多DevOps實踐取得了一些小範圍的成功，但是無法更進一步，導致最終對於業務的正向影響也較為有限。為了使DevOps早期實踐獲得的成功更好地擴充套件，跨組織進行成功經驗和失敗教訓的分享對於整個DevOps實踐具有重要的作用。

自動化安全策略配置對更高成熟度的DevOps實踐具有重要作用

成熟度高的組織相比於其他較低的組織，在自動化安全策略配置方面，效率是其24倍。安全策略已經是整個過程中的一部分，而不再是傳統意義上在審查室的例行確認。這要求打破橫亙在運維和資訊保安團隊之間的那堵“牆”，而最終隨著資訊保安團隊的融入，安全配置能夠進行自動化配置將會傳統意義上的另外一塊瓶頸予以打破。

概要解讀

解讀1：Five Stages

這份報告更多地聚焦於如何進行DevOps的落地實踐，提出了五個階段或者步驟來給予整個實踐的旅程更好的引導。而整份報告幾乎都是對這五個階段的展開。無論是剛剛起步的階段還是卡在某個階段止步不前的企業，報告稱這種方法能夠幫助組織更快更好地走向成功。

解讀2: DevOps實踐成功的擴充套件

小規模的DevOps試行已經獲得成功，但是成功地如何大規模的擴充套件開來是一個巨大的挑戰。如何複製小規模的DevOps的成功，是當下實踐的重點挑戰之一。

解讀3: 偏離方向的實踐

有很多團隊在九年之前就開始踐行DevOps，但是至今似乎不得其門而入，或者卡在某個階段無法繼續。DevOps不是萬應靈藥，在一個一路高歌猛進的現狀之下也需要給自己潑盆冷水了，應更多的聚焦於組織的目標，反向進行落地，DevOps到底能給我們帶來什麼，在每次實踐的時候，功利性地明確到底能帶來何種收益，落地之後像個商人一樣去檢查，而不是僅在文化上的諸如NoBlaming上反覆暢談。

解讀4: 融入安全的DevOps

將安全融入DevOps，這從來都不是一個新的話題，甚至還是一個主題：DevSecOps。本年度的報告中將安全策略的自動化配置提到了一個重要的角度，除了其他的都談過了之外，安全確實是不可獲取的一塊拼板。
傳統意義上的安全，一般情況下在很多專案中本來就是形同虛設，在引入DevOps加快業務交付的同時，將這個問題變得更加尖銳，就像DevOps Hand Book中所提到的那樣，開發人員：運維人員：資訊保安人員，在實際的情況中往往這個比例是100:10:1，所以安全資訊的自動化，不是一個錦上添花的事情，而是如果在實際專案中真正有所謂的資訊保安的確認，這是一個必選項，沒有資訊保安策略的自動化，DevOps註定無法推廣開來，除非投入大量的人力進行follow，基於成本的考量，這在現實的世界中不太可行，所以自動化提高效率在此處是一個必選項，除非此資訊保安設定可有可無。

資料來源

區域

2018年的亞洲相關的資料上漲了80%，那是因為2017年的比例太低，上漲之後仍然只有可憐的18%。歐洲和美國的資料仍然佔到了整體的68%。

加上臺灣地區，在這份報告中中國的資料比例佔到整體的亞洲部分的4%（大陸地區3%），日本和彈丸小國新加坡各佔亞洲資料的37%，印度18%。

所以，整體來說，這份報告基本不能反映中國地區在全球的DevOps發展狀況，但作為對標的資料都是有一定的參考意義。

作為歐洲經濟三大強國的英/德/法，三家資料佔到整個歐洲的3/4.

行業與規模

科技與金融仍然撐起半壁江山，而零售/通訊/教育/醫療/政務/健康/保險/製造等主要行業也達到30%左右，整體行業均有涵括，非盈利的組織資料佔比明顯提高，這也間接印證了2017年的結論之一：DevOps在各個行業已全面展開。
相比較與2017年使用人數，今年對組織大小的判斷定義在年度營業收入，使用annual revenue將組織進行劃分，10億美元以上的組織佔到1/4，其餘規模的組織比例也較為均衡。

角色

比較有趣的是參與調查的人員角色的構成比例，填寫調查報告的有9%的C級別的企業最高層管理人員，普通的管理人員有39%，Team Leader和IC佔到47%，真正的IC為26%。

DevOps團隊

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

55%的受訪者來自於IT部門，36%來自於開發部，相較於2017年的27%，2018年的29%，更加細緻：14%（IT部門） + 15% （開發部）

在一個DevOps至今尚無統一定義的2018年，有29%的人在稱為DevOps的組織中工作，這是每年都會看的一個有趣資料，而且這個比例還在不斷上升。

組織結構

根據調查結果，在DevOps實踐中被採用的方式：開發中心方式（58%），特定應用服務的跨職能團隊方式（57%），而專職的DevOps團隊只佔到51%。
另外SRE團隊方式是目前採用最少的方式，但是關於後續是否會嘗試使用這種方式的調查上，意願是最高的（28%）。

解讀：
通過對受訪資料的分析，這次調查報告認為C級別的最高管理人員在後續嘗試沒有使用過的組織結構方面明顯比普通管理人員和團隊成員要低得多這個結論非常有趣。
但是我個人認為這是一個非常正常的事情，作為組織變動被影響最大的C級別的最高管理人員，頻繁地做影響自己position的變化應該並不算是好主意。
而且很多實踐的經驗也已經證明，很多專案的內在動力是在於這次調查報告中包含的較少的草根階層，樸素的動力往往就只是來源於避免沒有營養的重複性作業，增加一些自己生活和成長的時間而已，從資料上也可以看出他們根本沒有那麼多時間去填寫調查問卷。

解讀：
在看這個結果的時候，先預設一個問題：如果我所在的組織要推行DevOps，我們應該以什麼樣的組織結構去面對它？
前文中當前使用的結構就是現在的DevOps實踐所給出的答案，除了DevOps團隊之外，可以看出目前比例最高的仍然是現在的組織構成，開發中心方式明顯就是各種GDC，特定應用服務的跨職能團隊方式就是大型專案目前的現狀，所以實踐給出的答案就是：除了DevOps團隊之外就是繼續使用原有的結構。
為什麼SRE方式是目前大家嘗試意願最多的一種呢，從另外一個角度來看，已經有人嘗試的方案在備選答案中僅此一家別無分店，自然大家會希望使用google嘗試過的方式。這樣看來之後，SRE目前選擇的最少但是後續希望嘗試的最多這個結論也沒有太多意外了。
希望後續的報告能夠在使用什麼樣變革型的組織結構以及實踐的效果方面有一些資料的支援，不然個人認為這份報告具有的導向性會越來越低。

Five Stages

這是整份報告的重中之重，Five Stages，並給出了各個Stage建議做的事情。

四個關鍵要素：CAMS

調查的角度和方向，調查的方向聚焦於DevOps的四個重要支柱，CAMS這4個維度在分別有不同的側重點，這也是在實施中所需要關注的。

關鍵要素細化

C：Culture：文化維度

在文化維度，重點確認DevOps文化在不同的組織結構中的實施狀況

• 單一團隊
• 單一部門的多個團隊
• 單一部門
• 橫跨多個部門

A： Automation： 自動化維度

自動化的維度，主要確認當前自動化推行的狀況，團隊自身是否提供相關服務，自服務所推行的程度：

• 團隊自己控制自動化服務
• 使用其他團隊提供的自動化服務
• 團隊合作提供自動化服務
• 對關鍵業務功能提供自動化維度的自服務
• 對大多數業務提供自動化維度的自服務

M： Measurement：指標維度

指標維度從系統和業務兩個方面進行確認，收集方式從手工和自動兩種進行衡量：

• 諸如計算機效能和吞吐等系統指標通過手工方式收集和展示
• 自動收集和展示系統指標
• 業務指標通過手工方式進行收集和展示
• 業務指標通過自動方式進行收集和展示

S：Sharing：分享

分享是DevOps實踐經驗最快擴充套件的有效途徑，分享的範圍大小是衡量的一個重要標準

• 最佳實踐和模式在團隊內分享
• 最佳實踐和模式跨團隊分享
• 最佳實踐和模式跨組織分享
• 最佳實踐和模式在組織外部分享

調查結果

整體結果

整體來說，基本上一般程度和較好程度的已經佔到了90%，尚未起步的已經很少。但是一般程度的仍然佔據絕大部分，剛剛起步了一些，在一些方面取得了區域性的收穫但是離較好的程度還有一定的距離，這些佔到整體的79%。

C：Culture：文化維度

單一部門的多個團隊以及單一團隊方式為目前主要的實施方式。

A： Automation： 自動化維度

提供自服務的方式推動自動化的程序仍然只是佔到很小的一個比例，更多地還是通過團隊以及團隊之間的合作來實現自動化。

自動化一直被認為是一個非常容易被切入的維度，但隨著實踐經驗的擴充套件，依賴逐漸增度，複雜性逐漸增大，自然自動化的成本也愈加的昂貴，相關的問題都逐漸出現。自動化很重要，但是DevOps並不只是簡單地工具和自動化，這個結論再一次出現在報告之中。
(請注意本年度上面這張原圖有些錯誤，Low evolution的比例加起來高達到101%，再次驗證了小學數學成績的好壞根本不重要，兩位數的加減結果反正也沒有人會在乎，這不重要，請忽略)

M： Measurement：指標維度

隨著成熟度的提高，自動化程度會逐漸提高，手工方式會逐漸降低，這是一個整體的結論，系統級別的指標收集和展示在這個方面體現地非常清楚。
而業務指標資料的收集和展示自動化程度會逐漸提高，但和系統指標相比，複雜性和共通性較低，收集分析統計與展示也較為複雜，無論是自動化還是手工作業，相關的程度還有待於進一步地提升，是一個標準化仍在繼續的過程。所以在業務指標的自動化程度會隨著成熟度提高的時候明顯提高，但是手工的收集和展示方面也呈整體上升的狀態，隨著標準化的完善和進一步的提升，整體下降的趨勢應該會在後續出現，這一點可以在明年及以後的資料中可以進一步的確認。

S：Sharing：分享

隨著成熟度的提高，關於成功實踐經驗和模式的分享，在整個組織內部實施的比例越來越多，也體現了DevOps實踐在組織內部不斷複製和借鑑的過程。而對於組織外部的分享，目前各種成熟度都表現出的是比較冷淡，沒有明顯的利益推動，這樣的結果並不意外。

不同角色的不同結論

在這次的報告列出了一個角度，就是專案的不同角色對同一問題的看法，整體來說管理層級別越高，對問題的看法愈加樂觀。
比如對待在新的特性開發的時候保持較低的技術債務的這個問題的看法上，團隊成員有33%的比例，也就是說只有1/3的人有信心能夠平衡新的業務開發在一個比較低的技術債務基礎上，而C級別的最高管理層對此項的看法接近底層人員的一倍，有2/3的最高層管理人員對此有信心（真不知道這個信心是哪裡來的，開發的人自己都沒有，大概體現了一種真正的信任）。
報告認為，這種認識的落差來源於資訊的有意或者無意的過濾，所以增強溝通，提高自動化和指標展示，使得不同角色對相同問題有大體一致的看法這個也非常之重要。

Stage 0: 整體基礎的五個實踐

作為整體的基礎，如下五個基礎的實踐被認為是非常重要的基石：

• 監控和警告是可以配置使用的
• 部署模式是可重用的
• 構建應用和服務的測試是可以重用的
• 工具鏈可用並且團隊持續進行改進
• 配置使用配置管理工具進行管理

基礎實踐&分享

從某種角度來說，這些基礎實踐是跟CAMS模型中的S（分享）密切相關：

監控和警告是可以配置使用的：24x

在這一點的實踐上，成熟度高的組織達到了47%的比例，對比與低的2%，達到了近24倍的差距。

在具體實踐的細節上，有很多方式比如：

• 開發者自己對自己的程式碼部署和執行負責
• 開發者和運維人員一起提供相關的非功能性要素保證部署和交付
• DevOps團隊作為一個緊密結合的整體定義監控細節
• 由運維專家組成的團隊監控開發人員所交付的應用
• …

部署模式是可重用的: 23x

可重用的部署模式對於打破開發和運維之間的那堵牆（wall of confusion）非常重要，High級別和Low級別之間有高達23倍的差距。

構建應用和服務的測試是可以重用的 ：44x

同樣測試的可重用方面也是有著很大差距的，最重要的是Low級別的基本沒有相關的實踐，所以有高達44倍的差距。

解讀：不得不說這是一個去年沒有確認的重要部分，持續測試是DevOps中的一個重要環節，但是目前整體的狀況推廣的並不是很好，佔到整體大多數的Medium級別的組織只有10%左右的比例，Low級別更是幾乎沒有實踐，這將是接下來一個重要的實踐要點。

工具鏈可用並且團隊持續進行改進：44x

保持工具鏈可用並且持續進行改進，此項的差距也達到了44倍。

通過工具的使用，看起來似乎是自動化提高效率的一面，但實際影響更大的是通過工具的合理使用，使原本割裂開來的各個孤島進行了協作和資訊共享，這種改進更深層次的理解則是團隊進一步融合的顯現。

配置使用配置管理工具進行管理：

隨著DevOps實踐的深入，部署頻度的加快增大了運維側對於配置管理的自動化的壓力和需求，生產環境的效能和可用性需求也浮出水面，同時需要考慮快速的頻度下評審方式和資料提供的方式，一年一次部署的時候Audit的做法和一天十次部署的時候的做法自然不同，同時新的技術對於傳統的Audit方式帶來的挑戰都需要進行考量。這些最終反映在實際資料上看到此項調查相關的差距達到了27倍。

總結：
作為五項基礎的實踐，在實施中如下三項應該作為重點內容：

• 監控和警告是可以配置使用的
• 部署模式是可重用的
• 配置使用配置管理工具進行管理

而在此基礎之上，餘下的兩項建議推行，則是這份報告對於基礎實踐的五項所給予的結論

• 構建應用和服務的測試是可以重用的
• 工具鏈可用並且團隊持續進行改進

Stage 1: 規範化技術棧

很多組織都使用了很多技術，而且引入了很多的依賴，使得複雜性大為增加，而這些往往會拖慢整體的步伐。在這個階段，降低複雜性則是當務之急。

解讀：
就像報告所指出的那樣，很多人認為自動化應該是最初的切入點。而實際上如果事前的準備工作沒有做好，直接切入進行自動化，很多時候這種急功近利的樸實的需求並不一定能夠收到很好的效果。
在一個技術棧非常複雜的情況下，自動化本身就將會變成一個不可控的需求，而如果不對這種複雜性進行控制，後續的投入很有可能會大幅增加。所以規範化整體的技術棧更多的是為了簡化，降低過多的依賴，所謂磨刀不誤砍柴工。
我們做很多DevOps落地的專案中也是如此，雖然會講自動化作為一個很重要的點進行推行，但是在此之前對整體的流程/可改善的環節/改善的計劃和重點/技術架構進行討論，目的就是為了明確和降低整體的複雜性，以期能夠持續穩定的投入收到持續穩定的回報。

實踐內容

此階段主要從如下兩點來進行推進：

• 應用開發團隊使用版本管理

解讀：
版本管理是整體實踐的基礎，這一點應該不會有所異議。在實際的專案中，目前的階段沒有使用版本管理的專案可能更為罕見。但是是否所需要進行管理的內容納入了管理，管理是否規範，是否高效，這些問題實際上才是版本管理在實踐中不斷進行改善的細節。

• 團隊在標準的作業系統上進行部署

解讀：
應用和服務在複雜的作業系統中才得以執行這是非常普遍的一個現狀，在報告中所舉例的那樣，可能有在Windows 2012/Windows 2012RT/Windows 2016上執行的不同應用，而這些應用一起提供最終的服務，簡化這些能使得整體的複雜性大幅的降低。
在實際的專案中，往往比報告中所提到的例子更加複雜，你有可能還在使用一些大型機，使用已經不再更新版本了的Unix系統，使用Motif來畫頁面，使用CGI來寫網頁，因為大型的專案不是那麼理想可以一步替換的。但是簡化整體的技術棧確實是一個重要方向，哪怕技術本身不是一個問題，在DevOps Handbook 中就舉過一些公司在此方面的實踐，因為技術本身就非常複雜，每個人都很難在所有的方面做到全部精通，簡化技術棧可以使得在整體之間的溝通更為的高效和快速。

關鍵因素

為了保證此階段獲得成功，有四項對於結果影響最為重要的關鍵因素如下所示：

• 構建標準的技術棧
• 應用配置納入配置管理
• 在部署至生產環境之前測試基礎框架變更
• 原始碼對其他團隊可見

構建標準的技術棧

構建標準的技術棧非常重要，它是Stage 1的關鍵因素，同時是Stage 2中的實踐內容，也是Stage 3的關鍵因素，可以看出這是一項需要持續實施的實踐要素。標準化技術棧對簡化依賴和降低複雜度有很好的效果，而在業務層面也會在諸如license的成本上有所降低。

解讀：
對技術棧進行規範和標準化，從長遠來看會收到很好的效果。但是對於擁有複雜度很好的老舊系統，如何進行實施才是關鍵所在，影響太大，改動成本過高往往是現實世界中的阻礙所在。構建標準化的技術棧，勢在必行，但是如何推動，以什麼樣的規劃進行才是更應該考慮的。
另外，構建規範的技術棧，不應該侷限於某一個應用或者服務，應該著眼全域性，從整體角度進行考慮，也是這份報告所給出的一個建議。

應用配置納入配置管理

應用開發應該進行版本管理，這包括程式碼的版本管理以及應用配置資訊的版本管理。

解讀：
應用配置進行版本管理，可以從如下幾個方面進行理解：

• 應用部署的環境不同並且複雜，導致應用配置可能會有所不同
• 不同的應用配置，相同的應用程式碼，程式碼和配置資料進行分離是一種常見的對應方式
• 應用配置不僅僅著眼於快速的部署和靈活應對各種環境，可回滾也是進行版本管理的一個主要著眼點

在部署至生產環境之前測試基礎框架變更

這項實踐內容在這個階段和Stage 3均有出現，不同的是實施的程度有所不同。在此階段對於測試基礎框架變更所涉及到的內容僅僅為不需要手工的批准，主要目標在於團隊的自制，獲得許可權和責任是這個階段需要注意的。
這些實踐往往都是貫穿於各個階段的，不同的階段所側重的角度不同，這也是在實踐的不斷深入所應該考慮的問題。

原始碼對其他團隊可見

原始碼對於其他團隊可以見，可以使得不同團隊更好的進行參考和借鑑，也是分享文化的一種具體體現，在這個階段中這是一種將區域性的成功經驗進行復制擴充套件的有效方法。

Stage 2: 推進標準化&降低不一致性因素

標準化的推進是一個持續的過程，而那些不同的特性或者說不一致的因素往往會成為實踐過程中的阻礙，而這些不一致的要素往往是由於多種原因導致的，比如：

• 新的技術不斷實踐，但是舊有的技術棧也不進行移除，導致很多非標準的不一致因素的存在
• 土生土長的架構沒有考慮到行業共同的標準和規範，自成一派
• 企業合併與收購導致的不一致性
• …

實踐內容

此階段主要從如下兩點來進行推進：

• 構建標準的技術棧

團隊需要使用可重用的部署模式，標準的技術棧所解決的問題就是降低依賴行和複雜度。可以簡單地使用諸如如下的問題進行自檢：

• 是否所有的服務都是在相同的架構上進行構建？
• 是否這些服務使用相同的訊息佇列？
• 他們是否使用相同的組建和模式？
  當你的答案中出現No的時候，這些非標準化的不一致性會給系統帶來更高的複雜度和更多的維護成本負擔。

解讀：團隊對技術棧進行標準化和簡化意味著很多，而且能夠帶來很多收益比如：

• 更快的交付速度
• 降低安全脆弱性的簡單的共通性問題
• 學習曲線更加平滑，維護和升級更加容易…

• 在標準的單一作業系統上進行部署

作業系統及其版本的不同往往對運行於其上的應用程式有較大的影響，這裡的影響並不是業務層次上的影響，而是在NFR角度的考量，而當組織使用單一作業系統或者範圍可控的作業系統級是，部署的效率更得到很好的提升。同時能夠降低在系統安全補丁/調優/升級/故障排查等方面所消耗的時間。
整體來說，在作業系統的規範層面相關建議如下：

• 即使無法保證在單一作業系統上執行服務，減少到最低限度總是好的
• 在單一的作業系統上也儘可能地降低不一致性的存在

解讀：
活用目前所擁有的技術棧是一個很好的建議。技術本身往往沒有好壞之分，只有合適和不合適，即使是那些看起來很合適的技術，也需要考慮到引入之後帶來的成本考量，比如根據資料庫特性不同匯入了MongoDB/Mysql/Oracle/Postgresql同時在一個系統之中明顯不是一個好主意，這極大地增加了運維的複雜度，同時使得系統正常執行起來說需要的基礎知識範圍大幅度的擴寬，溝通的成本和時間也往往會大幅提升，而簡化往往能夠使得這些都不在是問題。
放棄的技術並不一定是不好的技術，規範和簡化技術棧以提高效率是非常重要的一環。

關鍵因素

為了保證此階段獲得成功，對於結果影響最為重要的關鍵因素如下所示：

• 重用構建和部署應用和服務的模式
• 基於業務需求對應用進行架構重構
• 將系統配置納入版本管理之中

重用構建和部署應用和服務的模式

在這個階段的重用其實還是非常的簡單的，而沒有考慮到過過多複雜的因素，簡單程度上的重用是這個階段的。而關於詳細的展開，在Stage 3中還會有進一步的陳述。

基於業務需求對應用進行架構重構

標註化技術棧帶來的結果往往是需要對既有的應用進行重構，在這個過程中可能是使用開源的元件或者商業的產品來代替以往專案中愈加難以維護和更新的自由行開發的舊有元件。

解讀：這是一個說起來更加容易的實踐，目的是希望有更快的速度和更好的可維護性。技術債務需要不斷償還，而且好的狀態需要不斷的維護。

將系統配置納入版本管理之中

在這個階段中，對系統級別的配置管理進行版本管理會給基礎框架的開發和維護提供一個非常良好的基礎，這也是“基礎框架即程式碼”的基礎實踐所要求的範疇。
系統配置納入版本管理會帶來很多好處，比如：

• 可以變更相關的詳細資訊，不同時間的變更和發起者等都能夠被追蹤
• 任何具有對版本控制系統具有許可權的人員都能對變更進行確認
• 關鍵的備至管理檔案能夠得到備份，從而具有可回滾的基礎

Stage 3: 擴充套件DevOps實踐

在前面的兩個Stage的基礎之上，整體程度上技術棧的複雜度和不一致性得到了有效的降低，為這個階段的DevOps實踐提供了很好的前提條件。
隨著各個團隊合作的深入，聚焦於各個部分的改進使得團隊開始在技術應用之外進行了更深入的協作，分享工具的改進，應用/服務/以及知識等等，這些推動了DevOps實踐在組織中的擴充套件。

實踐內容

此階段主要從如下三點來進行推進：

• 團隊成員工作無需團隊外部的人工批准

解讀：
這點主要的目的是為了賦能團隊，降低組織官僚化的冗長流程對效率造成重大損害。在實際實施的過程中達到目的即可，流程的審批需要的時候，可以考慮責任下放，使得團隊中的Leader有審批有權利和責任即可。
另外根據前幾年的調查報告顯示：這些外部的人工審批對於系統的安定性有著幾乎可以忽略的影響，換句話說，額外的人工審批不會使系統更加安全，可能只會使審批者心理上更加放心而已。

• 重用構建和部署應用和服務的模式

解讀：
相比較於前一個階段的同樣的實踐，這裡的要求就嚴格的多。簡單來說，哪怕你只有兩個軟體專案要進行釋出，需要使用相同的方式，而不論是發不到開發/測試/準生產還是生產環境。
在這個階段很多具體的實踐都會根據組織技術棧和流程進行標準化的重用，比如：

• 使用標準的方式去指定所要部署的物件環境
• 與CI的持續整合進行結合
• 部署的步驟可以進行標準化或者定製化
• 部署的方式可能是藍綠或者其他方式
• 可以重用一條流水線對不同的應用進行釋出
• …

• 在部署至生產環境之前測試基礎框架變更

解讀：
在這個階段，對於基礎框架並不需要整合到CI中進行全自動，而是要把重點放到對基礎框架功能的驗證上，而手工完全可以保持。
因為基礎框架的變更範圍非常廣泛，對其進行自動化，引入infrastructure-as-code的方式進行管理也是需要成本的，而在很多時候，對絕大多數情況來說，這些並沒有那麼的頻繁（當然對於那些雲伺服器的服務商來說完全不同了），所以結合手動作業，主要對基礎框架的變更進行驗證的方式是這個階段推行的重要方式。

關鍵因素

為了保證此階段獲得成功，對於結果影響最為重要的關鍵因素如下所示：

• 團隊成員可以進行變更對應而不會有過多的等待時間
• 服務變更可以在業務時間內對應
• 進行事後檢查和評審並分享相關結果
• 團隊在標準的技術棧上進行構建
• 團隊進行持續整合實踐
• 基礎框架團隊使用版本管理

團隊成員可以進行變更對應而不會有過多的等待時間

解讀：
雖然這期所給出的CAMS模型裡面沒有L（Lean），但是這就是典型的精益實踐之一，消除等待的浪費。是對整體過程的一個簡化，當然實際實施時需要考慮到很多因素，比如：

• 在整體不會出現很多問題的情況下進行實踐，比如部署成功率已經很高，很少出現問題和意外
• 消除等待時間應該與實際業務需求相結合，確認是必要還是可選

服務變更可以在業務時間內對應

解讀：
在業務時間進行服務變更，保證服務不中斷，建議從如下角度進行實踐：

• 流程：等待時間大幅度降低情況下進行
• 架構：考慮藍綠部署等方式降低影響
• 時機：定義出業務時間結合業務影響度，即使是24小時無終止的服務，業務影響度也會有所不同，選擇影響程度最低的時間段
• 預演：在準生產環境上進行驗證能力
• 回滾：事前準備回滾方案並進行驗證
• 試點：先選擇影響度小的專案作為試點

進行事後檢查和評審並分享相關結果

解讀：
時候檢查仍然是CAMS中S（分享）相關的具體實踐，實施時需要注意如下幾個要點：

• 免責方式進行：去年的gitlab給出了一個很好的案例，看一下他們把關鍵資料丟失的員工的進行了什麼樣的懲罰就知道了。
  其實也很好理解，出現的問題往往只是冰山的一角，對於可能出現的問題，大部分人在自身安全不能得到保證的情況下，免責還是不免責可能就是出現問題有可能會藏起來不說還是說的區別，這是人的本性，無可厚非。
  有些組織在構建企業文化時，一邊拿著鞭子抽打，另一方面期待員工能夠為公司殫精竭慮，所有問題都能暢所欲言，不太現實。
• 相關干係人蔘與並將結果進行公示，一方面可以增進信任，公開比隱藏個能獲取相關干係人的信任。另外一方面，對於其他沒有直接關聯的成員，這些公佈的內容也是值得學習和借鑑的內容。

團隊在標準的技術棧上進行構建

解讀：
構建標準的技術棧，這個實踐要點也是一個持續性的行為，在不同階段都需要進行考慮，自然在擴充套件的階段也不能避免。好不容易打下的基礎，簡化的技術棧，在擴充套件的時候重新變成複雜度和不一致性都很高的高技術負債的狀況，就說明擴充套件的方式出現了問題。

團隊進行持續整合實踐

解讀：
持續整合已經成為版本管理之後，最需要進行實踐的內容之一。但是需要注意的是，持續整合本身也需要維護和優化，也是一個長期的過程。

基礎框架團隊使用版本管理

基礎框架團隊使用版本管理在這個階段和後續的階段都是非常重要的，將基礎框架的變更和管理也納入版本管理的範疇也會對整體實踐的推進有非常正向的影響，詳細會在後續階段進行說明。

Stage 4: 自動化基礎框架交付

自動化基礎框架的交付並非是到了這個階段才能去實施的階段，在經過前面階段的規範化/標準化/簡化以及擴充套件之後，這個階段可以進行更為全面的基礎框架相關的自動化了。

實踐內容

此階段主要從如下四點來進行推進：

• 自動化系統配置
• 自動化設定
• 應用配置納入版本管理之中
• 基礎框架團隊使用版本管理

自動化系統配置

解讀：
自動化系統配置一般意味著系統的構建不是通過手工，而是通過得到版本管理的設定檔案和指令碼，整體通過一個自動化的框架（比如Puppet/Ansible，雖然報告中沒有寫出來，但是已經非常明顯了，有整整一個Stage來進行自動化基礎框架，而前面幾個Stage都是用來鋪墊和準備）
整體來說，系統配置自動化能帶來很多收益，比如：

• 更加快速應對變更
• 更快的整體交付速度
• 環境一致性得到保證
  …

另外，關於對那些系統配置項進行自動化，自然需要考慮到ROI，使用頻度高的並且實現簡單的自然應該有限考慮，同時也需要可簡化或優化流程結合起來以達到更好的效果。

自動化設定

解讀：
與自動化系統配置相結合，自動化設定實踐能夠使得專案成員通過自服務功能來對基礎框架進行操控。當然，使用頻度最高的專案應該是優先考慮的，同時自動化設定在後續階段中也是重要的實踐內容。

應用配置納入版本管理之中

解讀：
應用程式原始碼在版本管理控制之中，但是應用程式配置資訊同樣應該納入管理，那些使用了諸如12-facotr的應用，相關的配置資訊的管理也原始碼一樣同等重要。

即使沒有使用12-factor，應用配置資訊需要進行規範化和標準化，至少避免以硬編碼的方式存在與應用程式之中，這種最基本的程度是需要做到的。系統運維人員登入到生產環境之中，手工修改設定檔案或者資料庫然後重啟系統等這種手法在目前的階段已經不再是一個備選項了。應用程式的配置應該得到管理，能夠進行審計，包含前因後果，像程式碼一樣進行嚴格管理

基礎框架團隊使用版本管理

解讀：
基礎框架團隊使用版本管理是對包含基礎框架在內的整體進行持續交付的基礎。納入版本管理之後後很多的收益，比如

• 更加容易建立開發或者測試環境
• 更加容易重建測試環境用於問題定位
• 縮短生產環境的故障恢復時間
• 更好地提供Audit所需資料和功能
  …

關鍵因素

為了保證此階段獲得成功，對於結果影響最為重要的關鍵因素如下所示：

• 自動化安全策略配置
• 資源可以通過自服務獲取

自動化安全策略配置

解讀
除了普通的安全策略之外，組織往往需要強制性的滿足一些外部的Audit規範諸如：

• Sarbanes-Oxley
• Payment Card Industry Standards (PCI)
• NIST
• General Data Protection Guidelines (GDPR)
• …

在實際推行的時候需要注意：

• 這些安全策略在團隊層面意味著什麼和如何遵從和檢測
• 逐步推行循序漸進地完成安全策略檢測的方式，可以是從最簡單的一個指令碼開始和完善
• 可以通過一些外部的工具對安全性和脆弱性進行掃描和分析

脆弱性例項：OWASP Top 10（2017）

• A1:2017-Injection
• A2:2017-Broken Authentication
• A3:2017-Sensitive Data Exposure
• A4:2017-XML External Entities (XXE)
• A5:2017-Broken Access Control
• A6:2017-Security Misconfiguration
• A7:2017-Cross-Site Scripting (XSS)
• A8:2017-Insecure Deserialization
• A9:2017-Using Components with Known Vulnerabilities
• A10:2017-Insufficient Logging&Monitoring

資源可以通過自服務獲取

通過自服務獲取資源能更好地提高效率，在後續的Stage中對相關的實踐有更多的闡述。

Stage 5: 提供自服務能力

這個階段的實踐需要對IT能力進行重新的理解，需要不同團隊（開發/運維/資訊保安/ITSM和其他職能團隊）共同協作來提供IT能力，整體的方式是將這種能力進行服務化以提供給業務層面，而不再是將IT作為一個對應工單的成本中心。
而通過這個階段的實踐，一些新的收穫將會顯現，比如：

• 應用架構開始在標準化的技術棧上慢慢融入Cloud/容器化/微服務等
• 安全策略的自動化從滿足團隊需要到變成組織級別可衡量的基線
• …

實踐內容

此階段主要從如下四點來進行推進：

• 自動進行事件響應
• 資源可以通過自服務獲取
• 根據業務需要進行應用架構重構
• 安全團隊融入技術設計和部署階段

自動進行事件響應

解讀：
事件的響應是人工還是自動在效率上差別很大，比如以ALIEN VAULT所舉的例子進行說明：

• 對於可疑的IP的自動檢測和封IP自動響應：有些組織需要先發起工單，進行審批與核准，然後才能進行事件響應，缺乏實效性
• 被感染了病毒的伺服器的隔離：如果無法自動隔離，則很容易喪失最佳對應時間點

風險：
自動事件響應是好的，但是誤響應的風險也是巨大的，比如可疑IP的自動檢測，將新的大客戶的IP自動封起來之後影響也是巨大的，平衡與折衷，循序漸進的推進都是這個過程中需要考慮的。

資源可以通過自服務獲取

自服務帶來的好處不言而喻，就像這份報告所提到的那樣：

This is exactly what the data shows successful teams do.
Comparing our Low and High evolutionary cohorts, we see this exact shift from a high proportion of self-service systems for internal team usage towards multiple teams collaborating to deliver systems that will be broadly consumed across the organization.

自然，從資料上來看，對於自服務(self-service)的踐行，Low/Medium/High分別的比例是3%/5%/8%，確實是非常明顯地是隨著成熟度的增高自服務程度在逐漸提升的一個結果

注：看原文的話，會發現這份資料在Page 28已經使用了，但是跟這裡的區別是Low evolution的比例是8%，如果是這個資料的話，這裡的結論就很難找到資料的支撐。而且簡單地進行分析，本身Low evolution的資料相比與其他兩種，總和就不是100%，這個資料本身就存在問題，所以個人認為這個值的真實資料應該是7%。
但是無論什麼樣的資料，是什麼就應該展現什麼，準備發信問一下DORA。但是無論是什麼樣的資料，自服務的趨勢是整體的方向這個應該是沒有問題的，只是可能在大家都在起步的階段的時候，資料不足以對其提供支援而已，可以從後續的報告中進行進一步的確認，而不是修改資料去契合結論。

根據業務需要進行應用架構重構

解讀：
在Stage 2的時候此項實踐同樣出現，不同的是前面的階段中架構的重構所引起的原因是因為標準化技術棧所引起的，往往是很大程度的對應，比如資料庫種類的變化以及作業系統有多個變成了一個。
而這個階段則是整體的改善，比如12-factor規範的實踐等等，不同的階段考量的因素不同，架構的改善應該貫穿與整個過程。

安全團隊融入技術設計和部署階段

早在2016年的報告中，就發現了高效的組織在安全相關的問題上所花的時間只有抵消組織的50%，這是因為安全相關的因素已經在交付的過程中被考慮進去了。整體來說，安全需要更早的被引入到交付的流程之中，包括：

• 在保證不會拖慢開發進度的情況之下，對所有主要特性都進行安全評審的流程
• 整合資訊保安機制到每日的工作之中
• 將對安全需求的檢證作為自動測試過程的一部分
• …

組織不同角色對自動化的認識一致性較高

不同的角色在DevOps實踐中對同一問題的看法往往存在gap，而對於自動化相關的看法，調查的結果顯示，分歧非常之小。

關鍵因素

為了保證此階段獲得成功，對於結果影響最為重要的關鍵因素如下所示：

• 安全策略配置是自動化的
• 應用開發者自己部署應用到測試環境
• 專案的成功指標是視覺化的
• 自動化設定

安全策略配置是自動化的

解讀：
安全策略的自動化自所以在比較靠後的Stage進行，主要的原因是這是一塊難啃的骨頭，相比較於安全問題一旦出現所需要的成本，這一切都是值得。在如下的文章中對可以看到安全問題所需要付出的成本：（https://blog.csdn.net/liumiaocn/article/details/77646024）

應用開發者自己部署應用到測試環境

開發團隊成員能夠按需將開發的應用部署到測試環境時，由於無需進行環境的等待等，應用交付的流程將會更快，而運維團隊由於從大量的環境配置的重複性勞動中解放出來了，則可將精力投入到系統性能的優化上。但是前提是需要這種自服務的功能的提供不是從天而降的，需要投入一定的人力和成本的。

專案的成功指標是視覺化的

關心什麼，你就會得到什麼。KPI指標的視覺化非常重要，但是更加重要的是明確地定義以及對參與者可以隨時獲得資訊分享的途徑。

總結

今年的報告給出的最為重要的內容就是5-stages的推進方式，對於那些初步進行了一些實踐但是仍然覺得在擴充套件方面有問題的組織來說應該有一定的借鑑意義。

附錄1: 2017年DevOps報告解讀

附錄2：Take Away：5 Stages具體內容

參考內容