【DevOps】誰說大象不能跳舞?
很多企業(yè)，尤其是大企業(yè)在產(chǎn)品開發(fā)和運(yùn)維上存在著一些普遍問題，比如開發(fā)周期長、人員合作程度不高、開發(fā)和運(yùn)維脫節(jié)等等。可看看一些巨型企業(yè)，比如Google，Amazon，F(xiàn)acebook,Salesforce等等，人家的規(guī)模不比你大，架構(gòu)不必你復(fù)雜?為什么他們能做到大而靈?
成功的因素固然有很多，而一個共同的因素是，他們都引入了DevOps的概念。
DevOps是基于Agile和Lean發(fā)展而來的一種理念，目的是更好的優(yōu)化開發(fā)和運(yùn)維的流程，從而更快、更高效的實(shí)現(xiàn)產(chǎn)品更新。DevOps是由Development + Operation縮寫而來，但絕不是二者的簡單相加。引入DevOps需要在企業(yè)文化和技術(shù)上都要落實(shí)一些措施。
在我們進(jìn)一步介紹該理念之前，本文來探討一些我見過的IT環(huán)境中的問題，尤其是在大企業(yè)中有普遍性的問題。
上圖想說的是由于組織結(jié)構(gòu)、文化以及技術(shù)局限性的多種原因，各個組負(fù)責(zé)自己的一畝三分地，別組的事情不管我事，我也根本不知道別人在干什么。那產(chǎn)生的后果呢，咱們從項(xiàng)目的各個環(huán)節(jié)一一道來。
設(shè)計(jì)階段
需求分析和后面的環(huán)節(jié)脫鉤。往往大費(fèi)時間精力制定的需求，在后續(xù)階段中不能很好的執(zhí)行。可能的原因有：一需求本身的質(zhì)量不高，沒有很好的衡量手段和標(biāo)準(zhǔn)二需求沒有體現(xiàn)整個LifeCycle，往往忽視運(yùn)維中可能出現(xiàn)的問題三只注重Functional Requirements , 而忽略Non-Functional Requirement
另外需求更改是難免的，可合同已經(jīng)簽了。按照Change Control的規(guī)定，需要重新評估時間，人力及風(fēng)險(xiǎn)，這一趟下來時間上的損失不說，非常耗精力。
開發(fā)階段
實(shí)施人員可能對設(shè)計(jì)本身的了解不透徹，更別說對需求的把握了。做出來的東西有時走了樣，忘了本來的目的是什么。
測試階段
Unit Testing，integration Testing, Performance Testing, Stress Testing, UserAcceptance Testing. 整個測試階段耗時耗力，測試人員有時閑的要死，有時忙的要死。各個測試之間的協(xié)調(diào)也是問題。
運(yùn)維階段
大型復(fù)雜項(xiàng)目中往往一個Change需要涉及多個團(tuán)隊(duì)，本來30分鐘的活兒，你要想每個組都批準(zhǔn)Change可能要數(shù)天甚至數(shù)周。運(yùn)維中出了問題呢，各個組之間扯皮推脫自是家常便飯。怕的是有的時候根本不知道哪出了問題，也可能整個系統(tǒng)靠個別技術(shù)牛人來撐著，其他人沒有也不知道如何下手。
解決方案
發(fā)牢騷誰都會，那么有解決辦法么?當(dāng)然有，不過這可不是什么靈丹妙藥，一吃就靈。需要從上至下，在文化上和技術(shù)上都要有下大力氣才行。請關(guān)注下文將展開DevOps的一些實(shí)施細(xì)節(jié)。
