摘要：運(yùn)維部門比較笨，他們不懂新技術(shù)，為什么他們沒法實(shí)現(xiàn)最新的技術(shù)呢為什么他們這么落伍呢在我的機(jī)器上運(yùn)行的沒問題啊刺客聯(lián)盟與圣殿騎士互掐了幾百年，但事實(shí)上他倆都不過是想維護(hù)人類文明開發(fā)與運(yùn)維互看不順眼，但他們的初心都是想這個(gè)項(xiàng)目能順利驗(yàn)收。

從電子游戲到DevOps
在一個(gè)項(xiàng)目團(tuán)隊(duì)中，開發(fā)與運(yùn)維之間的關(guān)系像極了知名大型游戲《刺客信條》里的故事：開發(fā)就是追求自由的刺客聯(lián)盟——我喜歡用各種新穎技術(shù)手段去滿足用戶爸爸那些花里胡哨的需求，你別管那技術(shù)好不好用，總之它實(shí)現(xiàn)了需求；運(yùn)維就是那支持秩序的圣殿騎士——我要的是穩(wěn)定運(yùn)行！穩(wěn)定運(yùn)行！穩(wěn)定運(yùn)行??！

于是，產(chǎn)品與運(yùn)維之間形成了一道墻。
開發(fā)部門夜以繼日地打造出自己的“杰作”，并懷著今晚就能開慶功會的心情把自己的“杰作”交給了運(yùn)維部門，殊不知墻那面的運(yùn)維們對開發(fā)的抱怨才剛剛開始：
l 這款優(yōu)秀的產(chǎn)品在目前的底層平臺上無法運(yùn)行，因?yàn)檫@個(gè)平臺太古老了，因?yàn)檫@個(gè)平臺空間不足，因?yàn)檫@個(gè)平臺不支持某某版本……
l 這款產(chǎn)品的體系結(jié)構(gòu)跟我們的{存儲，網(wǎng)絡(luò)，部署，安全}模型不匹配。
l 這款產(chǎn)品的報(bào)告、安全、監(jiān)視、備份balabalabala 我們搞不懂 ，所以沒法把它做成實(shí)際可用的產(chǎn)品。
當(dāng)運(yùn)維將問題源源不斷地反饋給開發(fā)后，開發(fā)的回復(fù)一定是：
l 這不是我們的錯(cuò)，我們的代碼非常完美，是（運(yùn)維部門的）部署做的太差勁了。
l 運(yùn)維部門比較笨，他們不懂新技術(shù)，為什么他們沒法實(shí)現(xiàn)最新的技術(shù)呢？為什么他們這么落伍呢？
l 在我的機(jī)器上運(yùn)行的沒問題啊……
刺客聯(lián)盟與圣殿騎士互掐了幾百年，但事實(shí)上他倆都不過是想維護(hù)人類文明；開發(fā)與運(yùn)維互看不順眼，但他們的初心都是想這個(gè)項(xiàng)目能順利驗(yàn)收。
雖然開發(fā)和運(yùn)維這樣相愛相殺的關(guān)系看上去和游戲很像，但其對項(xiàng)目的危害性可不是游戲，開發(fā)與運(yùn)維陷入一場暴風(fēng)驟雨，客戶則成了蒙受損失的一方，最終團(tuán)隊(duì)失去了客戶，失去了金錢，失去了項(xiàng)目。
DevOps就是為了讓開發(fā)和運(yùn)維告別這樣的悲劇而被提出的。它是一種框架，包含了很多優(yōu)秀想法和原則，它重視開發(fā)部門和運(yùn)維部門打破隔墻，通力合作。
DevOps希望做到的是軟件產(chǎn)品交付過程中IT工具鏈的打通，使得各個(gè)團(tuán)隊(duì)減少時(shí)間損耗，更加高效地協(xié)同工作。專家們總結(jié)出了下面這個(gè)DevOps能力圖，良好的閉環(huán)可以大大增加整體的產(chǎn)出。

在DevOps環(huán)境中，開發(fā)人員和系統(tǒng)管理員會構(gòu)建一些關(guān)系、流程和工具，從而更好的與客戶互動，最終提供更好的服務(wù)。
DevOps的三大原則
基礎(chǔ)設(shè)施即代碼
DeveOps的基礎(chǔ)是將重復(fù)的事情使用自動化腳本或軟件來實(shí)現(xiàn)，例如Docker（容器化）、Jenkins（持續(xù)集成）、Puppet（基礎(chǔ)架構(gòu)構(gòu)建）、Vagrant（虛擬化平臺）等；
持續(xù)交付
持續(xù)交付是在生產(chǎn)環(huán)境發(fā)布可靠的軟件并交付給用戶使用。而持續(xù)部署則不一定交付給用戶使用。涉及到2個(gè)時(shí)間，TTR（Time to Repair）修復(fù)時(shí)間，TTM（Time To Marketing）產(chǎn)品上線時(shí)間。要做到高效交付可靠的軟件，需要盡可能的減少這2個(gè)時(shí)間。部署可以有多種方式，比如藍(lán)綠部署、金絲雀部署等；
協(xié)同工作
開發(fā)者和運(yùn)維人員必須定期進(jìn)行密切的合作。開發(fā)應(yīng)該把運(yùn)維角色理解成軟件的另一個(gè)用戶群體。協(xié)作有幾個(gè)的建議：a、自動化（減少不必要的協(xié)作）；b、小范圍（每次修改的內(nèi)容不宜過多，減少發(fā)布的風(fēng)險(xiǎn)）；c、統(tǒng)一信息集散地（如wiki，讓雙方能夠共享信息）；d、標(biāo)準(zhǔn)化協(xié)作工具（比如jenkins）。
DevOps的影響
交付
使用DevOps有多爽？有調(diào)查報(bào)告發(fā)現(xiàn)，在2016年，根據(jù)全球4600位各IT公司的技術(shù)工作者的提交數(shù)據(jù)統(tǒng)計(jì)，得出使用DevOps的公司團(tuán)隊(duì)平均每年可以完成1460次部署。與傳統(tǒng)組織相比，DevOps組織的部署頻繁200倍，產(chǎn)品投入使用速度快2555倍，服務(wù)恢復(fù)速度快24倍。
協(xié)調(diào)合作
強(qiáng)有力的發(fā)布協(xié)調(diào)人彌合了開發(fā)與運(yùn)營之間的技能鴻溝和溝通鴻溝，采用電子數(shù)據(jù)表、電話會議、即時(shí)消息、企業(yè)門戶（wiki、sharepoint）等協(xié)作工具來確保所有相關(guān)人員理解變更的內(nèi)容并全力合作。
自動化
強(qiáng)大的部署自動化手段確保部署任務(wù)的可重復(fù)性、減少部署出錯(cuò)的可能性。
如今，IT行業(yè)已經(jīng)越來越與市場的經(jīng)濟(jì)發(fā)展緊密掛鉤，能否讓公司的IT配套方案及時(shí)跟上市場需求的步伐，在今天顯得至關(guān)重要，DevOps或許就是給與公司和團(tuán)隊(duì)的一劑良方。
最后推薦幾個(gè)在實(shí)現(xiàn)DevOps上已很成熟的項(xiàng)目管理工具：CORNERSTONE、Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker。
要說這些工具各有什么特色，改天我們再聊吧。話說不知道刺客信條故事的最后結(jié)局會不會也和運(yùn)維與開發(fā)一樣，最終兩個(gè)派系握手言和共同進(jìn)退呢……