從電子遊戲到DevOps

從電子遊戲到DevOps

在一個項目團隊中，開發與運維之間的關係像極了知名大型遊戲《刺客信條》裏的故事：開發就是追求自由的刺客聯盟——我喜歡用各類新穎技術手段去知足用戶爸爸那些花裏胡哨的需求，你別管那技術好很差用，總之它實現了需求；運維就是那支持秩序的聖殿騎士——我要的是穩定運行！穩定運行！穩定運行啊！

 

 

因而，產品與運維之間造成了一道牆。

 

開發部門夜以繼日地打造出本身的「傑做」，並懷着今晚就能開慶功會的心情把本身的「傑做」交給了運維部門，卻不知牆那面的運維們對開發的抱怨纔剛剛開始：

l  這款優秀的產品在目前的底層平臺上沒法運行，由於這個平臺太古老了，由於這個平臺空間不足，由於這個平臺不支持某某版本……

l  這款產品的體系結構跟咱們的{存儲，網絡，部署，安全}模型不匹配。

l  這款產品的報告、安全、監視、備份balabalabala 咱們搞不懂 ，因此無法把它作成實際可用的產品。

 

當運維將問題源源不斷地反饋給開發後，開發的回覆必定是：

l  這不是咱們的錯，咱們的代碼很是完美，是（運維部門的）部署作的太差勁了。

l  運維部門比較笨，他們不懂新技術，爲何他們無法實現最新的技術呢？爲何他們這麼落伍呢？

l  在個人機器上運行的沒問題啊……

 

刺客聯盟與聖殿騎士互掐了幾百年，但事實上他倆都不過是想維護人類文明；開發與運維互看不順眼，但他們的初心都是想這個項目能順利驗收。

 

雖然開發和運維這樣相愛相殺的關係看上去和遊戲很像，但其對項目的危害性可不是遊戲，開發與運維陷入一場狂風暴雨，客戶則成了蒙受損失的一方，最終團隊失去了客戶，失去了金錢，失去了項目。

 

DevOps就是爲了讓開發和運維告別這樣的悲劇而被提出的。它是一種框架，包含了不少優秀想法和原則，它重視開發部門和運維部門打破隔牆，通力合做。

 

DevOps但願作到的是軟件產品交付過程當中IT工具鏈的打通，使得各個團隊減小時間損耗，更加高效地協同工做。專家們總結出了下面這個DevOps能力圖，良好的閉環能夠大大增長總體的產出。

 

 

在DevOps環境中，開發人員和系統管理員會構建一些關係、流程和工具，從而更好的與客戶互動，最終提供更好的服務。

 

DevOps的三大原則

基礎設施即代碼

DeveOps的基礎是將重複的事情使用自動化腳本或軟件來實現，例如Docker（容器化）、Jenkins（持續集成）、Puppet（基礎架構構建）、Vagrant（虛擬化平臺）等；

 

持續交付

持續交付是在生產環境發佈可靠的軟件並交付給用戶使用。而持續部署則不必定交付給用戶使用。涉及到2個時間，TTR（Time to Repair）修復時間，TTM（Time To Marketing）產品上線時間。要作到高效交付可靠的軟件，須要儘量的減小這2個時間。部署能夠有多種方式，好比藍綠部署、金絲雀部署等；

 

協同工做

開發者和運維人員必須按期進行密切的合做。開發應該把運維角色理解成軟件的另外一個用戶羣體。協做有幾個的建議：a、自動化（減小沒必要要的協做）；b、小範圍（每次修改的內容不宜過多，減小發布的風險）；c、統一信息集散地（如wiki，讓雙方可以共享信息）；d、標準化協做工具（好比jenkins）。

 

DevOps的影響

交付

使用DevOps有多爽？有調查報告發現，在2016年，根據全球4600位各IT公司的技術工做者的提交數據統計，得出使用DevOps的公司團隊平均每一年能夠完成1460次部署。與傳統組織相比，DevOps組織的部署頻繁200倍，產品投入使用速度快2555倍，服務恢復速度快24倍。

 

協調合做

強有力的發佈協調人彌合了開發與運營之間的技能鴻溝和溝通鴻溝，採用電子數據表、電話會議、即時消息、企業門戶（wiki、sharepoint）等協做工具來確保全部相關人員理解變動的內容並全力合做。

 

自動化

強大的部署自動化手段確保部署任務的可重複性、減小部署出錯的可能性。

 

現在，IT行業已經愈來愈與市場的經濟發展緊密掛鉤，可否讓公司的IT配套方案及時跟上市場需求的步伐，在今天顯得相當重要，DevOps或許就是給與公司和團隊的一劑良方。

 

最後推薦幾個在實現DevOps上已很成熟的項目管理工具：CORNERSTONE、Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker。

 

要說這些工具各有什麼特點，改天咱們再聊吧。話說不知道刺客信條故事的最後結局會不會也和運維與開發同樣，最終兩個派系握手言和共同進退呢……