一、技術團隊細分及配合問題

在IT企業里產品從創意到交付給用戶，從整體上看是由技術部門負責，但如果深入到技術部門，會發現由不同的技術團隊負責不同的部分或者階段。一般會分產品團隊、開發團隊、測試團隊以及運維團隊，在互聯網公司里，運維團隊一般還分基礎運維和產品運維兩個團隊，基礎運維負責基礎設施(包括機架、網絡、硬件)和操作系統的安裝，為整體公司的所有產品提供基礎設施的運維服務。而產品運維負責線上產品的問題處理、代碼的布署和跟開發的接口等。

不同的技術團隊一般隸屬不同的部門，分散在公司不同的辦公區域，團隊內部的溝通相對多一些，但團隊之間的溝通較少。不同團隊都會形成自己的辦事習慣、節奏，都有自己的關注點，一般只是知道與之接口的團隊的總體職責，但是不知道對方可能面臨的困難與工作中的挑戰點。另外，如果公司夠大，每個團隊內部又會分為許更細的小團隊，如基礎運維一般有系統團隊、網絡團隊和IDC團隊等，這樣更加重了團隊之間溝通難度。

從產品策劃到上線，一般是以下邊的順序經過各個團隊：

1. 開發團隊收集產品的需求，定下時間表并進行開發
2. 開發完后，交由測試或質量團隊進行測試
3. 然后交給運維團隊布署新產品或新版本
4. 運維團隊將運維過程中發現的代碼缺陷反饋給開發團隊進行修復

在上面的每個階段，對應的團隊都是各做各的，一般是在***才會把球踢給下一個團隊，如果下一個團隊發現問題又會把球踢回原來的團隊。如果你深入到不同的團隊中去，或聽到不同的抱怨聲音。

基礎運維團隊經常抱怨：

• 產品開發一點計劃都沒有，突然要上線機器，讓我們措手不及。
• 每個產品都急著上線，誰催得急就上誰的，誰能說一下，到底那個重要？
• 動不動就要重裝系統，壞了一塊盤就著急去修，剛從機房回來，又要過去。
• 上線太突然了，沒有交換機，沒有機架，還需要搬別的機器騰地方。
• 那個地方有機架和交換機端口，但沒有四層設備，他們又要放在四層后邊，真的沒有辦法了。
• 剛跟他們上線到一個機房，他們又說要換到另一個機房，盡折騰。
• 他們怎么能那么用設備，把上連端口帶寬都跑滿了。

產品運維團隊會說：

• 真沒辦法，上個線不是說沒機架，就是沒有交換機，還有就是說沒有四層設備。
• 從來不告訴我們什么時候能設備能上線交付給我們，不派專人催著這事，一點譜都沒有。
• 本來沒有想好怎么用這些設備，先提前一個月申請上線，得我們想清楚了，他們卻說又得換機房。
• 網絡怎么老是出問題，他們怎么規劃的。
• 開發的代碼太不靠譜，一上線就引發用戶投訴，只能回滾到老版本。
• 開發人員的技術能力不行，寫不出能用的版本。
• 開發要求有一個跟生產環境一樣的測試環境，這不可能有的。

而開發團隊卻說：

• 他們又不讓我們碰線上的系統，生產環境是什么樣，我們都不知道，沒法開發代碼。
• 我們辛苦開發幾個月，上線出問題又直接回滾了，心情很不好受。
• 代碼在測試環境或我的機器跑的好好的呀，怎么一上線就出問題呢。
• 測試怎么測的，那么多問題發現不了。
• 我們希望產品運維同事幫忙搭一個跟線上一模一樣的測試環境。

另外，測試團隊的人也許會說：

• 開發人員不寫規定寫單元測試代碼。
• 想著能用一個自動的集成測試環境，因為開發的原因，老是實現不了。
• 測試環境跟生產環境不一樣，好多問題才發現
• 還有那么多的bug沒有解決，產品就催著上線。

二、技術團隊之間配合不好的影響

上面看到的團隊之間的沖突和抱怨問題雖然都不一樣，產生的影響確是類似的：

• 產品上線的進度延誤，整個團隊很難正常交付新版本。
• 產品上線后問題很多，影響用戶的訪問。
• 團隊的士氣很差。

最近又發生了運維團隊與開發團隊之間的配合不好的問題，影響及原因如下：

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

雖然，有些問題確實需要靠某些團隊提高自身的人員技能才能解決好，但這些團隊能夠形成一股合力的話，同樣的人員組合肯定會產生更好的效果。

三、過去解決團隊配合問題的方法

***次碰到團隊之間的配合問題時，我們還沒來得及解決的時候，公司戰略調整，整個開發和系統運營團隊轉給了另一個大部門。但我們在別的地方重新梳理技術團隊時，后來又沒有出現這種問題，回想起來，我們的做法是：

• 部分開發人員有生產環境中服務器的帳號，可以觀察代碼的運轉情況，少數核心開發人員還有sudo權限，當然他們也不會隨便修改服務器的設置
• 開發時一開始就會跟系統運維團隊溝通，在代碼中增加數據收集的接口和監控接口，這樣上線后，很容易收集產品的性能數據，并能方便地對運行狀態進行監控與報警
• 生產環境中也有沙箱與beta環境，這樣大的版本從測試中過渡到生產環境前，先在沙箱環境中適應一段時間，這樣能相對平穩過渡到生產環境
• 部分開發人員臨時轉到系統運維團隊工作一到二個季度，跟系統運維同事一起上線產品，解決產品在運行中發生的問題，這樣更好地了解代碼如何在生產環境中運行，回去之后能更好地運維同事溝通，開發出來的代碼更容易在生產環境中運行

這樣，不同團隊之間雖然有職責上的明確分工，但在中間的配合的部分做了不少柔性處理。另外，開發、運維與測試等團隊中的核心人員之間本身就有認同感，大家一開始的目標就是奔著公司能成功來的，這是沒有出配合問題的根本原因。這一點其實跟DevOps的核心點類似，既然如此，何不重新審視一下DevOps，并參考著解決團隊之間的配合問題呢。

四、DevOps

DevOps是2010年從歐洲傳過來的概念，***是由一群有著跨學科技能的工程師提出來的，為了解決下面的問題：

• 推出新功能和解決老問題的周期過長
• 新產品或新版本上線充滿風險，代碼能否在生產環境中穩定運行，沒有人有信心，只能艱難地推上去，再看是不是有問題
• 不同團隊相互隔離，配合差。如開發人員收到問題后，***反應是“在我的機器上工作得好好的呀”

我認為DevOps的核心是不管你是開發者、測試人員、管理者、DBA、網絡工程師還是系統管理員，大家都是一起的，只有一起努力給客戶提供穩定而高質量的軟件服務，實現公司的商業利益才會有別的，包括自己的工作機會。

所以，DevOps實際是給各個團隊之間搭橋，讓他們不僅僅是依靠上線申請單這樣的鴻雁傳書工具進行溝通，而且經常離開自己的孤島，走到別人的島上去，了解別人，并提供自己的想法，幫助對方。

DevOps更象是一種運動，每家公司都需要根椐自身的特點進行借鑒，推動團隊之間的協作與合作。需要在三個方面努力：

1. 人員

一方面對現有人員進行培訓，鼓勵他們了解別的團隊的工作、面臨的挑戰等，讓他們用自己的特長去審視和幫助別的團隊，另一方面也想辦法招一些全面的技術人才，在不同團隊之間搭出一些適用的橋來。

2. 流程

在研發的前期，讓系統運維同事參與起來，一起搭建測試環境，驗證想法，或者也可以在一些項目團隊中直接配有系統、開發和測試以及產品人員，一起為產品的上線努力。出現問題的時候，一起想方法找到問題的真正根源，避免相互推托，將解決方案落實在以后的研發過程中。從績效考核流程上也需要考慮協作因素。

3. 工具

說實在的，大家針對DevOps在工具方面其實討論得更多，這里面跟敏捷有些類似之處?？焖俚南到y部署和自動化產品代碼發布方面的工具顯得尤為重要了。

為了避免校彎過正，走向另一個極端，也需要避免下面的對DevOps的常見誤解：

1. DevOps意味著要給開發者root權限

可以給開發者加sudo權限，運行指定的命令，比如重啟web服務。讓開發者更多地了解生產環境和產品的運行狀況，但并不意味著讓開發者象管理員一樣的去管理機器。

2. 所有系統管理員需要寫代碼，所有開發者需要上架機器

在系統管理和開發者各個領域仍然需要各自的專家，如存儲、網絡、安裝、javascript等專門的人才，DevOps并不意味著讓大家不做自己專長的事情。

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

一些技術和自動化的工具對推動各個團隊之間協作很有幫助，但是還是需要聚焦于要解決的問題，根椐問題和組織的特點選擇合適的工具。

4. 我們需要招聘DevOps

DevOps不是一個新的崗位

五、結合DevOps，解決團隊配合問題

管理人員關注團隊之間的溝通機制及氛圍：

• 以新版能在生產環境中可靠穩定運行為目標，形成協作的氛圍。
• 在項目的早期，立項之間，運維、開發與測試就進行溝通，可能的話坐在一起，面對面溝通。
• 在項目上線前，除了測試功能，還要關注部署、備份、監控、安全以及配置管理，在早期發現的問題越多，越能盡少后期的問題并避免影響用戶體驗。
• 建立各個團隊的核心成員定期溝通機制。
• 團隊之間的協作納入績效考核過程中去。

讓開發人員了解運維工作、關注點及挑戰，并從開發視角幫助運維：

• 開發人員參與運維團隊的內部培訓，了解線上的系統。
• 了解運維如何定位并解決故障、如何監控系統的運轉情況等。
• 少數開發人員可以跟運維一樣發版本到生產環境中，讓開發人員關注并了解自己代碼的運行情況。
• 從運維的視角修改代碼，方便運維人員進行日常的變更與調整，監控與報警。
• 幫助運維人員修改puppet配置模板。
• 幫助運維人員編寫與修改產品的發布腳本，提高自動化水平。

讓運維人員了解開發過程的關注點及挑戰，并從運維角度改善開發過程：

• 運維為開發在公司搭建基于虛擬機的測試環境，虛擬機的安裝、配置管理以及代碼的發布采用跟生產環境一樣的方式。
• 開發人員與測試人員象運維一樣發布版本到測試環境中。
• 鼓勵開發與測試人員修改puppet配置與模板，管理自己的虛擬機。
• 在生產環境中建立了beta環境，開發人員可以直接發版本上去，讓代碼在最終上線前多一層緩沖。
• 運維去了解代碼的模塊結構，從運維的角度修改代碼，讓產品上線后更方便運維與適應生產環境的特點。
• 運維參與到持續的集成測試中，用自己的自動化知識幫助實現自動的集成測試等。

來源：http://www.infoq.com/cn/articles/lxh-teamwork-devops

 【編輯推薦】

1. 為什么需要DevOps？
2. 從敏捷開發到敏捷運維：DevOps將帶來革命？
3. 給系統管理員們的節日禮物