當今，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規模化，最終實現企業的商業敏捷。
