當今，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變革過程中，比較現實的情況是單個職能領域（例如it部門）來發起此變革，因此導致devops實施侷限於單個職能領域，無形中增加了變革失敗的可能性。
因此即使單個職能領域發起devops變革，組織必須意識到成功的devops實施需要所有干係人共同合作以更全面地理解並系統地解決問題。為了加快價值實現時間，devops團隊必須與其他團隊及關係人合作。devops需要人們共同工作實現解決方案，打破障礙，並能像小型團隊一樣運作。因此，合作是至上的，團隊的大小並沒有絕對的限制，雖然業界有所謂兩個比薩（two-pizza）團隊的說法。
更為重要的是，企業級別的合作需要管理層的支援。在一開始，就應該獲得管理層的支援與擁護。devops的擁躉必須相信devops的價值，並平衡組織內不同團隊的激勵方式，例如開發團隊被鼓勵快速變更和開發新特性，而運維被鼓勵維持可靠性和穩定性，這樣就難以形成合作。
全面的一攬子的devops變革，對於大多數企業組織來說，是非常有**力的。然而，歷史經驗卻無情地告訴我們，這種傳統變革失敗率非常高。devops要在乙個大型it組織中成功，涉及太多因素，並且組織越大越困難。
因此，增量迭代方法成為組織的必然選擇，一方面此方法使組織聚焦於持續改進，另一方面避免了傳統方法的巨大風險。在進行devops變革時，組織聚焦於單一價值流，通過迭代與持續學習來持續改進，來得到合適的因素維持可接受的變革。迭代增量節奏也使組織確保團隊分享與合作，並建立實踐社群。這樣，在此價值流學到的知識可以傳遞到下乙個價值流，逐漸在組織中規模化devops。
組織在每個迭代中需要仔細識別目標機會，並確保每個迭代滿足以下3個關鍵條件：
俗話說，期望越高，失望越大。對於devops，許多組織的期望與它能夠交付的內容存在脫節。與其講企業組織將更敏捷或者快速，不如明確組織現在在哪兒以及需要到哪兒，然後迭代地實現目標。devops不是一次性投入，而是需要不斷地嘗試。因此組織需要達成一致的目標與度量指標來有效地管理期望。devops的度量指標非常多，建議可以從以下4個角度建立進度平衡檢視：
需要指出的是，並非所有的不切實際的期望都來自於商業客戶。例如，it部門會認為工具鏈是免費的，實際上工具鏈需要持續的資源與投入。總體上，組織需要圍繞客戶價值、成本與風險來權衡建立合適的期望。
由於受到devops成功案例以及camls理念中自動化的影響，企業通常寄希望於自動化等技術與工具手段來加速產品上市週期，然而經常因諸多基礎性工作沒有做紮實導致devops實施效果未達到預期。
在諸多基礎性工作中，最為關鍵的兩點是需求的探索分析與分解、源**的版本與分支管理。從devops的發展歷史來看，devops繼承了敏捷方法的諸多實踐與理念，原則上預設devops團隊較充分地掌握了敏捷方法與實踐，也致使devops組織忽略需求的重要性。因此無論如何強調需求的重要性都不為過。devops團隊必須清晰地管理需求，使需求以及story滿足smart要求，在迭代週期內可以按時保質交付最小可行產品（mvp）。**版本管理的重要性是不言而喻的，更需要關注的是良好的分支管理模式是持續整合與持續部署的基礎。企業可以使用華為雲devcloud進行需求與**的管理。
devops變革是乙個系統工程，涉及到組織、文化、人員、流程、工具、方法等方方面面。對於企業來講，應該從客戶商業價值出發，選擇合適的團隊，合理地管理期望，並以增量迭代的方法，初始聚焦於單一價值流，夯實基礎，逐漸擴充套件到其它價值，實現devops規模化，最終實現企業的商業敏捷。
如何避免DevOps變革的六大「焦油坑」
當今，devops能顯著提公升企業的商業敏捷與能力，因此在企業中廣受歡迎。然而，對於大多數企業來講，devops變革並非一帆風順，此過程中會面臨各種各樣的挑戰。為了提高devops變革成功的可能性，企業領導者亟需識別或者理解devops變革失敗的常見原因，並採取一定的措施來避免。經過不斷發展，dev...
PL的六大秘訣
pl在大多數情況下在 member 中更具有親和力，更容易獲得尊敬。作為一位成功的 pl的六 則 1 激勵 不管member 完成一項簡單還是複雜的工作，都不要忘了表示一下讚許。在 member 完成一項超出你預想的工作時，更要鄭重地發一封表揚信。2 坦白 面對member 當你沒有弄懂問題的時候，...
QBC的六大硬傷
硬傷 系列已經是炒得爛熟了，所以取這樣的名字也是有點怕怕 不過 在行業內混了幾年，最近看花前柳下的文章少了，發現竟然取不出更好的名字，將就吧，呵呵。以前用hql比qbc多，網上都說qbc功能比hql少，我也一直有這個感覺，但是從來沒有總結過 qbc到底比 hql差在 呢？最近實現das標準，終於 全...