7個常見的 DevOps 誤區解讀

前言:

本文將介紹《DevOps Handbook》全書中的一部分:對 DevOps 常見誤區進行解讀。有些朋友對DevOps不熟悉或有一些不許確的理解,好比是否是隻有互聯網公司能夠僅僅,是否是與ITIL不兼容,是否是作DevOps就不能同時保證質量和效率等,咱們會對這些常見誤區進行分析。python

第一個常見的誤區:DevOps只適合於初創型的互聯網公司,這也是不少人常常會表達的一個觀點。linux

DevOps實踐確實是被那些互聯網獨角獸公司所倡導,包括優秀的公司好比谷歌、亞馬遜、Netflix、Etsy,這些公司都在倡導DevOps相關的方法實踐,雖然也許他們不把它稱爲DevOps。數據庫

實際上,這些公司並非生來如此的,每一個公司成長過程都是同樣的,都會經歷不少問題、坎坷,也經歷過IT跟不上業務的發展致使業務停滯的風險。安全

咱們把他們叫作獨角獸公司,由於在神話裏獨角獸是一種長着犄角和翅膀的白馬,這些公司都是從普通的」馬駒」公司進化成了獨角獸公司,他們也會遇到傳統公司所碰到的問題,包括高危代碼致使的災難性的失敗、不能快速發佈功能、不能應對市場上競爭的變化、不能擴大規模,以及開發和運維相互對立而不能相互信任等。運維

第二個誤區,DevOps Replaces Agile,有些人認爲是否是DevOps就會替換掉Agile。工具

正確的說法應該是DevOps的方法和實踐是與敏捷相適應的,咱們認爲DevOps是敏捷之旅的一種邏輯延伸。學習

敏捷是DevOps的使能者,由於作了敏捷,具有小團隊快速發佈和持續交付的能力,才能進一步作好DevOps。測試

可是DevOps其實是在超越敏捷的,你們讀過《敏捷宣言》,有一句是」可工做的軟件大於面面俱到的文檔」,每一個迭代結束以後它會獲得一個潛在可交付的版本,可是咱們認爲DevOps已經在超越這個目標,把目標擴展爲」讓代碼一直處於可部署的狀態」。優化

經過每日頻繁的簽入代碼到主幹上,通過一系列的構建、自動化測試,可以很快在類生產環境甚至生產環境看到此次變動所帶來的影響。DevOps不是替換敏捷,而是敏捷之旅的延伸,把目標作進一步的擴展。設計

第三個誤區,DevOps與ITIL不兼容,這多是不少作運維的朋友最大的困惑。1989年提出的ITIL是很是經典的方法論,影響了一代又一代運維實踐者。

有不少世界級IT運維流程橫跨整個服務的策略、設計和支持等不少方面,可是咱們認爲DevOps的實踐實際上能夠與ITIL流程作兼容。具體有三個方面:

  • 第一,爲了支持更短的前置週期和更高的部署效率,不少ITIL流程須要自動化,經過自動化的方式提高效率。
  • 第二,爲了解決配置和發佈管理流程方面的一些問題,咱們強調DevOps須要保持配置管理數據庫以及軟件庫的及時更新。
  • 第三,DevOps須要快速探測和恢復故障,在這個背景之下ITIL裏關於服務的設計、事故、問題管理的這些流程實際上是仍然適用的。

ITIL與DevOps實際上是能夠兼容的,以前有一個文檔《企業級DevOps成功之路》,裏面談到DevOps裏有不少組成部分,包括敏捷、持續交付、精益,還有輕量級的ITSM,如何把ITIL流程作效率上的優化,與DevOps頻繁發佈變動的模式相匹配等,因此咱們認爲本質上兩者是能夠兼容的。

第四個誤區,DevOps和信息安全、合規性之間不兼容。

不少人以爲DevOps缺少傳統的控制方式,好比職責隔離,不一樣人有不一樣權限、作不一樣事情,DevOps講究跨界,鼓勵開發人員自服務的方式作環境申請、部署和發佈。

又好比說傳統的控制方式有很嚴格的變動審批的流程,以及在整個項目末尾人工進行很是完善的安全review的活動。

DevOps沒有這些活動,可是不表明沒有安全控制,反過來,不少作DevOps的公司的安全性、合規性甚至會超過原來傳統控制方式的公司。由於DevOps實際上是把原來項目末尾作的安全和合規性的檢查注入到了每一個階段,變成平常工做的一部分。

咱們常常說在DevOps裏是沒有單獨的測試階段的,可是它把測試已經融入到每一個階段,測試在DevOps場景裏是每一個階段都要作的實踐,而不是一個單獨的階段。沒有傳統的控制方式,並不意味着DevOps沒有安全和合規性的要求,反而它會更強。
在這裏插入圖片描述

第五個誤區,DevOps沒有Ops或者說排斥了IT運營。

誠然在DevOps場景裏IT運營或者運維的職責會發生一些變化,可是這種角色仍然是很是重要的。

咱們的運維更早的會介入到軟件生命週期裏,可能會與開發一塊兒工做。反過來,開發也會在代碼部署到生產以後,與運維一塊兒去持續工做。變化是咱們更強調自動化,經過自動化替代原來手工處理工單的一些工做。

運維最大的變化是經過一系列自服務平臺的建立和開發,可以把本身原來基於人工的環境的建設、維護、發佈、部署等等這些能力賦能給開發,經過賦能給開發的方式,提高流程生產效率。

從這個角度講,IT運營或運維其實更像是一種開發,開發的產品是一個平臺,讓開發人員能夠快速、安全、可靠的用這個平臺去完成常常操做的場景,好比部署、環境分配等。從這個角度講,並非說沒有運營或運維,反過來運維的職能會有些變化,更強調賦能給開發,提高自服務能力。

第六個誤區,DevOps僅僅是基礎設施即代碼。

由於不少人在談DevOps強調的是自動化,強調的是Puppet、Chef、Ansible這種工具,咱們認爲這遠遠不夠。

不少DevOps模式確實須要自動化,可是那些成功的公司不只僅有技術範疇的改進,更有公司組織結構的調整、文化氛圍的調整,讓整個共享目標在IT的價值流裏快速交付,這已經遠遠超出了自動化的範疇。

這裏有一句很經典的話:」DevOps不只是自動化,就像天文學不只是望遠鏡那樣」。咱們要超越技術的範疇去看更廣闊的改進空間。

第七個誤區,DevOps只爲開源軟件服務。

不少成功的故事都是用LAMP技術棧,好比Linux、Apache、MySQL、PHP,可是這些其實與取得DevOps的成果是無關的,咱們看到不少成功案例能夠用微軟.Net、大型機系統、SAP軟件,或者是一些嵌入式軟件等,均可以作DevOps轉型,在《DevOps Handbook》這本書裏也提到不少,包括ATM機這種複雜的嵌入式的系統也能夠作DevOps轉型。

以上談到了七個誤區,但願你們經過個人解讀慢慢去理解,DevOps其實是一個普適的概念,它不只僅是自動化,不只僅是一種流程,能夠跟咱們平常的工做場景相兼容。

最後,推薦你們看下《116頁DevOps實踐手冊,揭祕阿里巴巴高效開發的祕籍》你會對DevOps有更全面的瞭解!

福利:豆花同窗爲你們精心整理了一份關於linux和python的學習資料大合集!有須要的小夥伴們,關注豆花我的公衆號:python頭條!回覆關鍵詞「資料合集」便可免費領取!

相關文章
相關標籤/搜索