在IT企業裡產品從創意到交付給使用者，從整體上看是由技術部門負責，但如果深入到技術部門，會發現由不同的技術團隊負責不同的部分或者階段。一般會分產品團隊、開發團隊、測試團隊以及運維團隊，在網際網路公司裡，運維團隊一般還分基礎運維和產品運維兩個團隊，基礎運維負責基礎設施(包括機架、網路、硬體)和作業系統的安裝，為整體公司的所有產品提供基礎設施的運維服務。而產品運維負責線上產品的問題處理、程式碼的佈署和跟開發的介面等。
不同的技術團隊一般隸屬不同的部門，分散在公司不同的辦公區域，團隊內部的溝通相對多一些，但團隊之間的溝通較少。不同團隊都會形成自己的辦事習慣、節奏，都有自己的關注點，一般只是知道與之介面的團隊的總體職責，但是不知道對方可能面臨的困難與工作中的挑戰點。另外，如果公司夠大，每個團隊內部又會分為許更細的小團隊，如基礎運維一般有系統團隊、網路團隊和IDC團隊等，這樣更加重了團隊之間溝通難度。
從產品策劃到上線，一般是以下邊的順序經過各個團隊：
1.開發團隊收集產品的需求，定下時間表並進行開發
2. 開發完後，交由測試或質量團隊進行測試
3. 然後交給運維團隊佈署新產品或新版本
4. 運維團隊將運維過程中發現的程式碼缺陷反饋給開發團隊進行修復
在上面的每個階段，對應的團隊都是各做各的，一般是在最後才會把球踢給下一個團隊，如果下一個團隊發現問題又會把球踢回原來的團隊。如果你深入到不同的團隊中去，或聽到不同的抱怨聲音
基礎運維團隊經常抱怨：
- 產品開發一點計劃都沒有，突然要上線機器，讓我們措手不及。
- 每個產品都急著上線，誰催得急就上誰的，誰能說一下，到底那個重要？
- 動不動就要重灌系統，壞了一塊盤就著急去修，剛從機房回來，又要過去。
- 上線太突然了，沒有交換機，沒有機架，還需要搬別的機器騰地方。
- 那個地方有機架和交換機埠，但沒有四層裝置，他們又要放在四層後邊，真的沒有辦法了。
- 剛跟他們上線到一個機房，他們又說要換到另一個機房，盡折騰。
- 他們怎麼能那麼用裝置，把上連埠頻寬都跑滿了。
產品運維團隊會說：
- 真沒辦法，上個線不是說沒機架，就是沒有交換機，還有就是說沒有四層裝置。
- 從來不告訴我們什麼時候能裝置能上線交付給我們，不派專人催著這事，一點譜都沒有。
- 本來沒有想好怎麼用這些裝置，先提前一個月申請上線，得我們想清楚了，他們卻說又得換機房。
- 網路怎麼老是出問題，他們怎麼規劃的。
- 開發的程式碼太不靠譜，一上線就引發使用者投訴，只能回滾到老版本。
- 開發人員的技術能力不行，寫不出能用的版本。
- 開發要求有一個跟生產環境一樣的測試環境，這不可能有的。
而開發團隊卻說：
- 他們又不讓我們碰線上的系統，生產環境是什麼樣，我們都不知道，沒法開發程式碼。
- 我們辛苦開發幾個月，上線出問題又直接回滾了，心情很不好受。
- 程式碼在測試環境或我的機器跑的好好的呀，怎麼一上線就出問題呢。
- 測試怎麼測的，那麼多問題發現不了。
- 我們希望產品運維同事幫忙搭一個跟線上一模一樣的測試環境。
另外，測試團隊的人也許會說：
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在工具方面其實討論得更多，這裡面跟敏捷有些類似之處。快速的系統部署和自動化產品程式碼釋出方面的工具顯得尤為重要了。
為了避免校彎過正，走向另一個極端，也需要避免下面的對DevOps的常見誤解：
1.DevOps意味著要給開發者root許可權 可以給開發者加sudo許可權，執行指定的命令，比如重啟web服務。讓開發者更多地瞭解生產環境和產品的執行狀況，但並不意味著讓開發者象管理員一樣的去管理機器。
2.所有系統管理員需要寫程式碼，所有開發者需要上架機器 在系統管理和開發者各個領域仍然需要各自的專家，如儲存、網路、安裝、javascript等專門的人才，DevOps並不意味著讓大家不做自己專長的事情。
3.你一定要用某個工具，不然就不是DevOps 一些技術和自動化的工具對推動各個團隊之間協作很有幫助，但是還是需要聚焦於要解決的問題，根椐問題和組織的特點選擇合適的工具。
4.我們需要招聘DevOps DevOps不是一個新的崗位
五、結合DevOps，解決團隊配合問題
管理人員關注團隊之間的溝通機制及氛圍：
- 以新版能在生產環境中可靠穩定執行為目標，形成協作的氛圍。
- 在專案的早期，立項之間，運維、開發與測試就進行溝通，可能的話坐在一起，面對面溝通。
- 在專案上線前，除了測試功能，還要關注部署、備份、監控、安全以及配置管理，在早期發現的問題越多，越能盡少後期的問題並避免影響使用者體驗。
- 建立各個團隊的核心成員定期溝通機制。
- 團隊之間的協作納入績效考核過程中去。
讓開發人員瞭解運維工作、關注點及挑戰，並從開發視角幫助運維：
- 開發人員參與運維團隊的內部培訓，瞭解線上的系統。
- 瞭解運維如何定位並解決故障、如何監控系統的運轉情況等。
- 少數開發人員可以跟運維一樣發版本到生產環境中，讓開發人員關注並瞭解自己程式碼的執行情況。
- 從運維的視角修改程式碼，方便運維人員進行日常的變更與調整，監控與報警。
- 幫助運維人員修改puppet配置模板。
- 幫助運維人員編寫與修改產品的釋出指令碼，提高自動化水平。
讓運維人員瞭解開發過程的關注點及挑戰，並從運維角度改善開發過程：
- 運維為開發在公司搭建基於虛擬機器的測試環境，虛擬機器的安裝、配置管理以及程式碼的釋出採用跟生產環境一樣的方式。
- 開發人員與測試人員象運維一樣釋出版本到測試環境中。
- 鼓勵開發與測試人員修改puppet配置與模板，管理自己的虛擬機器。
- 在生產環境中建立了beta環境，開發人員可以直接發版本上去，讓程式碼在最終上線前多一層緩衝。
- 運維去了解程式碼的模組結構，從運維的角度修改程式碼，讓產品上線後更方便運維與適應生產環境的特點。
- 運維參與到持續的整合測試中，用自己的自動化知識幫助實現自動的整合測試等。
原文： 李小紅