一、技術(shù)團(tuán)隊(duì)細(xì)分及配合問(wèn)題

在IT企業(yè)里產(chǎn)品從創(chuàng)意到交付給用戶，從整體上看是由技術(shù)部門負(fù)責(zé)，但如果深入到技術(shù)部門，會(huì)發(fā)現(xiàn)由不同的技術(shù)團(tuán)隊(duì)負(fù)責(zé)不同的部分或者階段。一般會(huì)分產(chǎn)品團(tuán)隊(duì)、開(kāi)發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)以及運(yùn)維團(tuán)隊(duì)，在互聯(lián)網(wǎng)公司里，運(yùn)維團(tuán)隊(duì)一般還分基礎(chǔ)運(yùn)維和產(chǎn)品運(yùn)維兩個(gè)團(tuán)隊(duì)，基礎(chǔ)運(yùn)維負(fù)責(zé)基礎(chǔ)設(shè)施(包括機(jī)架、網(wǎng)絡(luò)、硬件)和操作系統(tǒng)的安裝，為整體公司的所有產(chǎn)品提供基礎(chǔ)設(shè)施的運(yùn)維服務(wù)。而產(chǎn)品運(yùn)維負(fù)責(zé)線上產(chǎn)品的問(wèn)題處理、代碼的布署和跟開(kāi)發(fā)的接口等。

不同的技術(shù)團(tuán)隊(duì)一般隸屬不同的部門，分散在公司不同的辦公區(qū)域，團(tuán)隊(duì)內(nèi)部的溝通相對(duì)多一些，但團(tuán)隊(duì)之間的溝通較少。不同團(tuán)隊(duì)都會(huì)形成自己的辦事習(xí)慣、節(jié)奏，都有自己的關(guān)注點(diǎn)，一般只是知道與之接口的團(tuán)隊(duì)的總體職責(zé)，但是不知道對(duì)方可能面臨的困難與工作中的挑戰(zhàn)點(diǎn)。另外，如果公司夠大，每個(gè)團(tuán)隊(duì)內(nèi)部又會(huì)分為許更細(xì)的小團(tuán)隊(duì)，如基礎(chǔ)運(yùn)維一般有系統(tǒng)團(tuán)隊(duì)、網(wǎng)絡(luò)團(tuán)隊(duì)和IDC團(tuán)隊(duì)等，這樣更加重了團(tuán)隊(duì)之間溝通難度。

從產(chǎn)品策劃到上線，一般是以下邊的順序經(jīng)過(guò)各個(gè)團(tuán)隊(duì)：

1. 開(kāi)發(fā)團(tuán)隊(duì)收集產(chǎn)品的需求，定下時(shí)間表并進(jìn)行開(kāi)發(fā)
2. 開(kāi)發(fā)完后，交由測(cè)試或質(zhì)量團(tuán)隊(duì)進(jìn)行測(cè)試
3. 然后交給運(yùn)維團(tuán)隊(duì)布署新產(chǎn)品或新版本
4. 運(yùn)維團(tuán)隊(duì)將運(yùn)維過(guò)程中發(fā)現(xiàn)的代碼缺陷反饋給開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行修復(fù)

在上面的每個(gè)階段，對(duì)應(yīng)的團(tuán)隊(duì)都是各做各的，一般是在***才會(huì)把球踢給下一個(gè)團(tuán)隊(duì)，如果下一個(gè)團(tuán)隊(duì)發(fā)現(xiàn)問(wèn)題又會(huì)把球踢回原來(lái)的團(tuán)隊(duì)。如果你深入到不同的團(tuán)隊(duì)中去，或聽(tīng)到不同的抱怨聲音。

基礎(chǔ)運(yùn)維團(tuán)隊(duì)經(jīng)常抱怨：

• 產(chǎn)品開(kāi)發(fā)一點(diǎn)計(jì)劃都沒(méi)有，突然要上線機(jī)器，讓我們措手不及。
• 每個(gè)產(chǎn)品都急著上線，誰(shuí)催得急就上誰(shuí)的，誰(shuí)能說(shuō)一下，到底那個(gè)重要？
• 動(dòng)不動(dòng)就要重裝系統(tǒng)，壞了一塊盤就著急去修，剛從機(jī)房回來(lái)，又要過(guò)去。
• 上線太突然了，沒(méi)有交換機(jī)，沒(méi)有機(jī)架，還需要搬別的機(jī)器騰地方。
• 那個(gè)地方有機(jī)架和交換機(jī)端口，但沒(méi)有四層設(shè)備，他們又要放在四層后邊，真的沒(méi)有辦法了。
• 剛跟他們上線到一個(gè)機(jī)房，他們又說(shuō)要換到另一個(gè)機(jī)房，盡折騰。
• 他們?cè)趺茨苣敲从迷O(shè)備，把上連端口帶寬都跑滿了。

產(chǎn)品運(yùn)維團(tuán)隊(duì)會(huì)說(shuō)：

• 真沒(méi)辦法，上個(gè)線不是說(shuō)沒(méi)機(jī)架，就是沒(méi)有交換機(jī)，還有就是說(shuō)沒(méi)有四層設(shè)備。
• 從來(lái)不告訴我們什么時(shí)候能設(shè)備能上線交付給我們，不派專人催著這事，一點(diǎn)譜都沒(méi)有。
• 本來(lái)沒(méi)有想好怎么用這些設(shè)備，先提前一個(gè)月申請(qǐng)上線，得我們想清楚了，他們卻說(shuō)又得換機(jī)房。
• 網(wǎng)絡(luò)怎么老是出問(wèn)題，他們?cè)趺匆?guī)劃的。
• 開(kāi)發(fā)的代碼太不靠譜，一上線就引發(fā)用戶投訴，只能回滾到老版本。
• 開(kāi)發(fā)人員的技術(shù)能力不行，寫不出能用的版本。
• 開(kāi)發(fā)要求有一個(gè)跟生產(chǎn)環(huán)境一樣的測(cè)試環(huán)境，這不可能有的。

而開(kāi)發(fā)團(tuán)隊(duì)卻說(shuō)：

• 他們又不讓我們碰線上的系統(tǒng)，生產(chǎn)環(huán)境是什么樣，我們都不知道，沒(méi)法開(kāi)發(fā)代碼。
• 我們辛苦開(kāi)發(fā)幾個(gè)月，上線出問(wèn)題又直接回滾了，心情很不好受。
• 代碼在測(cè)試環(huán)境或我的機(jī)器跑的好好的呀，怎么一上線就出問(wèn)題呢。
• 測(cè)試怎么測(cè)的，那么多問(wèn)題發(fā)現(xiàn)不了。
• 我們希望產(chǎn)品運(yùn)維同事幫忙搭一個(gè)跟線上一模一樣的測(cè)試環(huán)境。

另外，測(cè)試團(tuán)隊(duì)的人也許會(huì)說(shuō)：

• 開(kāi)發(fā)人員不寫規(guī)定寫單元測(cè)試代碼。
• 想著能用一個(gè)自動(dòng)的集成測(cè)試環(huán)境，因?yàn)殚_(kāi)發(fā)的原因，老是實(shí)現(xiàn)不了。
• 測(cè)試環(huán)境跟生產(chǎn)環(huán)境不一樣，好多問(wèn)題才發(fā)現(xiàn)
• 還有那么多的bug沒(méi)有解決，產(chǎn)品就催著上線。

二、技術(shù)團(tuán)隊(duì)之間配合不好的影響

上面看到的團(tuán)隊(duì)之間的沖突和抱怨問(wèn)題雖然都不一樣，產(chǎn)生的影響確是類似的：

• 產(chǎn)品上線的進(jìn)度延誤，整個(gè)團(tuán)隊(duì)很難正常交付新版本。
• 產(chǎn)品上線后問(wèn)題很多，影響用戶的訪問(wèn)。
• 團(tuán)隊(duì)的士氣很差。

最近又發(fā)生了運(yùn)維團(tuán)隊(duì)與開(kāi)發(fā)團(tuán)隊(duì)之間的配合不好的問(wèn)題，影響及原因如下：

1. 新產(chǎn)品上線延誤了兩個(gè)星期，正常情況下一天就可以上線。原因是開(kāi)發(fā)考慮不周，測(cè)試環(huán)境中沒(méi)有發(fā)現(xiàn)，到上線前才發(fā)現(xiàn)部署到多臺(tái)機(jī)器上后，按開(kāi)發(fā)原先計(jì)劃的方式多臺(tái)機(jī)器無(wú)法協(xié)作完成任務(wù)。還有就是在設(shè)計(jì)階段沒(méi)有考慮生產(chǎn)環(huán)境的狀況，在上線的過(guò)程中需要做出對(duì)應(yīng)的代碼調(diào)整。
2. 上線后質(zhì)量不穩(wěn)定，出現(xiàn)多次緊急修復(fù)。原因同上。
3. 臨時(shí)增加硬件投入。新產(chǎn)品中有個(gè)組件采用全新的技術(shù)方案，跟原來(lái)的LAMP體系不兼容，所以需要新增機(jī)器，單獨(dú)部署。
4. 除低了服務(wù)可用性標(biāo)準(zhǔn)，并產(chǎn)生了遺留問(wèn)題。因?yàn)榕R時(shí)需要增加硬件，而恰好又只有一臺(tái)，這樣就形成了單點(diǎn)，如果該機(jī)器出現(xiàn)故障，服務(wù)將全部中斷。另外，由于開(kāi)發(fā)前設(shè)計(jì)上考慮不周，跟別的組件集成時(shí)產(chǎn)生別的單點(diǎn)。所以這些降低了服務(wù)的可用性，以后還得想辦法解決。除此之外，組件采有新的軟件，安裝、服務(wù)起停以及軟件配置的管理都是純手工打造，以后還得找時(shí)間納入到自動(dòng)配置管理中。
5. 影響了團(tuán)隊(duì)士氣。在上線過(guò)程中開(kāi)發(fā)、測(cè)試和運(yùn)維都覺(jué)得不舒服，相互之間產(chǎn)生了抱怨。如果不處理好，會(huì)影響以后的配合。

雖然，有些問(wèn)題確實(shí)需要靠某些團(tuán)隊(duì)提高自身的人員技能才能解決好，但這些團(tuán)隊(duì)能夠形成一股合力的話，同樣的人員組合肯定會(huì)產(chǎn)生更好的效果。

三、過(guò)去解決團(tuán)隊(duì)配合問(wèn)題的方法

***次碰到團(tuán)隊(duì)之間的配合問(wèn)題時(shí)，我們還沒(méi)來(lái)得及解決的時(shí)候，公司戰(zhàn)略調(diào)整，整個(gè)開(kāi)發(fā)和系統(tǒng)運(yùn)營(yíng)團(tuán)隊(duì)轉(zhuǎn)給了另一個(gè)大部門。但我們?cè)趧e的地方重新梳理技術(shù)團(tuán)隊(duì)時(shí)，后來(lái)又沒(méi)有出現(xiàn)這種問(wèn)題，回想起來(lái)，我們的做法是：

• 部分開(kāi)發(fā)人員有生產(chǎn)環(huán)境中服務(wù)器的帳號(hào)，可以觀察代碼的運(yùn)轉(zhuǎn)情況，少數(shù)核心開(kāi)發(fā)人員還有sudo權(quán)限，當(dāng)然他們也不會(huì)隨便修改服務(wù)器的設(shè)置
• 開(kāi)發(fā)時(shí)一開(kāi)始就會(huì)跟系統(tǒng)運(yùn)維團(tuán)隊(duì)溝通，在代碼中增加數(shù)據(jù)收集的接口和監(jiān)控接口，這樣上線后，很容易收集產(chǎn)品的性能數(shù)據(jù)，并能方便地對(duì)運(yùn)行狀態(tài)進(jìn)行監(jiān)控與報(bào)警
• 生產(chǎn)環(huán)境中也有沙箱與beta環(huán)境，這樣大的版本從測(cè)試中過(guò)渡到生產(chǎn)環(huán)境前，先在沙箱環(huán)境中適應(yīng)一段時(shí)間，這樣能相對(duì)平穩(wěn)過(guò)渡到生產(chǎn)環(huán)境
• 部分開(kāi)發(fā)人員臨時(shí)轉(zhuǎn)到系統(tǒng)運(yùn)維團(tuán)隊(duì)工作一到二個(gè)季度，跟系統(tǒng)運(yùn)維同事一起上線產(chǎn)品，解決產(chǎn)品在運(yùn)行中發(fā)生的問(wèn)題，這樣更好地了解代碼如何在生產(chǎn)環(huán)境中運(yùn)行，回去之后能更好地運(yùn)維同事溝通，開(kāi)發(fā)出來(lái)的代碼更容易在生產(chǎn)環(huán)境中運(yùn)行

這樣，不同團(tuán)隊(duì)之間雖然有職責(zé)上的明確分工，但在中間的配合的部分做了不少柔性處理。另外，開(kāi)發(fā)、運(yùn)維與測(cè)試等團(tuán)隊(duì)中的核心人員之間本身就有認(rèn)同感，大家一開(kāi)始的目標(biāo)就是奔著公司能成功來(lái)的，這是沒(méi)有出配合問(wèn)題的根本原因。這一點(diǎn)其實(shí)跟DevOps的核心點(diǎn)類似，既然如此，何不重新審視一下DevOps，并參考著解決團(tuán)隊(duì)之間的配合問(wèn)題呢。

四、DevOps

DevOps是2010年從歐洲傳過(guò)來(lái)的概念，***是由一群有著跨學(xué)科技能的工程師提出來(lái)的，為了解決下面的問(wèn)題：

• 推出新功能和解決老問(wèn)題的周期過(guò)長(zhǎng)
• 新產(chǎn)品或新版本上線充滿風(fēng)險(xiǎn)，代碼能否在生產(chǎn)環(huán)境中穩(wěn)定運(yùn)行，沒(méi)有人有信心，只能艱難地推上去，再看是不是有問(wèn)題
• 不同團(tuán)隊(duì)相互隔離，配合差。如開(kāi)發(fā)人員收到問(wèn)題后，***反應(yīng)是“在我的機(jī)器上工作得好好的呀”

我認(rèn)為DevOps的核心是不管你是開(kāi)發(fā)者、測(cè)試人員、管理者、DBA、網(wǎng)絡(luò)工程師還是系統(tǒng)管理員，大家都是一起的，只有一起努力給客戶提供穩(wěn)定而高質(zhì)量的軟件服務(wù)，實(shí)現(xiàn)公司的商業(yè)利益才會(huì)有別的，包括自己的工作機(jī)會(huì)。

所以，DevOps實(shí)際是給各個(gè)團(tuán)隊(duì)之間搭橋，讓他們不僅僅是依靠上線申請(qǐng)單這樣的鴻雁傳書(shū)工具進(jìn)行溝通，而且經(jīng)常離開(kāi)自己的孤島，走到別人的島上去，了解別人，并提供自己的想法，幫助對(duì)方。

DevOps更象是一種運(yùn)動(dòng)，每家公司都需要根椐自身的特點(diǎn)進(jìn)行借鑒，推動(dòng)團(tuán)隊(duì)之間的協(xié)作與合作。需要在三個(gè)方面努力：

1. 人員

一方面對(duì)現(xiàn)有人員進(jìn)行培訓(xùn)，鼓勵(lì)他們了解別的團(tuán)隊(duì)的工作、面臨的挑戰(zhàn)等，讓他們用自己的特長(zhǎng)去審視和幫助別的團(tuán)隊(duì)，另一方面也想辦法招一些全面的技術(shù)人才，在不同團(tuán)隊(duì)之間搭出一些適用的橋來(lái)。

2. 流程

在研發(fā)的前期，讓系統(tǒng)運(yùn)維同事參與起來(lái)，一起搭建測(cè)試環(huán)境，驗(yàn)證想法，或者也可以在一些項(xiàng)目團(tuán)隊(duì)中直接配有系統(tǒng)、開(kāi)發(fā)和測(cè)試以及產(chǎn)品人員，一起為產(chǎn)品的上線努力。出現(xiàn)問(wèn)題的時(shí)候，一起想方法找到問(wèn)題的真正根源，避免相互推托，將解決方案落實(shí)在以后的研發(fā)過(guò)程中。從績(jī)效考核流程上也需要考慮協(xié)作因素。

3. 工具

說(shuō)實(shí)在的，大家針對(duì)DevOps在工具方面其實(shí)討論得更多，這里面跟敏捷有些類似之處?？焖俚南到y(tǒng)部署和自動(dòng)化產(chǎn)品代碼發(fā)布方面的工具顯得尤為重要了。

為了避免校彎過(guò)正，走向另一個(gè)極端，也需要避免下面的對(duì)DevOps的常見(jiàn)誤解：

1. DevOps意味著要給開(kāi)發(fā)者root權(quán)限

可以給開(kāi)發(fā)者加sudo權(quán)限，運(yùn)行指定的命令，比如重啟web服務(wù)。讓開(kāi)發(fā)者更多地了解生產(chǎn)環(huán)境和產(chǎn)品的運(yùn)行狀況，但并不意味著讓開(kāi)發(fā)者象管理員一樣的去管理機(jī)器。

2. 所有系統(tǒng)管理員需要寫代碼，所有開(kāi)發(fā)者需要上架機(jī)器

在系統(tǒng)管理和開(kāi)發(fā)者各個(gè)領(lǐng)域仍然需要各自的專家，如存儲(chǔ)、網(wǎng)絡(luò)、安裝、javascript等專門的人才，DevOps并不意味著讓大家不做自己專長(zhǎng)的事情。

3. 你一定要用某個(gè)工具，不然就不是DevOps

一些技術(shù)和自動(dòng)化的工具對(duì)推動(dòng)各個(gè)團(tuán)隊(duì)之間協(xié)作很有幫助，但是還是需要聚焦于要解決的問(wèn)題，根椐問(wèn)題和組織的特點(diǎn)選擇合適的工具。

4. 我們需要招聘DevOps

DevOps不是一個(gè)新的崗位

五、結(jié)合DevOps，解決團(tuán)隊(duì)配合問(wèn)題

管理人員關(guān)注團(tuán)隊(duì)之間的溝通機(jī)制及氛圍：

• 以新版能在生產(chǎn)環(huán)境中可靠穩(wěn)定運(yùn)行為目標(biāo)，形成協(xié)作的氛圍。
• 在項(xiàng)目的早期，立項(xiàng)之間，運(yùn)維、開(kāi)發(fā)與測(cè)試就進(jìn)行溝通，可能的話坐在一起，面對(duì)面溝通。
• 在項(xiàng)目上線前，除了測(cè)試功能，還要關(guān)注部署、備份、監(jiān)控、安全以及配置管理，在早期發(fā)現(xiàn)的問(wèn)題越多，越能盡少后期的問(wèn)題并避免影響用戶體驗(yàn)。
• 建立各個(gè)團(tuán)隊(duì)的核心成員定期溝通機(jī)制。
• 團(tuán)隊(duì)之間的協(xié)作納入績(jī)效考核過(guò)程中去。

讓開(kāi)發(fā)人員了解運(yùn)維工作、關(guān)注點(diǎn)及挑戰(zhàn)，并從開(kāi)發(fā)視角幫助運(yùn)維：

• 開(kāi)發(fā)人員參與運(yùn)維團(tuán)隊(duì)的內(nèi)部培訓(xùn)，了解線上的系統(tǒng)。
• 了解運(yùn)維如何定位并解決故障、如何監(jiān)控系統(tǒng)的運(yùn)轉(zhuǎn)情況等。
• 少數(shù)開(kāi)發(fā)人員可以跟運(yùn)維一樣發(fā)版本到生產(chǎn)環(huán)境中，讓開(kāi)發(fā)人員關(guān)注并了解自己代碼的運(yùn)行情況。
• 從運(yùn)維的視角修改代碼，方便運(yùn)維人員進(jìn)行日常的變更與調(diào)整，監(jiān)控與報(bào)警。
• 幫助運(yùn)維人員修改puppet配置模板。
• 幫助運(yùn)維人員編寫與修改產(chǎn)品的發(fā)布腳本，提高自動(dòng)化水平。

讓運(yùn)維人員了解開(kāi)發(fā)過(guò)程的關(guān)注點(diǎn)及挑戰(zhàn)，并從運(yùn)維角度改善開(kāi)發(fā)過(guò)程：

• 運(yùn)維為開(kāi)發(fā)在公司搭建基于虛擬機(jī)的測(cè)試環(huán)境，虛擬機(jī)的安裝、配置管理以及代碼的發(fā)布采用跟生產(chǎn)環(huán)境一樣的方式。
• 開(kāi)發(fā)人員與測(cè)試人員象運(yùn)維一樣發(fā)布版本到測(cè)試環(huán)境中。
• 鼓勵(lì)開(kāi)發(fā)與測(cè)試人員修改puppet配置與模板，管理自己的虛擬機(jī)。
• 在生產(chǎn)環(huán)境中建立了beta環(huán)境，開(kāi)發(fā)人員可以直接發(fā)版本上去，讓代碼在最終上線前多一層緩沖。
• 運(yùn)維去了解代碼的模塊結(jié)構(gòu)，從運(yùn)維的角度修改代碼，讓產(chǎn)品上線后更方便運(yùn)維與適應(yīng)生產(chǎn)環(huán)境的特點(diǎn)。
• 運(yùn)維參與到持續(xù)的集成測(cè)試中，用自己的自動(dòng)化知識(shí)幫助實(shí)現(xiàn)自動(dòng)的集成測(cè)試等。

來(lái)源：http://www.infoq.com/cn/articles/lxh-teamwork-devops

 【編輯推薦】

1. 為什么需要DevOps？
2. 從敏捷開(kāi)發(fā)到敏捷運(yùn)維：DevOps將帶來(lái)革命？
3. 給系統(tǒng)管理員們的節(jié)日禮物