在定義上，DevOps是一個涵蓋著幾條線的領域。它既非常實用又貼近實踐。但與此同時，你需要了解的不僅有技術背景，還有非技術的文化方面。中培偉業專家指出，DevOps最佳實踐的動手和軟技能兩個部分。

DevOps由開發(developments)和運維(operations)兩個單詞組成。這個雙關語已經揭示了DevOps的本意，那就是鼓勵不同的軟件開發部門共同協作。

DevOps這個詞的起源和DevOps運動的早期還是很清晰的：Patrick Debois是一名在IT行業的許多領域里很有經驗的軟件開發工程師兼顧問。他本人對于開發和運維之間的對立感到相當不爽。他試圖在會議中引起大家對這個問題的興趣，但是一開始并沒有什么效果。

在2009年，O’Reilly Velocity大會上有個深得好評的演講：“每日至少十次部署：開發和運維在Flickr的合作”。Patrick隨即決定在比利時根特市組織一場名為DevOps之日的活動。這次，感興趣的人變多了，這場大會獲得了成功。“DevOps之日”這個名字引起了共鳴，而這場大會也延續了下來。在Twitter和大多數論壇里，DevOps之日被簡稱為DevOps。

DevOps運動的根源寫在了敏捷軟件開發原則里。在2001年，有些人想要改進一成不變的軟件開發模式，并尋找新的工作方法，他們編寫了敏捷宣言。下面是敏捷宣言里被奉為經典的摘錄，可以在http://agilemanifesto.org/上閱讀“個體和互動高于流程和工具工作的軟件高于詳盡的文檔客戶合作高于合同談判響應變化高于遵循計劃也就是說，盡管右項有其價值，我們更重視左項的價值。”

由此可見，DevOps可以說是與第一條原則密切相關的--“個體和互動高于流程和工具。”顯然這能夠給工作帶來好處——那為什么我們還要強調這么明顯的事呢？如果你在大型企業里工作過，你就會知道事實上經常是反著來的。哪怕是看起來沒什么障礙的小企業，里面的各個部門也很容易就筑起高墻。

DevOps，想要強調個體和互動是非常重要的，并且這個技術很可能有助于拆除企業里的部門墻。看起來可能有點兒反直覺，因為第一條原則更青睞于交互而不是工具。但是我認為使用任何工具都能起到多種效果。只要工具用得適當，就能幫我們得到所有想要在敏捷中獲得的東西。

舉個非常簡單的例子，一個選擇系統過去經常有缺陷。通常，開發團隊和測試團隊會用不同的系統來處理任務和缺陷。這樣的事不僅在團隊中導致了不必要的摩擦，并且把本應一起工作的雙方隔離開了。而運維團隊很可能又會用第三種系統來處理服務器的部署請求。

另一方面，有DevOps觀念的工程師，會立即意識到所有的三個系統都是相似的工作流程。三個囡隊里的每個人應該都有使用一個相同系統的可能性，也許只需要為不同的角色展示不同的界面就可以了。因為三個系統變成了一個，所以會帶來減少維護成本的長期利益。

DevOps的另一個核心目標是自動化和持續交付。簡單來說，自動化一切可重復的乏味的工作，把更多時間留給人與人之間的交流，這才能產生真實的價值。

想了解更多IT資訊，請訪問中培偉業官網：中培偉業