DevOps在2018年慶祝了它的十週年紀念日，在科技行業，這已經是足夠漫長的生命週期了。儘管DevOps已經相對成熟，DevOps哲學仍然在迴避甚至是最著名和最有資源的組織。一份令人震驚的Gartner報告顯示，75%的DevOps項目未能實現其目標。
爲什麼DevOps的失敗率如此之高？在實施DevOps理念時，組織面臨的共同挑戰是什麼？如何克服這些挑戰？
本篇文章將解決這些問題，併爲企業提供可複製的策略，以提高DevOps計劃的成功率。
1.資源配置不規範
資源分配是DevOps的一大挑戰。僅僅集成開發和運維團隊並不能產生一個高效的DevOps團隊。極大數量的DevOps團隊缺乏主題專家，這嚴重影響了團隊實現DevOps承諾的能力。
首先，從事應用程序開發、優化和監控等不同技術的多面手不會像專家那樣有效率。這樣會浪費寶貴的時間，最終減慢DevOps的交付速度。
此外，當DevOps團隊最小化計劃外工作時，他們的工作效率最高。如果沒有專門的資源來處理特定的DevOps問題，團隊被迫將複雜的問題分配給非主題問題的專家。這將破壞他們的工作計劃，並使整個團隊效率低下。更重要的是，這類人才日益增加的工作量增加將導致員工筋疲力盡，並有可能使整個DevOps計劃脫軌。
只有在有專門人才處理問題時，DevOps才能加快功能發佈、更新和上市時間。因此，企業必須確定關鍵的應用程序技術和開發流程，這些技術和流程可以通過DevOps進行優化，併爲這些特定領域分配專門的技能型人才。
最佳的資源分配對於DevOps計劃的成功至關重要。
2.責任錯位
DevOps將目標截然不同的團隊聚集在一起，在一個“不穩定的”環境中工作。開發人員主要關心的是創新、穩定的運維團隊、性能完美的QA團隊等等。當然，這些團隊之間必然會有摩擦和衝突。
更糟糕的是，高層往往不會明確定義DevOps團隊的目標、職責和優先級。這給模棱兩可留下了很大的空間。習慣於孤島式工作而不擔心依賴關係的團隊會倒退到原來的工作方式，從而否定了所有實現無縫協作的努力。
在改變領導者之前，讓團隊走出思維定勢是最大的挑戰。因此，當團隊由跨學科資源組成時，DevOps的工作效果最好。擁有運維思維的開發人員，他們不羞於經常走出自己的舒適區，這是引領DevOps計劃走向成功的迫切需要。
組織通常通過清晰地描述DevOps的目標、優先級和職責來克服這些挑戰。更重要的是，他們爲DevOps任務的成功分配了完整的責任。每個團隊成員都對DevOps端到端任務的成功負責。當他們的個人表現由團隊的整體成功來衡量時，筒倉會自動分解，協作會迅速增加。
3.過程割裂
沒有多少DevOps領導者意識到，或者至少意識到，DevOps是非常分散的。儘管DevOps已經成熟，但它並不是特別適用於中小企業軟件開發和交付模式。DevOps長期以來主要是一個大型企業計劃。由於這個原因，與DevOps接軌的中小企業發現自己陷入了困境。
DevOps通過自動化軟件開發生命週期中涉及的大部分任務來工作。然而，沒有一個工具、過程或資源可以實現這一點。DevOps團隊必須使用不同的工具來自動化其操作的不同方面。有很好的工具可以自動化各個組件，比如持續集成、基礎設施供應、測試、源代碼控制等等。但是，這些工具之間彼此不能集成（當然，也可藉助工具實現集成，如禪道ZTF打通了禪道和Jenkins之間的溝壑，貫穿DevOps持續集成、持續測試、持續部署等DevOps生命週期的不同階段）。
使這些不同的工具相互通信需要大量的資源，而大多數組織無法或願意分配這些資源。由於這個原因，DevOps團隊經常被迫使用有限的自動化功能，這是DevOps的對立面。
高效的DevOps團隊在執行任務和自動化任務之間分配時間。如果沒有自動化，事務性工作會逐漸增加，導致員工精疲力盡、流程延遲、響應能力惡化和交付質量下降。
企業可以通過開發一個清晰的DevOps策略來避免這些問題，該策略指定組織的DevOps目標，確定可以自動化的流程，並部署資源來實現這些目標。這些目標應該與資源分配相匹配，這種解決碎片整理的現實方法將幫助企業簡化和自動化對他們來說很重要的流程。
4.缺乏適當的度量標準
缺少適當的度量標準既是一個過程挑戰，也是一個人員挑戰。KPI和指標在向DevOps團隊傳達組織的優先級和期望方面大有幫助。正如前面所討論的，穩定性和部署時間在DevOps團隊中持續存在衝突。是應該以犧牲穩定性爲代價匆忙交付，還是注重穩定性延遲交付？是如何開始優先考慮一個目標而不是另一個目標的？
指標爲團隊提供了明確而精準的方向，以確定不同目標的優先級。儘管這些指標的價值可能會隨着業務的不同而變化，但這些指標本身對所有DevOps團隊都是普遍相關的。以下是企業在向團隊傳達DevOps目標時必須定義的一些指標：
● 部署頻率
● 部署時間
● 更改故障率
● 自動測試通過率
● 每次發佈後的故障數
● 缺陷逃逸率
● 檢測的時間到
● 功能使用
● 終端用戶體驗
● 業務影響
● 部署失敗
5.文化轉變
對變革的抵制將是DevOps轉型的最大障礙。DevOps試圖將控制權從各自爲政的團隊及其負責人轉移到組織內的單個多部門機構。自然，這樣的嘗試可以被解讀爲對決策權的侵蝕。
更進一步說，這不完全是關於控制。與傳統的IT角色相比，DevOps的領導角色有很大的不同。一般來說，IT領導層必須具備在各種技術方面指導、支持和建議員工的專業技能。在DevOps環境中，情況並非如此。DevOps的員工工作在一個不穩定和快速發展的環境中。錯誤是常見的，而帶來的後果可能是災難性的。這樣就不難理解爲什麼員工會擔心DevOps流程。
因此，領導的首要作用是創造培養條件，給予員工更高的自由度，保護他們免受快速試驗帶來的挫折。此外，領導者的工作必須集中在確定DevOps的成功模式，並複製這些模式，以在整個組織中擴展轉換。
一個自上而下的方法試圖重新定義領導的角色，賦予DevOps團隊更多的實驗自由，並確保他們的穩定性，這對於克服文化慣性至關重要。
“無法實施文化變革——整個組織的相關方必須一致支持成功採用DevOps所需的必要文化變革。它包括不同組內的執行人員和領導。這不僅僅是技術上的採用。爲了成功，業務、運營、IT、財務和其他方面必須承諾並建立信任。”
6.無法擴展DevOps
很多時候，早期DevOps計劃的成功往往會變成失敗。表現最好的DevOps團隊被更多的項目淹沒，這很快就會成爲項目交付的瓶頸，更不用說隨之而來的壓力增加和生產力下降了。
解決這個問題的一個明顯的方法是擴展DevOps團隊。然而，這說起來容易做起來難。DevOps專家需要與開發人員或工程師截然不同的技能，因此僱傭起來既困難又昂貴。
一些組織通過在每個開發團隊中嵌入一個DevOps專家來克服這個挑戰。他們的職責是簡化各自團隊的交付鏈，同時與其他部門的DevOps專家進行協調。然而，這種方法經常會在團隊之間滋生不一致和協作的麻煩。解決這些新問題的一種方法是借鑑開源實踐，使用一種內部源代碼方法。
團隊必須擁有強大的協作工具，使他們能夠從世界任何地方進行編碼、發佈和協作。最後，要用健壯的、去中心化的“以產品爲中心”的交付模型取代傳統的“以項目爲中心”的方法。
“由DevOps驅動的改變首先需要有一個讓人信服的目的。然後，要成功地衡量變化，需要整個組織的溝通、協作和承諾。”
7.無法合併安全性
純粹從表面上看，DevOps和安全性似乎完全衝突。DevOps的核心是速度和持續交付，而安全性則強調廣泛的測試和防誤。然而，企業正慢慢意識到，與安全性集成的DevOps可以幫助他們修補漏洞、發佈更新，並比以往更快地應對網絡威脅。
目前，DevOps在將安全集成到其過程中面臨三個障礙：緩慢的開發速度、無窮無盡的安全標準和對可見性的威脅。
最後，通過向所有團隊成員提供安全數據並方便他們報告，可以提高威脅可見性。根據每個團隊成員的角色和職責定製的SIEM儀表板可以在很大程度上爲DevOps團隊提供威脅可見性。爲了使之有效，可以建立一個基於共同績效目標的獎勵體系。
每個組織的DevOps計劃都會遇到該組織特有的複雜障礙。然而，關注團隊成員的合作和穩定可以減少內部阻力，並將潛在的惰性來源轉變爲對領導層的變革，從而確保成功。