DevOps 轉型，只有工具怎麼夠！

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

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

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

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

責任共擔

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

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

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

在實務中，協作往往開始於開發團隊意識到需要了解更多的維運工作（如部署和監控）或是維運團隊採用了新的自動化工具與實務。

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

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

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

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

支持自組織團隊

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

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

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

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

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

註：
[1]：維運工具包括虛擬化、雲端運算和自動化組態管理，在持續整合、增量設計、程式碼淨化等工程實務中都支援這些工具。

以上是DevOps 轉型，只有工具怎麼夠！的詳細內容。更多資訊請關注PHP中文網其他相關文章！