DevOps的目標非常明確：使應用軟件高效迭代，可靠，質量更好。這個目標非常理想，幾乎所有人都不會對此產生異議。
許多人都說，他們已經開始了DevOps的實踐，正遵循一些常見的框架，比如“CALMS”。然而，能得到非常滿意結果的並不多，我們在與200多名DevOps專業人士交談後，做了以下的數據統計，希望你能從中得出一些結論：
• 68％的人表示，DevOps中所需的多種工具之間缺乏連接性；
• 52％的人表示，他們的大部分測試仍然是手動的，速度緩慢；
• 38％的人表示，他們混合了傳統和現代應用，使得環境變得非常混亂，這給應用部署策略和工具鏈等方面製造了很多麻煩；
• 27％的人仍然在努力消除孤立的團隊，追求所預期的協作；
• 23%的人對自助服務基礎設施的訪問仍然受限；
• 以及一些其他的問題：找不到正確的DevOps思路，難以管理多種服務和環境的複雜性，缺乏預算和緊迫性，以及執行領導層的支持有限……
通過這些數據統計，我們能得出一些更深入的結論來：
挑戰＃1：DevOps工具鏈中缺少連接
許多DevOps工具會用於自動執行不同的任務，如CI，基礎設施配置，測試，部署，配置管理，發佈管理等，雖然這些組織開始採用DevOps，但他們往往不能一起工作。
舉一個典型的例子，某團隊使用Capistrano進行部署，當需要部署新版本的應用程序時，或者當應用配置需更改時，研發人員仍然會通過JIRA tickets 與Test and Ops團隊進行通信。
運行Capistrano腳本所需的所有信息都可以在JIRA tickets 中使用，在運行之前，研發人員手動將其複製到腳本中，這個過程通常需要幾個小時，需要仔細管理。而所需的配置其實被手動傳輸兩次：先輸入到JIRA，再將其複製到Capistrano。
這是一個簡單的例子，但這個問題存在於整個工具鏈中。當DevOps工具鏈中的工具無法協作並且依賴於手動的時候，持續交付將變得非常困難。
挑戰＃2：缺乏測試自動化
儘管所有的焦點都集中在TDD上，但大多數組織仍然在與自動化測試進行鬥爭。如果測試是手動的，那麼幾乎不可能執行整個測試套件，這將成爲持續交付的障礙。團隊試圖通過運行一組核心的測試來處理這一問題，並定期運行完整的測試套件。但這意味着在你的軟件交付工作流程中可能忽視很多bug，而且查找和修復的成本要高得多。
測試自動化是DevOps採用過程的重要組成部分，因此需要成爲首要任務。
挑戰3：布朗菲爾德環境
典型的IT組合在本質上是跨越了數十年的技術、雲平臺供應商、實驗室、數據中心的私有云和公共雲。創建跨越這些方面的工作流程是非常有挑戰性的，因爲相當一部分工具只能使用在特定的架構和技術上。這導致了工具鏈的蔓延，因爲每個團隊都希望使用最符合自己需求的工具鏈。
Docker的興起鼓勵許多組織開發基於微服務架構進行。這也增加了DevOps自動化的複雜性，因爲應用程序現在需要數百個異構微服務的部署管道。
挑戰＃4：文化問題
開發人員開發了穩定優質的軟件，然後由運維部門部署和運維。儘管所有這些團隊都希望能夠攜手共同合作，但他們往往會有利益衝突。
開發人員可以快速迭代，QA團隊確保沒有軟件錯誤，兩個團隊通常由SecOps和基礎設施運維部門協調，他們被激勵以確保生產不會中斷。但成本中心的壓力越來越大，這導致了一種反對變革的文化，因爲變革引發了風險，破壞了事物的穩定，這意味着需要更多的資金和資源來控制影響。
開發人員也受到開發問題的困擾，大部分時間都花在之前的內容維護上，而不是創新新事物。大多數組織試圖讓所有團隊參與SDLC的所有階段，但這種方法仍然依賴於手動協作。
自動化是開發和運維合作的最佳方式。但是正如我們剛剛分析的那樣，這種不太健康的自動化本身會降低你的速度並引入風險和錯誤。
我們需要更多關於DevOps理解和思考
一套完整的DevOps框架會包括文化、自動化、測試和共享。DevOps運動的雛形其實是一種文化運動，即使在今天，大多數的實現仍集中在文化上。
雖然文化是任何DevOps架構的重要組成部分，但想改變一個組織的文化是最困難的事情，因爲文化會在時間的沉澱中形成。Ops團隊不討厭改變，他們試圖快速改變生產過程，但他們更需要運維的穩定性。
把它們和開發人員一起放在一起，可能有助於使工作環境變得更加友好，但它並沒有解決根本原因，Dev團隊和Ops團隊還有很長的路要走。
“精靈學院”第二次分享交流會如約而至，9月6日晚我們繼續聊聊《針對企業的DevOps改進和實踐（下）》，歡迎各位朋友前來交流分享。
