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

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

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

責任共擔

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

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

他們也可以通過生產(chǎn)環(huán)境系統(tǒng)監(jiān)控獲取額外的需求。當運維團隊主動承擔系統(tǒng)的業(yè)務目標時，運維團隊可以和開發(fā)團隊更緊密的合作，以理解運維需求并提供支持。

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

將開發(fā)與運維團隊放在一起

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

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

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

支持自組織團隊

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

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

[[198402]]

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

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

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

注：

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