Dev Ops 文化

敏捷軟體開發已打破需求分析、測試和開發之間的部分藩籬。部署、運作和維護是其他活動，也遭受與軟體開發流程其他部分類似的隔離。DevOps 運動旨在移除這些藩籬，並鼓勵開發和運作之間的協作。

DevOps 已成為可能，這在很大程度上要歸功於新的運作工具和既定的敏捷工程實務 [1] 的結合，但這些還不足以實現 DevOps 的好處。即使擁有最好的工具，如果您沒有正確的文化，DevOps 也只是一個流行語。

DevOps 文化的主要特徵是開發和運作角色之間的協作增加。在團隊和組織層級中，有一些重要的文化轉變支持這種協作。

共同負責的態度是 DevOps 文化的一個面向，它鼓勵更緊密的協作。如果將系統的運作和維護移交給另一團隊負責，開發團隊很容易對此失去興趣。如果開發團隊在系統的生命週期中共同負責照顧系統，他們就能夠分擔運作人員的痛苦，並找出簡化部署和維護的方法（例如，透過自動化部署和改善記錄）。他們也可能從監控生產中的系統中獲得額外的 觀察到的需求。當運作人員共同負責系統的業務目標時，他們就能夠與開發人員更緊密地合作，以更好地了解系統的運作需求並協助滿足這些需求。在實務中，協作通常始於開發人員對運作問題（例如部署和監控）的認識增加，以及運作人員採用新的自動化工具和實務。

需要一些組織轉型來支援共同責任的文化。開發和營運之間不應有孤島。移交期和文件是從一開始就共同解決方案的拙劣替代品。調整資源結構以讓營運人員及早參與團隊會有所幫助。讓開發人員和營運人員共同駐點將有助於他們共同合作。移交和簽核會讓人們不願意承擔責任，並助長責備文化。相反地，開發人員和營運人員都應對系統的成功和失敗負責。DevOps 文化模糊了開發人員和營運人員角色之間的界線，並最終可能消除這種區別。在組織中導入 DevOps 時，一個常見的反模式是指定某人擔任「DevOps」的角色，或 稱呼一個團隊為「DevOps 團隊」。這麼做會讓 DevOps 旨在打破的孤島類型永續存在，並阻止 DevOps 文化和實務擴散和被更廣泛的組織採用。

另一個有價值的組織轉型是支援自主團隊。為了有效地協作，開發人員和營運人員需要能夠在沒有複雜決策程序的情況下做出決策並套用變更。這涉及信任團隊、改變風險管理方式，以及創造一個沒有失敗恐懼的環境。例如，必須製作變更清單以簽核才能部署到測試環境的團隊可能會經常延誤。與其要求這種手動檢查，不如依賴於完全可稽核的版本控制。版本控制中的變更甚至可以連結到團隊專案管理工具中的單據。沒有手動簽核，團隊可以自動化他們的部署並加速他們的測試週期。

轉向 DevOps 文化的一個影響是讓新程式碼更容易投入生產。這需要一些進一步的文化變革。為了確保生產中的變更健全，團隊需要重視在開發過程中建構品質。這包括效能和安全性等跨職能考量。持續傳遞的技術，包括 自測程式碼，形成一個基礎，允許定期、低風險的部署。

團隊重視回饋也很重要，以便持續改善開發人員和營運人員合作的方式，以及系統本身。生產監控是診斷問題和發現潛在改善之處的有用回饋迴路。

自動化是 DevOps 運動的基石，並促進協作。自動化測試、組態和部署等任務，可以讓人們專注於其他有價值的活動，並降低人為錯誤的機率。自動化的有用副作用是自動化腳本和測試可作為系統的有用且始終最新的文件。例如，自動化伺服器組態，可以消除與 SnowflakeServer 相關的猜測，並表示開發人員和營運人員都能夠知道和變更伺服器的組態方式。