一、技術(shù)團隊細分及配合問題
在IT企業(yè)里產(chǎn)品從創(chuàng)意到交付給用戶，從整體上看是由技術(shù)部門負責，但如果深入到技術(shù)部門，會發(fā)現(xiàn)由不同的技術(shù)團隊負責不同的部分或者階段。一般會分產(chǎn)品團隊、開發(fā)團隊、測試團隊以及運維團隊，在互聯(lián)網(wǎng)公司里，運維團隊一般還分基礎運維和產(chǎn)品運維兩個團隊，基礎運維負責基礎設施(包括機架、網(wǎng)絡、硬件)和操作系統(tǒng)的安裝，為整體公司的所有產(chǎn)品提供基礎設施的運維服務。而產(chǎn)品運維負責線上產(chǎn)品的問題處理、代碼的布署和跟開發(fā)的接口等。
不同的技術(shù)團隊一般隸屬不同的部門，分散在公司不同的辦公區(qū)域，團隊內(nèi)部的溝通相對多一些，但團隊之間的溝通較少。不同團隊都會形成自己的辦事習慣、節(jié)奏，都有自己的關注點，一般只是知道與之接口的團隊的總體職責，但是不知道對方可能面臨的困難與工作中的挑戰(zhàn)點。另外，如果公司夠大，每個團隊內(nèi)部又會分為許更細的小團隊，如基礎運維一般有系統(tǒng)團隊、網(wǎng)絡團隊和IDC團隊等，這樣更加重了團隊之間溝通難度。
從產(chǎn)品策劃到上線，一般是以下邊的順序經(jīng)過各個團隊：
- 開發(fā)團隊收集產(chǎn)品的需求，定下時間表并進行開發(fā)
- 開發(fā)完后，交由測試或質(zhì)量團隊進行測試
- 然后交給運維團隊布署新產(chǎn)品或新版本
- 運維團隊將運維過程中發(fā)現(xiàn)的代碼缺陷反饋給開發(fā)團隊進行修復
在上面的每個階段，對應的團隊都是各做各的，一般是在最后才會把球踢給下一個團隊，如果下一個團隊發(fā)現(xiàn)問題又會把球踢回原來的團隊。如果你深入到不同的團隊中去，或聽到不同的抱怨聲音。
基礎運維團隊經(jīng)常抱怨：
- 產(chǎn)品開發(fā)一點計劃都沒有，突然要上線機器，讓我們措手不及。
- 每個產(chǎn)品都急著上線，誰催得急就上誰的，誰能說一下，到底那個重要？
- 動不動就要重裝系統(tǒng)，壞了一塊盤就著急去修，剛從機房回來，又要過去。
- 上線太突然了，沒有交換機，沒有機架，還需要搬別的機器騰地方。
- 那個地方有機架和交換機端口，但沒有四層設備，他們又要放在四層后邊，真的沒有辦法了。
- 剛跟他們上線到一個機房，他們又說要換到另一個機房，盡折騰。
- 他們怎么能那么用設備，把上連端口帶寬都跑滿了。
產(chǎn)品運維團隊會說：
- 真沒辦法，上個線不是說沒機架，就是沒有交換機，還有就是說沒有四層設備。
- 從來不告訴我們什么時候能設備能上線交付給我們，不派專人催著這事，一點譜都沒有。
- 本來沒有想好怎么用這些設備，先提前一個月申請上線，得我們想清楚了，他們卻說又得換機房。
- 網(wǎng)絡怎么老是出問題，他們怎么規(guī)劃的。
- 開發(fā)的代碼太不靠譜，一上線就引發(fā)用戶投訴，只能回滾到老版本。
- 開發(fā)人員的技術(shù)能力不行，寫不出能用的版本。
- 開發(fā)要求有一個跟生產(chǎn)環(huán)境一樣的測試環(huán)境，這不可能有的。
而開發(fā)團隊卻說：
- 他們又不讓我們碰線上的系統(tǒng)，生產(chǎn)環(huán)境是什么樣，我們都不知道，沒法開發(fā)代碼。
- 我們辛苦開發(fā)幾個月，上線出問題又直接回滾了，心情很不好受。
- 代碼在測試環(huán)境或我的機器跑的好好的呀，怎么一上線就出問題呢。
- 測試怎么測的，那么多問題發(fā)現(xiàn)不了。
- 我們希望產(chǎn)品運維同事幫忙搭一個跟線上一模一樣的測試環(huán)境。
另外，測試團隊的人也許會說：
- 開發(fā)人員不寫規(guī)定寫單元測試代碼。
- 想著能用一個自動的集成測試環(huán)境，因為開發(fā)的原因，老是實現(xiàn)不了。
- 測試環(huán)境跟生產(chǎn)環(huán)境不一樣，好多問題才發(fā)現(xiàn)
- 還有那么多的bug沒有解決，產(chǎn)品就催著上線。
二、技術(shù)團隊之間配合不好的影響
上面看到的團隊之間的沖突和抱怨問題雖然都不一樣，產(chǎn)生的影響確是類似的：
- 產(chǎn)品上線的進度延誤，整個團隊很難正常交付新版本。
- 產(chǎn)品上線后問題很多，影響用戶的訪問。
- 團隊的士氣很差。
最近又發(fā)生了運維團隊與開發(fā)團隊之間的配合不好的問題，影響及原因如下：
- 新產(chǎn)品上線延誤了兩個星期，正常情況下一天就可以上線。原因是開發(fā)考慮不周，測試環(huán)境中沒有發(fā)現(xiàn)，到上線前才發(fā)現(xiàn)部署到多臺機器上后，按開發(fā)原先計劃的方式多臺機器無法協(xié)作完成任務。還有就是在設計階段沒有考慮生產(chǎn)環(huán)境的狀況，在上線的過程中需要做出對應的代碼調(diào)整。
- 上線后質(zhì)量不穩(wěn)定，出現(xiàn)多次緊急修復。原因同上。
- 臨時增加硬件投入。新產(chǎn)品中有個組件采用全新的技術(shù)方案，跟原來的LAMP體系不兼容，所以需要新增機器，單獨部署。
- 除低了服務可用性標準，并產(chǎn)生了遺留問題。因為臨時需要增加硬件，而恰好又只有一臺，這樣就形成了單點，如果該機器出現(xiàn)故障，服務將全部中斷。另外，由于開發(fā)前設計上考慮不周，跟別的組件集成時產(chǎn)生別的單點。所以這些降低了服務的可用性，以后還得想辦法解決。除此之外，組件采有新的軟件，安裝、服務起停以及軟件配置的管理都是純手工打造，以后還得找時間納入到自動配置管理中。
- 影響了團隊士氣。在上線過程中開發(fā)、測試和運維都覺得不舒服，相互之間產(chǎn)生了抱怨。如果不處理好，會影響以后的配合。
雖然，有些問題確實需要靠某些團隊提高自身的人員技能才能解決好，但這些團隊能夠形成一股合力的話，同樣的人員組合肯定會產(chǎn)生更好的效果。
三、過去解決團隊配合問題的方法
第一次碰到團隊之間的配合問題時，我們還沒來得及解決的時候，公司戰(zhàn)略調(diào)整，整個開發(fā)和系統(tǒng)運營團隊轉(zhuǎn)給了另一個大部門。但我們在別的地方重新梳理技術(shù)團隊時，后來又沒有出現(xiàn)這種問題，回想起來，我們的做法是：
- 部分開發(fā)人員有生產(chǎn)環(huán)境中服務器的帳號，可以觀察代碼的運轉(zhuǎn)情況，少數(shù)核心開發(fā)人員還有sudo權(quán)限，當然他們也不會隨便修改服務器的設置
- 開發(fā)時一開始就會跟系統(tǒng)運維團隊溝通，在代碼中增加數(shù)據(jù)收集的接口和監(jiān)控接口，這樣上線后，很容易收集產(chǎn)品的性能數(shù)據(jù)，并能方便地對運行狀態(tài)進行監(jiān)控與報警
- 生產(chǎn)環(huán)境中也有沙箱與beta環(huán)境，這樣大的版本從測試中過渡到生產(chǎn)環(huán)境前，先在沙箱環(huán)境中適應一段時間，這樣能相對平穩(wěn)過渡到生產(chǎn)環(huán)境
- 部分開發(fā)人員臨時轉(zhuǎn)到系統(tǒng)運維團隊工作一到二個季度，跟系統(tǒng)運維同事一起上線產(chǎn)品，解決產(chǎn)品在運行中發(fā)生的問題，這樣更好地了解代碼如何在生產(chǎn)環(huán)境中運行，回去之后能更好地運維同事溝通，開發(fā)出來的代碼更容易在生產(chǎn)環(huán)境中運行
這樣，不同團隊之間雖然有職責上的明確分工，但在中間的配合的部分做了不少柔性處理。另外，開發(fā)、運維與測試等團隊中的核心人員之間本身就有認同感，大家一開始的目標就是奔著公司能成功來的，這是沒有出配合問題的根本原因。這一點其實跟DevOps的核心點類似，既然如此，何不重新審視一下DevOps，并參考著解決團隊之間的配合問題呢。
四、DevOps
DevOps是2010年從歐洲傳過來的概念，最先是由一群有著跨學科技能的工程師提出來的，為了解決下面的問題：
- 推出新功能和解決老問題的周期過長
- 新產(chǎn)品或新版本上線充滿風險，代碼能否在生產(chǎn)環(huán)境中穩(wěn)定運行，沒有人有信心，只能艱難地推上去，再看是不是有問題
- 不同團隊相互隔離，配合差。如開發(fā)人員收到問題后，第一反應是“在我的機器上工作得好好的呀”
我認為DevOps的核心是不管你是開發(fā)者、測試人員、管理者、DBA、網(wǎng)絡工程師還是系統(tǒng)管理員，大家都是一起的，只有一起努力給客戶提供穩(wěn)定而高質(zhì)量的軟件服務，實現(xiàn)公司的商業(yè)利益才會有別的，包括自己的工作機會。
所以，DevOps實際是給各個團隊之間搭橋，讓他們不僅僅是依靠上線申請單這樣的鴻雁傳書工具進行溝通，而且經(jīng)常離開自己的孤島，走到別人的島上去，了解別人，并提供自己的想法，幫助對方。
DevOps更象是一種運動，每家公司都需要根椐自身的特點進行借鑒，推動團隊之間的協(xié)作與合作。需要在三個方面努力：
- 人員
一方面對現(xiàn)有人員進行培訓，鼓勵他們了解別的團隊的工作、面臨的挑戰(zhàn)等，讓他們用自己的特長去審視和幫助別的團隊，另一方面也想辦法招一些全面的技術(shù)人才，在不同團隊之間搭出一些適用的橋來。
- 流程
在研發(fā)的前期，讓系統(tǒng)運維同事參與起來，一起搭建測試環(huán)境，驗證想法，或者也可以在一些項目團隊中直接配有系統(tǒng)、開發(fā)和測試以及產(chǎn)品人員，一起為產(chǎn)品的上線努力。出現(xiàn)問題的時候，一起想方法找到問題的真正根源，避免相互推托，將解決方案落實在以后的研發(fā)過程中。從績效考核流程上也需要考慮協(xié)作因素。
- 工具
說實在的，大家針對DevOps在工具方面其實討論得更多，這里面跟敏捷有些類似之處。快速的系統(tǒng)部署和自動化產(chǎn)品代碼發(fā)布方面的工具顯得尤為重要了。
為了避免校彎過正，走向另一個極端，也需要避免下面的對DevOps的常見誤解：
- DevOps意味著要給開發(fā)者root權(quán)限
可以給開發(fā)者加sudo權(quán)限，運行指定的命令，比如重啟web服務。讓開發(fā)者更多地了解生產(chǎn)環(huán)境和產(chǎn)品的運行狀況，但并不意味著讓開發(fā)者象管理員一樣的去管理機器。
- 所有系統(tǒng)管理員需要寫代碼，所有開發(fā)者需要上架機器
在系統(tǒng)管理和開發(fā)者各個領域仍然需要各自的專家，如存儲、網(wǎng)絡、安裝、javascript等專門的人才，DevOps并不意味著讓大家不做自己專長的事情。
- 你一定要用某個工具，不然就不是DevOps
一些技術(shù)和自動化的工具對推動各個團隊之間協(xié)作很有幫助，但是還是需要聚焦于要解決的問題，根椐問題和組織的特點選擇合適的工具。
- 我們需要招聘DevOps
DevOps不是一個新的崗位
五、結(jié)合DevOps，解決團隊配合問題
管理人員關注團隊之間的溝通機制及氛圍：
- 以新版能在生產(chǎn)環(huán)境中可靠穩(wěn)定運行為目標，形成協(xié)作的氛圍。
- 在項目的早期，立項之間，運維、開發(fā)與測試就進行溝通，可能的話坐在一起，面對面溝通。
- 在項目上線前，除了測試功能，還要關注部署、備份、監(jiān)控、安全以及配置管理，在早期發(fā)現(xiàn)的問題越多，越能盡少后期的問題并避免影響用戶體驗。
- 建立各個團隊的核心成員定期溝通機制。
- 團隊之間的協(xié)作納入績效考核過程中去。
讓開發(fā)人員了解運維工作、關注點及挑戰(zhàn)，并從開發(fā)視角幫助運維：
- 開發(fā)人員參與運維團隊的內(nèi)部培訓，了解線上的系統(tǒng)。
- 了解運維如何定位并解決故障、如何監(jiān)控系統(tǒng)的運轉(zhuǎn)情況等。
- 少數(shù)開發(fā)人員可以跟運維一樣發(fā)版本到生產(chǎn)環(huán)境中，讓開發(fā)人員關注并了解自己代碼的運行情況。
- 從運維的視角修改代碼，方便運維人員進行日常的變更與調(diào)整，監(jiān)控與報警。
- 幫助運維人員修改puppet配置模板。
- 幫助運維人員編寫與修改產(chǎn)品的發(fā)布腳本，提高自動化水平。
讓運維人員了解開發(fā)過程的關注點及挑戰(zhàn)，并從運維角度改善開發(fā)過程：
- 運維為開發(fā)在公司搭建基于虛擬機的測試環(huán)境，虛擬機的安裝、配置管理以及代碼的發(fā)布采用跟生產(chǎn)環(huán)境一樣的方式。
- 開發(fā)人員與測試人員象運維一樣發(fā)布版本到測試環(huán)境中。
- 鼓勵開發(fā)與測試人員修改puppet配置與模板，管理自己的虛擬機。
- 在生產(chǎn)環(huán)境中建立了beta環(huán)境，開發(fā)人員可以直接發(fā)版本上去，讓代碼在最終上線前多一層緩沖。
- 運維去了解代碼的模塊結(jié)構(gòu)，從運維的角度修改代碼，讓產(chǎn)品上線后更方便運維與適應生產(chǎn)環(huán)境的特點。
- 運維參與到持續(xù)的集成測試中，用自己的自動化知識幫助實現(xiàn)自動的集成測試等。
文章了來自：http://www.infoq.com/cn/articles/lxh-teamwork-devops