DevOps是雲計算時代的開發與運營

時間 2019-11-11

標籤 devops 計算時代開發運營简体版

原文原文鏈接

DevOps（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。^[1] 它的出現是因爲軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工做必須緊密合做。html

如下幾方面因素可能促使一個組織引入DevOps：windows

使用敏捷或其餘軟件開發過程與方法
業務負責人要求加快產品交付的速率
虛擬化和雲計算基礎設施（可能來自內部或外部供應商）日益廣泛
數據中心自動化技術和配置管理工具的普及
有一種觀點認爲，目前占主導地位的「傳統」美國式管理風格（「斯隆模型 vs 豐田模型」）會致使「煙囪式自動化」，從而形成開發與運營之間的鴻溝，所以須要DevOps能力來克服由此引起的問題。

DevOps，是一種提倡將開發機構的文化、流程和工具整合到一塊兒的集成軟件交付方式，跨越從業務規劃、建立、交付到反饋的整個軟件開發生命週期。DevOps既不只是一個工具、平臺或技術，也不是簡單的定義開發和運營，而是對軟件開發及交付的一門哲學。DevOps裏面包括四個維度：(1)計劃和監控；(2)開發和測試；(3)發佈和部署；(4)版本管理、反饋和分析。安全

在軟件行業進入雲計算時代後，在整個市場用戶對軟件產品以及服務的要求也跟着提升，這不只須要開發和運維人員快速實現，並且要快速部署發佈上線，而且必須保證業務可靠、高效運行。正如虛擬化改變了數據中心的運營同樣，雲計算的興起也預示着IT應用運維將發生重大變革。目前，IT運維團隊還一直處於以服務器爲中心來驅動的運維模式，而具體的應用則扮演着次要做用。另外一方面，雲計算則是以應用爲中心的運維模式。服務器

運行在雲環境下的應用程序也須要具備高可用性、高可靠性和高靈活性，以應對更多更復雜的工做負載和監測。過去由IT運維基礎架構提供的這些功能如今將成爲應用程序自己的一部分，這些運維能力須要融入到開發環境中。而在這些以應用爲中心的新環境，運維團隊將須要與開發者協同建立這些應用程序，也就是剛纔咱們所介紹的「DevOps」。DevOps團隊是「一羣採用新的方式實現更快、更好、更具效益和樂趣來推動開發和系統管理的人羣。」架構

傳統模型帶來的是開發及測試的部門壁壘。隨着咱們經過像敏捷，像Scrum這樣的敏捷方法，在增強開發團隊和測試團隊之間的溝通協做以後，其實咱們不可避免地會面臨到開發部門和咱們的運維，以及發佈運營這樣的一個瓶頸。它會取代咱們以前開發團隊裏面所遇到的障礙和瓶頸，咱們新的要解決這樣的問題。DevOps從它的思想和實踐上來看，也是隨着敏捷的實踐項目繼續集成、自動化部署這樣的一些實踐成熟。app

傳統的意義上講，咱們開發團隊，開發完了以後每每是打包扔給發佈團隊，或者說是運維團隊，隨着咱們對於發佈的要求愈來愈高。咱們實際上是要求，就是說生產環境的運維部門和發佈團隊，跟開發部門坐到一塊兒，雙方角色互補，開發人員去學習運維的知識和工具。運維去提供我生產環境部署的約束和要求，雙方融合造成一個比較一體化的DevOps這樣的團隊。運維

在虛擬化和雲計算出來以前，每每咱們的部署和生產運維，並且都是在實體機上面，實體機上面的成本基數很高的。在虛擬化技術出來以後，我一個普通的運維人員，輸入命令就能夠獲得幾臺這樣的虛擬機。當這樣的工具出來以後，我能夠再輸入命令就會拿到一個徹底同樣的環境出來。因此咱們來說，隨着虛擬化和雲計算技術，以及周邊的管理，像自動化建立工具這樣的成熟後，DevOps就傳統的運維技能會變得愈來愈大衆化，能夠被咱們開發人員所接受、所擁抱，再用到環境裏面去。ide

開發和運維是分開的兩個團隊，項目之間經過一個發佈包，作出一個FTP這樣的去溝通。其餘團隊把包放在FTP上面，而後運維從FTP上取下包去部署。這個致使的問題就是，不少生產環境下面的環境配置，這樣的一些軟件要求，跟開發的時候不同。DevOps成員是做爲團隊的一分子參與到開發團隊的平常工做裏面去，它的幾個主要工做職責會包括，第一，它會幫助團隊把他們團隊對環境的配置、對環境的要求，用一些工具把它變成代碼，變成自動化的。另一個就是說，在生產環境下面會考慮到可用性、考慮到安全、考慮到運維的要求。它會把這樣的約束條件灌輸給團隊，團隊在設計系統的時候就考量這一塊的約束狀況，這樣的時候實施就會更好一些。工具

開發和運維實際上是兩種不一樣的技能，開發的頭腦裏面就是我趕忙把代碼寫完，扔給運維就行了。運維的頭腦就想着，我這塊要是出了問題，那我就可能睡不着覺，天天晚上接到電話起來維護。其實來說，兩邊對對方存在一些這樣的誤解，很大的緣由就是，你們對於各自工做是不瞭解的，他不知道運維須要作什麼事情，我只看到運維可能有這樣的一些報表，有這樣的投影，投在那裏說系統實際是怎麼樣，有沒有出現問題。運維看到開發團隊在那邊寫代碼，也不知道在作什麼事情。要想在團隊裏面實施這樣的運維，DevOps的話，其實咱們以爲它從文化和技術，或者是技能兩方面都要提供相應的輔導。從文化層面上面來說，就要鼓勵咱們的運維和開發人員坐在一塊兒，互相地分享。由於團隊的目標仍是一致的，我把系統更快的部署到環境上去，讓它可以穩定安全地運行。從文化上面來說，首先要讓你們理解這樣的一個，你們是共同的目標，不是說勢如水火。性能

其次的話，要營造出雙方相互協做的一個狀況、一個場景。就是文化上面，而後從場景和技巧上面來說，除了雙方對於各自技能的掌握和培訓以外，咱們發現仍是有一些前提條件是比較知足的，好比說咱們來說企業集成。咱們須要自動化測試，只要咱們可以在團隊內部把企業集成和自動化測試先作到必定程度的話，好比說咱們能夠有信心地拍胸脯說，咱們這個軟件沒有太大的問題。在這樣的狀況下面，咱們再引入DevOps作這個，從軟件交付的角度來說，會是比較好的一種方式。不然的話團隊成天在修復缺陷，這時候咱們的運維和開發坐在一塊兒可能沒有太多的意義，這是第一。

第二就是說，若是咱們不是這麼全局來看，咱們是從局部優化來看，咱們能夠看到運維團隊在系統配置、系統建立這一塊的技能。它也是很是必要的，由於咱們發現開發團隊，不論是開發仍是測試，它其實有一個很嚴重的問題，他們要想作調試、作測試的時候，環境是不夠的。可能這個環境作完一套測試以後，環境就被污染了、數據被污染、個人應用包被污染。在追求環境的準備和提供方面，其實咱們的運維是能夠進來，或者是咱們的DevOps團隊是能夠造成的，而後去作一些相對來說沒有那麼廣的事情，仍是跟在這一塊上面。而這個前提條件就多是咱們這樣的一個架構也好、技術也好，可以比較好的支持咱們DevOps去作基礎設施代碼的工做。

DevOps相似於咱們敏捷方法，它其實也是跟思想原則和具體的實現，DevOps它的自己的這樣一個思想和價值觀就是說，讓咱們的開發和咱們的運維也好，或者說咱們的實施也好，讓他們可以更好地，雙方可以消除各自領域的浪費。從原則上來說，就會有一些像基礎設施代碼、配置自動化等等這樣的一些原則。

相關圖書