討論：未來(lái)的運(yùn)維方式：DevOps？（獲獎(jiǎng)名單已公布-2014-7-31）

dc222222222

首先說(shuō)下，我是做運(yùn)維的，在我離開(kāi)我的項(xiàng)目時(shí)，開(kāi)發(fā)團(tuán)隊(duì)都認(rèn)為我是一個(gè)極好接觸的運(yùn)維，我特別感到欣慰。
我見(jiàn)過(guò)很多運(yùn)維抱怨“1個(gè)開(kāi)發(fā)累死10個(gè)運(yùn)維”，也見(jiàn)過(guò)很多開(kāi)發(fā)抱怨“運(yùn)維經(jīng)常電話不接，找不到人”。就我的經(jīng)驗(yàn)而言，運(yùn)維跟開(kāi)發(fā)主要有以下矛盾：
1，一個(gè)關(guān)注功能，一個(gè)關(guān)注性能：有的開(kāi)發(fā)為了追求速度，1下開(kāi)100個(gè)線程，導(dǎo)致服務(wù)器load 100+，cpu100%，運(yùn)維不斷收到短信，也有運(yùn)維為了提高服務(wù)器性能利用率，很多應(yīng)用都跑在同一臺(tái)服務(wù)器上。
2，各自只能組織KPI，開(kāi)發(fā)要求快速上線，并且穩(wěn)定 ，運(yùn)維要求成本節(jié)約，而且在沒(méi)有好的上線機(jī)制的前提小只能手動(dòng)去上線代碼，成本節(jié)約跟高效穩(wěn)定在初期階段看起來(lái)絕對(duì)是一個(gè)矛盾體。
3，各自知識(shí)點(diǎn)的欠缺，開(kāi)發(fā)為了給運(yùn)維將他們軟件的實(shí)現(xiàn)原理而大傷腦筋，運(yùn)維為了教開(kāi)發(fā)使用linux也是苦不堪言。
如果開(kāi)發(fā)要跟運(yùn)維做好協(xié)作，我認(rèn)為應(yīng)該做好以下幾個(gè)事情：
1，對(duì)于一個(gè)項(xiàng)目，雙方應(yīng)達(dá)到共識(shí)，早期關(guān)注功能，后期關(guān)注功能，早期，運(yùn)維可多參與開(kāi)發(fā)的會(huì)議，了解產(chǎn)品是如何工作的，后期開(kāi)發(fā)一定要找出產(chǎn)品的風(fēng)險(xiǎn)點(diǎn)，配合運(yùn)維降低因用戶量大引起的各種性能問(wèn)題。
2，kpi互通，畢竟是在公司嘛，誰(shuí)還沒(méi)有個(gè)kpi了，一般情況這些kpi都是合理的，其實(shí)也是做好一個(gè)項(xiàng)目必須做成的，所以大家需要了解彼此的kpi，協(xié)助對(duì)方去達(dá)成，這樣才能有個(gè)好的合作關(guān)系。
3，技術(shù)學(xué)習(xí)，互聯(lián)網(wǎng)的確是一個(gè)很龐大的體系，不管是開(kāi)發(fā)還是運(yùn)維，學(xué)到的都是冰山一角，就技術(shù)本身而言，最終都是對(duì)內(nèi)存，磁盤(pán)，cpu等硬件資源的使用，只是所處層次不樣，如果雙方都對(duì)計(jì)算機(jī)有很好的認(rèn)識(shí)，肯定能杜絕很多問(wèn)題，雙方合作也跟順暢。
關(guān)于devops，我推薦以下工具：
1，gitlab。天生的版本控制工具，配合jinkens，測(cè)試，上線，一步到位。
2，puppet。服務(wù)器狀態(tài)保持利器，可減少運(yùn)維很多工作量。
3，docker，資源分片利用，提供最合理的測(cè)試環(huán)境。

cfan0330

在亞馬遜看了樣書(shū)的目錄，覺(jué)得這個(gè)可能對(duì)剛剛接觸運(yùn)維的，或者是IDC的人比較有用，但如果要說(shuō)devops,個(gè)人感覺(jué)就差太遠(yuǎn)了，通篇書(shū)就只是說(shuō)了咋個(gè)處理查看一般的機(jī)器網(wǎng)絡(luò)環(huán)境問(wèn)題，其他就呵呵了，簡(jiǎn)單一句話，跟dev（開(kāi)發(fā)）根本不著邊

haide1014

運(yùn)維其實(shí)是高層