合適的切入點，是DevOps轉型成功地關鍵。數字化時代下，企業需要更快更靈活的交付來支持業務運營，這種迫切地需求促成了DevOps的高速發展，成爲企業獲得競爭優勢的關鍵。
儘管大家都知道DevOps能推動業務，但DevOps落地過程中極易踩坑，最終導致DevOps轉型失敗，因此許多企業仍然難以從中獲益。
本次直播介紹了DevOps建設的常見路徑，分析各個環節的阻力，挖掘其背後的根源性問題，詳解企業在DevOps轉型過程中如何結合自身實際情況進行建設規劃。
二、DevOps轉型常見的建設路徑
1、推行DevOps的兩種軌跡
- 自底而上
在這種模式下，企業內部DevOps的引入和實踐一般發起於一個小組或者小團隊，他們可能是企業內部DevOps的早期倡導者和實踐者，爲了解決自己團隊內部，或者是和上下游團隊交互過程中的問題。一般這類團隊規模較小，而且內部相關資源調動起來也相對簡單，這種模式比較容易在局部獲得效果。
不過，DevOps的核心在於不同團隊之間的協作，如果只是一個小團隊內部的改進，還不能算是完整的DevOps轉型。
如果企業規模較大，很難一次性改變，需要有一些勇敢的人來嘗試推動這個過程，一種相對比較合適的方式，就是先在自己團隊內部，以及和自己團隊所負責的業務範圍有強依賴關係的上下游團隊之間建立聯繫，一方面不斷擴展自己團隊的能力範圍，另一方面，逐步模糊上下游團隊的邊界，由點到面，打造大家共同的DevOps。
如果想讓DevOps轉型的效果最大化，我們一定要想辦法讓高層看到我們在局部改進的效果，讓高層領導認可這種嘗試和實踐，最終實現橫向擴展，在企業內部逐步鋪開。
- 自頂而下
在這種模式下，企業高層基於自己對於行業趨勢發展的把握，以及對團隊現狀的瞭解，通過企業戰略推行的方式，下達任務目標。在這種情況下，公司領導有足夠的意願來推動DevOps轉型，並願意投入資源給予支持，各個團隊也有足夠清晰的目標，但是在DevOps的推行過程中，不能只是依靠自頂向下的推廣，同時也需要中層的帶動和底層的創新。
若想觀看完整直播回放，請掃描下方二維碼↓
2、DevOps建設的演進路徑
DevOps建設的演進路徑一般有三個階段：
- 自動化
DevOps的實施，一般先從自動化入手，通過從需求管理到上線部署的工具鏈平臺建設，驅動研發效率、質量、管控的提升，實現通過工具來驅動研發。
- 數據化
當有了支撐研發交付過程的工具鏈之後，通過基於研發全過程的數據度量分析，面向不同角色提供關鍵指標，推進研發全過程的持續改進，實現通過數據驅動持續改進。
- 一體化
當以數據作爲支撐而進行的持續改進，讓整個研發過程的效率和質量實現了大幅的提升後，此時通過研發運維一體化與業務進行緊密結合，實現對業務的快速響應，最終不斷增強企業的業務在市場上的競爭實力。
二、DevOps轉型中的常見障礙
1、業務部門不關注研發部門如何工作的
由於IT交付最終是面向業務交付的，如果業務部門不關注研發部門是如何工作的，那麼很可能會導致IT交付的效果和質量沒有保障。
因此，需要讓業務部門參與進來，讓他們瞭解在DevOps模式下是如何工作的，和之前有什麼不同，可以帶來什麼樣的效果，同時需要業務部門給研發團隊提供對需求理解的幫助，幫助研發團隊實現更有價值的需求交付。
2、管理層缺乏對DevOps的深入理解
如果企業的管理層缺乏對DevOps的深入理解，那麼DevOps團隊很難獲得企業高層的支持。
因此可以對高層領導提供DevOps相關的理念和知識培訓，最終才能更好的爭取領導層的支持。
3、你說的都對，但是我們沒有時間改進
在DevOps推行的過程中，可能些有團隊由於手頭上的工作內容或者問題比較多，本身就有點手忙腳亂，他們會提出沒有時間改進。
因此，這種情況我們可以換個思路，告訴相關成員，其實解決質量問題，提升效率，也是可以創造出時間的。
4、大家都覺得沒有什麼需要改進的了
有些團隊可能認爲當前在交付的過程中一切都還行，沒什麼大問題，沒有什麼需要改進的。
這時，可能我們需要通過一些問題現象或者邏輯的溝通論證，證明當前的流程和方式是存在問題的，是有提升效率和質量的空間的。
5、一開始就把面鋪得太廣戰線拉得太長
在轉型初期資源由於投入有限，難以支撐大量任務並行，且團隊之間的各種問題慢慢暴露出來也需要時間消化。
因此，可以分階段設立目標，先在部分部門實施轉型，等改進成功後再逐步擴大。
6、在不改變現有流程下推行DevOps
從組織和文化層面來看，其實DevOps是一種文化和流程的變革，如果直接在現有的流程框架下去推行，不能把相關團隊之間的協作調動起來，不將整個過程貫通，最終是無法推行下去的。
因此，實施DevOps轉型，不是一個人的事情，是所有人的事情，從思維，技術，流程都需要進行變革。
7、轉型團隊缺乏相關的理論和實踐經驗
DevOps轉型的潮流洶湧，但是有些團隊可能缺乏相關的理論和實踐經驗。
這個時候我們可以通過學習一些書籍、參加一些大會、分析一些企業案例來補充相關的知識和經驗。
8、缺乏統一的工具鏈平臺作爲支撐
DevOps轉型需要工具平臺的支撐，有些團隊可能更多的成員是被安排在業務開發上，並沒有過多的資源在工具平臺的研究和開發上，或者有些小團隊可能自己零零散散的弄了一些工具。
因此，搭建統一完整的工具鏈平臺來作爲支撐，是轉型過程中重要的一步。
三、避免文化、組織、工具中的坑
前面我們梳理了一些DevOps轉型過程中常見的障礙，這些障礙總結起來主要涵蓋三個方面：
- 文化的坑：文化不是流程與形式，而是共同的目標與利益
精益和敏捷爲DevOps理念提供了很好的理論指導和工具支持，近年來很多公司逐漸開始進行敏捷轉型。
例如：項目經理變成了Scrum主管，用戶故事替代了以前的需求，開發計劃變成了更短的衝刺計劃。以前每週一次的會議變成了每日站會，一開始大家都精神滿滿，久而久之覺得每天的站會太麻煩，錄入需求要時間，開站會需要時間，如果此時開發任務繁重、人員不足，這些繁瑣的流程就應該儘可能簡化，同時應該分析各成員的工作負載，合理的分配任務和資源，把大家當下的共同目標統一併明確起來。
- 組織的坑：尋求管理層認可和支持是DevOps轉型的關鍵
如果沒有管理層的支持，DevOps的轉型之路將會困難重重。因爲無論在什麼時代，變革一直都是一場勇敢者的遊戲，對於一家成熟的企業而言，無論是組織架構、團隊文化，還是工程能力、協作精神，都是長期沉澱的結果，而不是在一朝一夕間建立起來的。
DevOps在企業內部實施時，要形成以企業高層如：CIO，業務部門和科技部門共同組成的DevOps轉型小組，DevOps轉型會使得之前的組織結構發生很大的變化，將之前的大部隊作戰方式，轉型爲一個一個的小團體進行作戰，這樣會更加機動靈活。
- 工具的坑：讓需求流動起來才能更大程度發揮工具的價值
DevOps工具鏈的建設，是實施DevOps轉型的第一步，有很多人認爲，有了工具就實現了DevOps。
其實，一般的工具都只是滿足某一個階段的需求。比如，用jenkins來做持續集成，用Jira來做項目管理，用gitlab來管理源代碼。有了工具並不能說就實現了DevOps，雖然通過工具確實能提高某些階段的效率，但DevOps最終的目標是爲了提高企業整體研發流程的效率和質量。
因此，我們需要讓需求流動起來，並通過不斷的反饋和持續改進優化，才能最終實現既快速，且高質量的價值交付。
四、關於DevOps轉型之路的思考
1、經典的DevOps三步工作法
來自《DevOps實踐指南》的經典三步工作法：
第一步：流動原則
實現開發到運維的工作快速地從左向右流動。爲了最大程度地優化工作流，需要將工作可視化，減少每批次大小和等待間隔，通過內建質量杜絕向下遊傳遞缺陷，並持續地優化全局目標。
第二步：反饋原則
在從右向左的每個階段中，應用持續、快速的工作反饋機制。通過反饋機制，防止問題復發，並能縮短問題檢測週期，實現快速修復。能夠創造出組織學習與改進的機會。
第三步：持續學習和實驗原則
建立具有創意和高可信度的企業文化，支持動態的、嚴格的、科學的實驗。通過主動地承擔風險，不但能從成功中學習，也能從失敗中學習。幫助團隊快速並自動適應不斷變化的環境，進而幫助企業在市場競爭中脫穎而出。
2、關於價值流的三個關鍵要素
來自《DevOps實踐指南》的關於價值流的三個關鍵要素：
- 前置時間（Lead Time，簡稱 LT）
前置時間在 DevOps 中是一項非常重要的指標。具體來說，它是指一個需求從提出（典型的就是創建一個需求任務）的時間點開始，一直到最終上線交付給用戶爲止的時間週期。這部分時間直接體現了軟件開發團隊的交付速率，並且可以用來計算交付吞吐量。DevOps 的核心使命之一就是優化這段時長。
- 增值活動時間和不增值活動時間（Value Added Time/Non-Value Added Time，簡稱 VAT/NVAT）
在精益思想中，最重要的就是消除浪費，也就是說最大化流程中那些增值活動的時長，降低不增值活動的時長。在軟件開發行業中，典型的不增值活動有很多，比如無意義的會議、需求的反覆變更、開發的缺陷流向下游帶來的返工等。
- 完成度和準確度（% Complete/Accurate，簡稱 %C/A）
這個指標用來表明工作的質量，也就是有多少工作因爲質量不符合要求而被下游打回。這裏面蘊含了大量的溝通和返工成本，從精益的視角來看，也是一種浪費。
3、梳理企業內部的交付價值流
- 企業內部價值流程梳理會議
對於大型企業而言，開展企業內部價值流梳理會議時，可以選擇處於改進中的項目裏某個核心的業務模塊，同時參加會議的人員需要覆蓋軟件交付的所有環節。而且，參會人員要儘量是相對資深的，因爲他們對自身所負責的業務和上下游都有比較深刻的理解，比較容易識別出問題背後的根本原因。
不過，這種方式的實施成本比較高。畢竟，這麼多關鍵角色能夠在同一時間坐在一起本身就比較困難。另外，面對面溝通的時候，爲了給對方保留面子，大家多少都會有所保留，這樣就會隱藏很多真實的問題。所以，一般情況下，像團隊內部的敏捷回顧會，或者是版本發佈總結會，都是很合適的機會，只需要邀請部分平常不參會的成員就行了。
- 內部人員走訪
如果第一種方式難以開展，我們可以採用第二種方式。通常來說，企業內部的 DevOps 轉型工作都會有牽頭人，同時會成立轉型小組，那麼可以由這個小組中的成員對軟件交付的各個環節的團隊進行走訪。這種方式在時間上是比較靈活的，但對走訪人的要求比較高，最好是 DevOps 領域的專家，同時是企業內部的老員工，這樣可以跟受訪人進行比較深入的交流。
無論採用哪種方式，我們都需要識別出幾個關鍵問題，縮小談話範圍，儘量做到有效溝通，可通過提前建立一個調研問題列表來達到收集關鍵信息的目的。
通過訪談交流，我們就可以對整個軟件交付過程有一個全面的認識，並根據交付中的環節、上下游關係、處理時長、識別出來的等待浪費時長等，最終整理出當前部門的價值流交付圖。
4、尋找DevOps轉型合適的切入點
第一步：尋找合適的試點項目
試點項目是企業內部最初引入DevOps實踐並實施改進工作的業務對象，一個合適的項目對於企業積累DevOps實踐經驗是至關重要的，一般一個合適的項目應該具備以下幾個特徵：
- 貼近核心業務：DevOps要以業務價值爲導向，對於核心業務，管理層的關注度足夠高，各項業務指標也相對比較完善，如果改進效果可以通過核心業務指標來呈現，會更有說服力。同時，核心業務的資源投入會有長期保障。畢竟，我們肯定都不希望DevOps轉型落地項目因爲業務調整而半途而廢。
- 傾向敏捷業務：敏捷性質的業務需求量和變更都比較頻繁，更加容易驗證DevOps改造所帶來的效果，如果一個業務以穩定爲主要訴求，整體處於維護階段，變更的訴求和意願都比較低，那麼這對於DevOps而言，就不是一個好的選擇。
- 改進意願優先：如果公司內部的團隊認爲當前狀況一切都非常好，完全瞧不上DevOps，覺得自己當前的流程是最完美的，再跟他們費力強調DevOps的價值，結果很可能事倍功半。相反，那些目前績效一般般的團隊都有非常強烈的改進訴求，也更加願意配合轉型工作。這時，團隊的精力就可以聚焦於做事本身，而不會浪費在反覆無效的溝通上。
第二步：尋找團隊痛點
找到合適的團隊，有了共同改進和意願，接下來就需要識別團隊的痛點了。所謂痛點，就是當前最影響團隊效率的事情，同時也是改進之後可以產生最大效益的事情，至於如何找尋痛點，我們可以參照上面講的價值流分析活動。
第三步：打造可快速成功的改進點
當我們找到了合適的團隊，也通過價值流分析識別出了一大堆需要改進的事項，這個時候，一定要注意不要把面鋪得太廣，把戰線拉得太長，這其實是DevOps轉型初期最典型的一個坑。
首先，轉型初期一般資源的投入有限，難以支撐大量任務並行。其次，由於團隊成員之間還沒有完全建立起信任關係，那些所謂的最佳實踐很容易水土不服。如果生搬硬套的話，很可能會導致大量摩擦，從而影響改進效果。最後，管理層的耐心也沒有想象中那麼多，如果遲遲看不到效果，很容易影響後續資源的投入。
所以，最關鍵的就是識別一個改進點，定義一個目標。比如，測試執行效率，那麼就可以定義這樣一個指標：測試執行效率提升50%。這樣一來，團隊的目標會更加明確，方便任務的拆解和細化，可以在幾周內見到明顯的成果。
第四步：快速展示成果
當我們在轉型實施的過程中取得階段性的成果之後，要及時向管理層彙報，並且在團隊內部進行總結，這樣，可以增強管理層和團隊的信心，逐步加大在DevOps上的資源投入。
第五步：持續優化改進
在DevOps轉型過程中，通過及時發現改進過程中的問題，在團隊內部形成持續學習的氛圍，激發團隊成員的積極性，可以從側面改善團隊的文化，更有利於DevOps在企業內部的推行。
以上就是今天關於DevOps轉型的過程中的一些常見障礙和企業如何盤點自身情況並選擇合適的轉型切入點內容分享，DevOps轉型的過程雖然很艱難，但我相信只要我們找準了目標和方向，並且朝着這個方向堅持前走，就一定能夠逐步的達到我們想要的效果。