DevOps is everywhere,全部人都在說在作。DevOps轉型的案例和故事不少,有些轉型成功了,但也許失敗的例子更多(雖然你沒有機會聽到他們出來分享了)。不一樣組織面臨的狀況和環境各不相同,其實很難簡單的複製別人的成功。sql
我常常喜歡舉的一個例子,學習DevOps有不一樣的方式,就像人類學習飛行時有鳥飛派和空氣動力學派。人類的飛行夢想始於古老而又遙遠的年代,但真正的飛行實踐起源於仿鳥飛行,即給本身裝上一對翅膀,學習鳥的撲翼動做而飛行,但大量長期的實踐證實這樣的嘗試都是失敗的。但還有另一派,英國的科學家提出人造飛行器應該解決推動動力和升力等方面的問題,須要加強對空氣動力學理論體系的基本認知,這使不少人放棄了單純模仿鳥類飛行而逐漸接受和實踐固定翼飛行器的設計思路,並最終由萊特兄弟發明了徹底受控、可持續飛行的載人飛行器。
安全
DevOps的實踐和轉型也是同樣,咱們很難照搬其餘組織的成功,而是應該深刻理解其背後的原理、原則和實踐,從正確的方向入手。本文主要內容來自Jez Humble在Devon Summit上的演講《Leading a DevOps Transformation》,重點介紹了DevOps轉型的五個誤區、五個實踐,以及轉型實施的具體建議。由於篇幅較長,我將會經過兩篇文章跟你們分享。另外,與以前的文章同樣,我會結合個人經驗和理解進行適當的內容擴展,而不只限於演講內容,核心仍是但願幫助你們少走彎路、避免踩坑,可以更順利的走向DevOps成功之路。
架構
另外再介紹一下Jez Humble,做爲DevOps領域裏公認的世界級領軍人物,他既是一位很是有影響力的軟件研究人員,也是一位屢獲殊榮的做家。他與其餘做者合著的《持續交付》(Continuous Delivery) 一書曾獲Jot大獎,是學習DevOps的必讀書籍。Jez的其餘暢銷書包括《精益企業》(LeanEnterprise),以及DevOps Handbook,其中文譯本《DevOps實踐指南》將於5月5日在DevOpsDays北京站首發,大神Jez Humble也會來華與你們面對面暢談DevOps!
運維
傳統軟件交付方式的問題你們都清楚,好比很長的交付週期、不好的應變能力和低效的價值交付。全部不少組織進行了敏捷轉型,但敏捷轉型的歷程可能也並非一路順風。以開發爲表明的工程師部門使用敏捷的方式運做,從瀑布轉向了Scrum快速迭代,並引入了TDD,作好了架構解耦,工做很是開心。分佈式
但組織裏的其餘部門也許就不是這樣想的了。好比運維團隊,原來一年作好幾回發佈就能夠了,如今隨時有上線包扔過來,隨時都須要準備發佈,這個實在太可怕了。遇到這樣的問題,很天然的反應是創建起一個屏障,好比"變動管理流程",而這個流程的職責就是限制變動。
學習
DevOps的出現就是爲了解決這樣的問題,可能不少人對DevOps的理解都不一樣,也可能並無一個統一的定義。但這並無關係,咱們能夠從DevOps的起源來思考。DevOps運動始於社區,一些人試圖解決某些從未被解決的問題:如何構建大規模、分佈式、可靠、安全的系統,而且能夠在持續、快速變動的狀況下,讓系統一直保持安全和可靠。ui
在過去的五年時間中,經過對不少高效能企業的調研,能夠發現投資於DevOps實踐所取得的衆多好處,首當其衝的就是軟件交付會對業務發展產生重大的影響,高效能企業有兩倍於其餘企業的機率達到其利潤率、市場佔有率、生產效率等業務目標。spa
接下來,咱們從統計學的角度來分析IT效能,這裏設計了兩大類四個指標。分別是度量吞吐量的指標(部署頻率、變動前置時間),以及度量穩定性的指標(MTTR、變動失敗率)。這些數據來自每一年的DevOps現狀調查報告,我在去年也進行過屢次線上、線下解讀和分享,這裏暫不展開說明。但值得再次強調的是,從統計結果上來看,高效能的企業能夠在吞吐量和穩定性方面兼得,而不是傳統意義上的爲了提高效率而犧牲質量,或者爲了質量而犧牲效率。設計
以前Facebook有句格言是"Move fast and break things",意思是公司應該快速行動、打破陳規。但我以爲能夠改爲"Move fast and don't break things",即快速交付的同時必需要確保質量和安全性,這正是DevOps能夠賦予給咱們的能力。orm
2018年5月5日,與大神Jez Humble面對面暢聊DevOps!
與大神見面並交流的機會可貴,趕快掃碼報名!