如何避免DevOps變革的六大「焦油坑」

當今，DevOps能顯著提高企業的商業敏捷與能力，所以在企業中廣受歡迎。然而，對於大多數企業來說，DevOps變革並不是一路順風，此過程當中會面臨各類各樣的挑戰。爲了提升DevOps變革成功的可能性，企業領導者亟需識別或者理解DevOps變革失敗的常見緣由，並採起必定的措施來避免。

通過不斷髮展，DevOps逐漸演變爲一種方法框架，使能企業綜合運用人員（People）、流程（Processes）與技術（Technologies）等，從而將價值持續交付給最終客戶與用戶。基於DevOps的價值觀（Value）、原則（Principles）與實踐（Practices），華爲雲DevCloud分析了許多企業的DevOps落地案例，DevOps變革會存在6大常見的主要緣由，稱之爲六大「焦油坑」：

• 無的放矢

• 烏合之衆

• 各自爲政

• 一蹴而就

• 好高騖遠

• 沙上建塔

無的放矢：未從客戶價值出發

在DevOps熱潮下，許多組織一般爲了趕潮流而快速啓動DevOps變革，經常爲了DevOps而作DevOps（Doing DevOps for DevOps），而沒有充分考慮DevOps的真正目標或者目的。員工只會關注爲組織帶來的價值，而不會單純與DevOps術語、方法以及支撐工具產生聯繫。所以對DevOps變革，不管變革啓動時，仍是變革過程當中，都須要將爲客戶帶來的商業價值做爲目標，以便不斷調整DevOps變革內容。這也與多數組織「以客戶爲中心」的理念相吻合，然而卻常常被忽視甚至忘卻，致使無的放矢或者向不正確的靶子放矢。

爲了使DevOps變革立足於客戶價值、充分識別誰是客戶、他們須要的價值是什麼，組織應該常常思考以下問題：

• 現有或者潛在的客戶是誰

• 客戶看重或想實現的商業價值是什麼

• 企業能提供哪些服務，仍有哪些差距

• 客戶指望的時間點

• 企業可以多快進行發佈

• 客戶前進的方向是什麼，如何升級企業的服務

• 如何讓客戶瞭解到企業提供了什麼

企業組織在DevOps實施過程當中，必須以客戶爲中心，持續地提升對客戶商業價值的理解，來做出相應的改變，並提高自身能力。

烏合之衆：未有效地管理組織變革

在DevOps變革中，企業組織應該認識到人或團隊是DevOps變革的最大的挑戰，於是應該充分重視組織變革的重要性，而不是將重心聚焦在工具上。企業應該從理解客戶商業價值來發起組織變革，領導層必須清楚DevOps以及相應的組織變革是不可或缺的，員工必須認識到變革正在發生。在DevOps變革中，領導層應該理解，爲了提高商業敏捷性，決策須要在信息產生的地方進行，並應該去身體力行此種決策理念。

所以，領導層須要組建團隊，並讓團隊本身決策應該作什麼以及如何作。這就要求在組織內識別潛在的候選人，且候選人應該具備如下價值觀：

• 團隊合做：確保候選人樂於團隊合做，而且在團隊內工做效率高；

• 值得信賴：信任是DevOps的CAMLS理念中文化的基本要素之一，所以候選人必須可靠、可信；

• 幹勁十足：候選人必須能主動積極地追求目標；

• 有責任心：對工做過程、工做產出能負起責任，而不是推三阻四；

• 足夠聰明：能理解必須完成的工做，並能夠決定如何開展；

• 經驗豐富：經驗可使團隊成員成長，固然不必定對DevOps有經驗；

• 有效溝通：及時準確地口頭或者書面傳遞信息與知識；

• 風險管理：與團隊其餘成員（例如PO）協同工做懂得如何管理風險；

• 終身學習：DevOps並不是一成不變，所以更重要的是，發現有正確態度的人並培訓技術技能，而不是過度強調技術技能而忽略錯誤的行爲。

領導者應具有相應的技能與態度來激勵員工，進行受權並提高他們的責任感。固然，對於拒不改變的員工，必須絕不遲疑地將他們安排到不會動搖變革的崗位上。

各自爲政：未充分地合做

在DevOps變革過程當中，比較現實的狀況是單個職能領域（例如IT部門）來發起此變革，所以致使DevOps實施侷限於單個職能領域，無形中增長了變革失敗的可能性。

所以即便單個職能領域發起DevOps變革，組織必須意識到成功的DevOps實施須要全部干係人共同合做以更全面地理解並系統地解決問題。爲了加快價值實現時間，DevOps團隊必須與其餘團隊及關係人合做。DevOps須要人們共同工做實現解決方案，打破障礙，並能像小型團隊同樣運做。所以，合做是至上的，團隊的大小並無絕對的限制，雖然業界有所謂兩個比薩（Two-pizza）團隊的說法。

更爲重要的是，企業級別的合做須要管理層的支持。在一開始，就應該得到管理層的支持與擁護。DevOps的擁躉必須相信DevOps的價值，並平衡組織內不一樣團隊的激勵方式，例如開發團隊被鼓勵快速變動和開發新特性，而運維被鼓勵維持可靠性和穩定性，這樣就難以造成合做。

一蹴而就：未採用迭代方法

全面的一攬子的DevOps變革，對於大多數企業組織來講，是很是有誘惑力的。然而，歷史經驗卻無情地告訴咱們，這種傳統變革失敗率很是高。DevOps要在一個大型IT組織中成功，涉及太多因素，而且組織越大越困難。

所以，增量迭代方法成爲組織的必然選擇，一方面此方法使組織聚焦於持續改進，另外一方面避免了傳統方法的巨大風險。在進行DevOps變革時，組織聚焦於單一價值流，經過迭代與持續學習來持續改進，來獲得合適的因素維持可接受的變革。迭代增量節奏也使組織確保團隊分享與合做，並創建實踐社區。這樣，在此價值流學到的知識能夠傳遞到下一個價值流，逐漸在組織中規模化DevOps。

組織在每一個迭代中須要仔細識別目標機會，並確保每一個迭代知足如下3個關鍵條件：

• 政策友好性：干係人願意給予DevOps公正的試驗環境，在錯誤發生時，從中學習經驗而不是責備；

• 可接受的價值：每一個迭代產生足夠的客戶價值，來創建信任與獲取支持；

• 可接受的風險：即便DevOps宣稱具備顯著下降風險的能力，然而人們更樂於看到實際效果，而不是簡單聽理論。

好高騖遠：疏於管理指望值

俗話說，指望越高，失望越大。對於DevOps，許多組織的指望與它可以交付的內容存在脫節。與其講企業組織將更敏捷或者快速，不如明確組織如今在哪兒以及須要到哪兒，而後迭代地實現目標。DevOps不是一次性投入，而是須要不斷地嘗試。所以組織須要達成一致的目標與度量指標來有效地管理指望。DevOps的度量指標很是多，建議能夠從如下4個角度創建進度平衡視圖：

• 市場目標：例如銷售量、客戶留存率等；

• 交付週期：價值實現的平均時間；

• 風險管理：宕機時間、業務恢復時間等；

• 客戶滿意度：滿意度水平等；

須要指出的是，並不是全部的不切實際的指望都來自於商業客戶。例如，IT部門會認爲工具鏈是免費的，實際上工具鏈須要持續的資源與投入。整體上，組織須要圍繞客戶價值、成本與風險來權衡創建合適的指望。

沙上建塔：未清晰地管理需求與代碼

因爲受到DevOps成功案例以及CAMLS理念中自動化的影響，企業一般寄但願於自動化等技術與工具手段來加速產品上市週期，然而常常因諸多基礎性工做沒有作紮實致使DevOps實施效果未達到預期。

在諸多基礎性工做中，最爲關鍵的兩點是需求的探索分析與分解、源代碼的版本與分支管理。從DevOps的發展歷史來看，DevOps繼承了敏捷方法的諸多實踐與理念，原則上默認DevOps團隊較充分地掌握了敏捷方法與實踐，也致DevOps組織忽略需求的重要性。所以不管如何強調需求的重要性都不爲過。DevOps團隊必須清晰地管理需求，使需求以及Story知足SMART要求，在迭代週期內能夠按時保質交付最小可行產品（MVP）。

代碼版本管理的重要性是不言而喻的，更須要關注的是良好的分支管理模式是持續集成與持續部署的基礎。企業可使用華爲雲DevCloud進行需求與代碼的管理。

最後，

DevOps變革是一個系統工程，涉及到組織、文化、人員、流程、工具、方法等方方面面。對於企業來說，應該從客戶商業價值出發，選擇合適的團隊，合理地管理指望，並以增量迭代的方法，初始聚焦於單一價值流，夯實基礎，逐漸擴展到其它價值，實現DevOps規模化，最終實現企業的商業敏捷。