很多企業(yè)，尤其是大企業(yè)在產(chǎn)品開(kāi)發(fā)和運(yùn)維上存在著一些普遍問(wèn)題，比如開(kāi)發(fā)周期長(zhǎng)、人員合作程度不高、開(kāi)發(fā)和運(yùn)維脫節(jié)等等?？煽纯匆恍┚扌推髽I(yè)，比如Google，Amazon，F(xiàn)acebook,Salesforce等等，人家的規(guī)模不比你大，架構(gòu)不必你復(fù)雜?為什么他們能做到大而靈?

成功的因素固然有很多，而一個(gè)共同的因素是，他們都引入了DevOps的概念。

DevOps是基于Agile和Lean發(fā)展而來(lái)的一種理念，目的是更好的優(yōu)化開(kāi)發(fā)和運(yùn)維的流程，從而更快、更高效的實(shí)現(xiàn)產(chǎn)品更新。DevOps是由Development + Operation縮寫(xiě)而來(lái)，但絕不是二者的簡(jiǎn)單相加。引入DevOps需要在企業(yè)文化和技術(shù)上都要落實(shí)一些措施。

在我們進(jìn)一步介紹該理念之前，本文來(lái)探討一些我見(jiàn)過(guò)的IT環(huán)境中的問(wèn)題，尤其是在大企業(yè)中有普遍性的問(wèn)題。

上圖想說(shuō)的是由于組織結(jié)構(gòu)、文化以及技術(shù)局限性的多種原因，各個(gè)組負(fù)責(zé)自己的一畝三分地，別組的事情不管我事，我也根本不知道別人在干什么。那產(chǎn)生的后果呢，咱們從項(xiàng)目的各個(gè)環(huán)節(jié)一一道來(lái)。

設(shè)計(jì)階段

需求分析和后面的環(huán)節(jié)脫鉤。往往大費(fèi)時(shí)間精力制定的需求，在后續(xù)階段中不能很好的執(zhí)行?？赡艿脑蛴校阂恍枨蟊旧淼馁|(zhì)量不高，沒(méi)有很好的衡量手段和標(biāo)準(zhǔn)二需求沒(méi)有體現(xiàn)整個(gè)LifeCycle，往往忽視運(yùn)維中可能出現(xiàn)的問(wèn)題三只注重Functional Requirements , 而忽略Non-Functional Requirement

另外需求更改是難免的，可合同已經(jīng)簽了。按照Change Control的規(guī)定，需要重新評(píng)估時(shí)間，人力及風(fēng)險(xiǎn)，這一趟下來(lái)時(shí)間上的損失不說(shuō)，非常耗精力。

開(kāi)發(fā)階段

實(shí)施人員可能對(duì)設(shè)計(jì)本身的了解不透徹，更別說(shuō)對(duì)需求的把握了。做出來(lái)的東西有時(shí)走了樣，忘了本來(lái)的目的是什么。

測(cè)試階段

Unit Testing，integration Testing, Performance Testing, Stress Testing, UserAcceptance Testing. 整個(gè)測(cè)試階段耗時(shí)耗力，測(cè)試人員有時(shí)閑的要死，有時(shí)忙的要死。各個(gè)測(cè)試之間的協(xié)調(diào)也是問(wèn)題。

運(yùn)維階段

大型復(fù)雜項(xiàng)目中往往一個(gè)Change需要涉及多個(gè)團(tuán)隊(duì)，本來(lái)30分鐘的活兒，你要想每個(gè)組都批準(zhǔn)Change可能要數(shù)天甚至數(shù)周。運(yùn)維中出了問(wèn)題呢，各個(gè)組之間扯皮推脫自是家常便飯。怕的是有的時(shí)候根本不知道哪出了問(wèn)題，也可能整個(gè)系統(tǒng)靠個(gè)別技術(shù)牛人來(lái)?yè)沃?，其他人沒(méi)有也不知道如何下手。

解決方案

發(fā)牢騷誰(shuí)都會(huì)，那么有解決辦法么?當(dāng)然有，不過(guò)這可不是什么靈丹妙藥，一吃就靈。需要從上至下，在文化上和技術(shù)上都要有下大力氣才行。請(qǐng)關(guān)注下文將展開(kāi)DevOps的一些實(shí)施細(xì)節(jié)。

原文鏈接：http://frankfan.blog.51cto.com/6402282/1255642