敏捷軟件開發已經打破了需求分析、測試、開發之間的壁壘。在軟件開發流程中，開發與運維之間面臨著相同的隔離問題。DevOps運動的目標就是打破開發與運維之間的壁壘，鼓勵開發與運維之間的協作。

新運維工具的出現以及敏捷工程實踐的建立使得DevOps變成了可能[1]，但對于DevOps好處的認識還遠遠不夠，即便擁有最好的工具，如果我們沒有正確的文化，DevOps僅僅是一個時髦的詞匯而已。

DevOps文化的基本特征是開發和運維角色之間的不斷增強的協作。在團隊級和組織級都需要文化的轉變一支持這種協作。

責任共擔

責任共擔是DevOps的團隊文化之一，責任共擔鼓勵團隊進一步的協作。如果系統運行與維護的工作交給了其他團隊負責，開發團隊一般都不會關心具體的運維工作。

當開發團隊共同分擔系統生命周期中的運維工作與責任時，開發團隊就能理解運維團隊的痛苦，就能主動簡化開發和運維中繁瑣的工作(例如：自動化部署和完善日志)。

他們也可以通過生產環境系統監控獲取額外的需求。當運維團隊主動承擔系統的業務目標時，運維團隊可以和開發團隊更緊密的合作，以理解運維需求并提供支持。

在實踐中，協作往往開始于開發團隊意識到需要了解更多的運維工作(如部署和監控)或者是運維團隊采用了新的自動化工具與實踐。

將開發與運維團隊放在一起

責任共擔文化也需要組織上的一些變化。開發團隊和運維團隊之間不應該有壁壘。在一開始，就不能依靠移交文檔來代替一起工作。應該在組織資源結構上支持運維團隊盡早地介入到產品交付過程中與其他團隊一起工作。

將開發與運維團隊放在一起，可以有效地促進他們一起工作。“移交和簽收”無益于團隊共同承擔責任，并且會導致形成責備的文化。反之，開發和運維團隊應該共同對產品的成功與失敗負責。

DevOps文化模糊了開發與運維之間的界限，最終也將消除這種界限。在向組織中引入DevOps時，一種常見的反模式就是制作出一個DevOps角色或者DevOps團隊。這樣做只會造成更多的壁壘，并且阻礙DevOps文化和實踐在更廣泛的團隊中傳播和使用。

支持自組織團隊

另一個有價值的組織變化是支持自組織團隊，為了更高效的協作，開發與運維團隊應該自主決策，在采納變更時也不需要冗長的變更管理流程。這涉及到對團隊的信任、對風險管理方式的變化，也需要創建不怕失敗的環境氛圍。

例如，一個團隊需要列出變更清單并且獲得一堆簽字批準才能發布到測試環境，這些變更經常被推遲。我們應該依靠可審計的版本控制來替代大量的人工檢查。在版本控制中的變更可以鏈接到團隊的任務管理工具中，無需人工的簽字批準，團隊可以自動化部署變更，并縮短測試周期。

[[198402]]

向DevOps文化改變的一個影響就是將代碼部署到生產環境將變得很容易。這需要更進一步的文化改變。為了保證生產環境變更是可靠的，團隊需要重視在開發過程中內建質量。這包括跨職能關注點，如性能和安全。持續交付技術(包括代碼自測試)形成一個允許日常的、低風險的部署。

對團隊而言，重視反饋也很重要，為了持續的推進開發與運維像一個團隊一樣工作，生產環境監控是一個很有用的反饋循環，它可以幫助診斷問題和發現潛在改進點。

自動化是DevOps運維的基石，它可以加快協作。自動化測試、配置、部署使得團隊有更多的時間專注在其他有價值的活動中，并減少因為人為造成的錯誤。自動化腳本和測試的另一個好處是總是保證系統的文檔是最新的。比如，自動化服務器配置意味著開發和運維團隊都能了解并修改服務器的配置。

注：

[1]：運維工具包括虛擬化、云計算和自動化配置管理，在持續集成、增量設計、代碼凈化等工程實踐中都支持這些工具。