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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文來自： https://www.linuxprobe.com/devpos-transation.html