資訊專欄INFORMATION COLUMN
摘要：運維部門比較笨，他們不懂新技術(shù)，為什么他們沒法實現(xiàn)最新的技術(shù)呢為什么他們這么落伍呢在我的機器上運行的沒問題啊刺客聯(lián)盟與圣殿騎士互掐了幾百年，但事實上他倆都不過是想維護人類文明開發(fā)與運維互看不順眼，但他們的初心都是想這個項目能順利驗收。
從電子游戲到DevOps
在一個項目團隊中，開發(fā)與運維之間的關(guān)系像極了知名大型游戲《刺客信條》里的故事：開發(fā)就是追求自由的刺客聯(lián)盟——我喜歡用各種新穎技術(shù)手段去滿足用戶爸爸那些花里胡哨的需求，你別管那技術(shù)好不好用，總之它實現(xiàn)了需求；運維就是那支持秩序的圣殿騎士——我要的是穩(wěn)定運行！穩(wěn)定運行！穩(wěn)定運行??！
于是，產(chǎn)品與運維之間形成了一道墻。
開發(fā)部門夜以繼日地打造出自己的“杰作”，并懷著今晚就能開慶功會的心情把自己的“杰作”交給了運維部門，殊不知墻那面的運維們對開發(fā)的抱怨才剛剛開始：
l 這款優(yōu)秀的產(chǎn)品在目前的底層平臺上無法運行，因為這個平臺太古老了，因為這個平臺空間不足，因為這個平臺不支持某某版本……
l 這款產(chǎn)品的體系結(jié)構(gòu)跟我們的{存儲，網(wǎng)絡(luò)，部署，安全}模型不匹配。
l 這款產(chǎn)品的報告、安全、監(jiān)視、備份balabalabala 我們搞不懂 ，所以沒法把它做成實際可用的產(chǎn)品。
當(dāng)運維將問題源源不斷地反饋給開發(fā)后，開發(fā)的回復(fù)一定是：
l 這不是我們的錯，我們的代碼非常完美，是（運維部門的）部署做的太差勁了。
l 運維部門比較笨，他們不懂新技術(shù)，為什么他們沒法實現(xiàn)最新的技術(shù)呢？為什么他們這么落伍呢？
l 在我的機器上運行的沒問題啊……
刺客聯(lián)盟與圣殿騎士互掐了幾百年，但事實上他倆都不過是想維護人類文明；開發(fā)與運維互看不順眼，但他們的初心都是想這個項目能順利驗收。
雖然開發(fā)和運維這樣相愛相殺的關(guān)系看上去和游戲很像，但其對項目的危害性可不是游戲，開發(fā)與運維陷入一場暴風(fēng)驟雨，客戶則成了蒙受損失的一方，最終團隊失去了客戶，失去了金錢，失去了項目。
DevOps就是為了讓開發(fā)和運維告別這樣的悲劇而被提出的。它是一種框架，包含了很多優(yōu)秀想法和原則，它重視開發(fā)部門和運維部門打破隔墻，通力合作。
DevOps希望做到的是軟件產(chǎn)品交付過程中IT工具鏈的打通，使得各個團隊減少時間損耗，更加高效地協(xié)同工作。專家們總結(jié)出了下面這個DevOps能力圖，良好的閉環(huán)可以大大增加整體的產(chǎn)出。
在DevOps環(huán)境中，開發(fā)人員和系統(tǒng)管理員會構(gòu)建一些關(guān)系、流程和工具，從而更好的與客戶互動，最終提供更好的服務(wù)。
DevOps的三大原則
基礎(chǔ)設(shè)施即代碼
DeveOps的基礎(chǔ)是將重復(fù)的事情使用自動化腳本或軟件來實現(xiàn)，例如Docker（容器化）、Jenkins（持續(xù)集成）、Puppet（基礎(chǔ)架構(gòu)構(gòu)建）、Vagrant（虛擬化平臺）等；
持續(xù)交付
持續(xù)交付是在生產(chǎn)環(huán)境發(fā)布可靠的軟件并交付給用戶使用。而持續(xù)部署則不一定交付給用戶使用。涉及到2個時間，TTR（Time to Repair）修復(fù)時間，TTM（Time To Marketing）產(chǎn)品上線時間。要做到高效交付可靠的軟件，需要盡可能的減少這2個時間。部署可以有多種方式，比如藍綠部署、金絲雀部署等；
協(xié)同工作
開發(fā)者和運維人員必須定期進行密切的合作。開發(fā)應(yīng)該把運維角色理解成軟件的另一個用戶群體。協(xié)作有幾個的建議：a、自動化（減少不必要的協(xié)作）；b、小范圍（每次修改的內(nèi)容不宜過多，減少發(fā)布的風(fēng)險）；c、統(tǒng)一信息集散地（如wiki，讓雙方能夠共享信息）；d、標(biāo)準(zhǔn)化協(xié)作工具（比如jenkins）。
DevOps的影響
交付
使用DevOps有多爽？有調(diào)查報告發(fā)現(xiàn)，在2016年，根據(jù)全球4600位各IT公司的技術(shù)工作者的提交數(shù)據(jù)統(tǒng)計，得出使用DevOps的公司團隊平均每年可以完成1460次部署。與傳統(tǒng)組織相比，DevOps組織的部署頻繁200倍，產(chǎn)品投入使用速度快2555倍，服務(wù)恢復(fù)速度快24倍。
協(xié)調(diào)合作
強有力的發(fā)布協(xié)調(diào)人彌合了開發(fā)與運營之間的技能鴻溝和溝通鴻溝，采用電子數(shù)據(jù)表、電話會議、即時消息、企業(yè)門戶（wiki、sharepoint）等協(xié)作工具來確保所有相關(guān)人員理解變更的內(nèi)容并全力合作。
自動化
強大的部署自動化手段確保部署任務(wù)的可重復(fù)性、減少部署出錯的可能性。
如今，IT行業(yè)已經(jīng)越來越與市場的經(jīng)濟發(fā)展緊密掛鉤，能否讓公司的IT配套方案及時跟上市場需求的步伐，在今天顯得至關(guān)重要，DevOps或許就是給與公司和團隊的一劑良方。
最后推薦幾個在實現(xiàn)DevOps上已很成熟的項目管理工具：CORNERSTONE、Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker。
要說這些工具各有什么特色，改天我們再聊吧。話說不知道刺客信條故事的最后結(jié)局會不會也和運維與開發(fā)一樣，最終兩個派系握手言和共同進退呢……
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/114886.html
摘要：微店技術(shù)團隊公眾號容器化之路這是一套以阿里云為基礎(chǔ)，為核心，第三方服務(wù)為工具的開發(fā)測試部署流程，以及內(nèi)部的代碼提交，版本管理規(guī)范。如何打造安全的容器云平臺對，微服務(wù)，來說都是非常好的落地實踐技術(shù)。 在使用 flow.ci 進行持續(xù)集成的過程中，也許你會遇到一些小麻煩。最近我們整理了一些常見問題在 flow.ci 文檔之 FAQ，希望對你有用。如果你遇到其他問題，也可以通過「在線消息」或...
摘要：圍繞軟件工程效率提升進行一系列技術(shù)內(nèi)容分享，包括國內(nèi)外持續(xù)集成持續(xù)交付，持續(xù)部署自動化測試等實踐教程工具與資源，以及一些工程師文化相關(guān)的程序員。劃分了數(shù)據(jù)庫日志安全監(jiān)控配置管理云服務(wù)等個大類，個工具。 CI Weekly 圍繞『 軟件工程效率提升』 進行一系列技術(shù)內(nèi)容分享，包括國內(nèi)外持續(xù)集成、持續(xù)交付，持續(xù)部署、自動化測試、 DevOps 等實踐教程、工具與資源，以及一些工程師文化相關(guān)...
摘要：正在走遠，新年之初，小數(shù)精選過去一年閱讀量居高的技術(shù)干貨，從容器到微服務(wù)云原生，匯集成篇精華集錦，充分反映了這一年的技術(shù)熱點走向。此文值得收藏，方便隨時搜索和查看。，小數(shù)將繼續(xù)陪伴大家，為朋友們奉獻更有逼格的技術(shù)內(nèi)容。 2017正在走遠，新年之初，小數(shù)精選過去一年閱讀量居高的技術(shù)干貨，從容器、K8S 到微服務(wù)、云原生、Service Mesh，匯集成52篇精華集錦，充分反映了這一年的技...
閱讀 1002·2021-11-17 09:33
閱讀 471·2019-08-30 11:16
閱讀 2526·2019-08-29 16:05
閱讀 3406·2019-08-29 15:28
閱讀 1455·2019-08-29 11:29
閱讀 2003·2019-08-26 13:51
閱讀 3440·2019-08-26 11:55
閱讀 1271·2019-08-26 11:31
