在CTO俱樂部第96期《 產(chǎn)品創(chuàng)新之路及DevOps實踐分享》活動上，CC視頻CTO 侯明強講述了DevOps概念在CC視頻的實踐，DevOps是Development和Operation兩個英文單詞前面幾個字母的組合，主要是指研發(fā)人員和運維人員在實踐中的之間的溝通、協(xié)作與整合。

在DevOps給CC視頻技術團隊帶來了高效率之余，侯明強還談到了實踐中面臨的挑戰(zhàn)。他指出，對研發(fā)人員而言，DevOps給研發(fā)人員帶來了新的要求和新的挑戰(zhàn)。長期做研發(fā)的人對代碼之外的東西并不是很熟悉，對工具、環(huán)境，尤其是在線運維的東西涉獵不多。對運維來說，運維人員轉(zhuǎn)成半開發(fā)人員的角色，困難重重，相關人員也很難招聘。

以下為侯明強本次分享內(nèi)容精華摘選：

DevOps的由來

傳統(tǒng)的開發(fā)和運維的配合

研發(fā)團隊負責：離線開發(fā)，開發(fā)，測試；運維團隊負責：線上，打包，部署，更新；

研發(fā)與運維的矛盾

研發(fā)認為，我本地運沒問題，線上出問題是你們運維的事情；不更新業(yè)務怎么辦？

運維認為，我們運維沒問題，是你們程序爛才出了線上問題；你一更新出問題我的KPI就下降。

研發(fā)與運維的不同

研發(fā)團隊與運維團隊的關注點不同；

研發(fā)更關注產(chǎn)品的優(yōu)化和更新，也就是更關注變化；

運維更關注系統(tǒng)的安全和穩(wěn)定，也就是更關注不變；

這就導致了研發(fā)和運維之間的關注點是完全不同的，甚至對立的。

由于研發(fā)和運維矛盾的不斷凸出，甚至在有些場合下，出現(xiàn)對立。這就引出了DevOps的概念。這個概念很好理解，研發(fā)（Development）和運維（Operation）英文單詞前面幾個字母合起來就是DevOps。

維基百科這么描述DevOps：

它是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)（應用程序/軟件工程）、運維部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件業(yè)日益清晰地認識到：為了按時交付軟件產(chǎn)品和服務，開發(fā)和運維工作必須緊密合作。

DevOps能解決什么問題

更密切配合業(yè)務。讓你更加以業(yè)務為中心，你們團隊必須是配合的，你們要想出更好的方式來配合；

解決對變更部署的恐懼。通過一些好的方式方法或者工具，能夠讓變更部署不再成為大家共同的惡夢；

解決開發(fā)和運維部門配合，減少雙方之間的扯皮問題。

為何選擇DevOps

業(yè)務

互聯(lián)網(wǎng)創(chuàng)業(yè)早期，一切圍繞業(yè)務快速變化。當時為了實現(xiàn)業(yè)務目標，在團隊人員比較少、資源有限的情況下，我們就想辦法盡量把運維工作省下來，讓研發(fā)人員直接負責業(yè)務目標的達成，從開發(fā)到最終上線，保證它在線上正常工作的事情，都由開發(fā)去做。

服務質(zhì)量

如果不是開發(fā)直接來確定質(zhì)量能夠達到理想的標準的話，拆分成兩個部門分別做，運維不懂業(yè)務，你讓他進行深入的調(diào)整是很困難的。尤其是在創(chuàng)新的一些業(yè)務，或者是一些技術方案上，它會需要很多的嘗試，甚至包括配制的嘗試，服務器或者應用服務器，或者數(shù)據(jù)庫架構的構造，自然要出狀況。

成本

以業(yè)務目標為主，為了服務質(zhì)量，在成本相對較低的情況下，我們從創(chuàng)業(yè)公司的初期就選擇了這種方式，我們是以開發(fā)盡量多做東西、運維主要負責系統(tǒng)，開發(fā)負責線上的質(zhì)量。

圍繞DevOps的一些初級措施

測試環(huán)境鏡像線上環(huán)境。為了縮短本地開發(fā)和實際線上運行的差異，我們的開發(fā)人員用的系統(tǒng)和線上的系統(tǒng)一樣，測試環(huán)境也是一個完全一樣的，就是盡量把一些鴻溝縮短掉。

從SVN自動化部署。我們也開發(fā)一些腳本，讓它從SVN里自動化去部署，把相應的內(nèi)容拿出來，然后更新到線上去。

應用級監(jiān)控系統(tǒng)。我們做的一些應用級的監(jiān)控系統(tǒng)，如果從傳統(tǒng)的運維監(jiān)控來看，大家會用工具去監(jiān)控系統(tǒng)本身的負載，監(jiān)測各種各樣的指標，但是他們沒有辦法知道，這個應用本身是不是出了問題。

此外，我們會做大量視頻的處理，在全國視頻網(wǎng)絡里進行視頻的分發(fā)，這些工作都是比較耗時、耗CPU。一天上傳上萬個文件，會有非常多的工作項目在進行中。因此這些任務，比如視頻處理一半，服務器宕機了，還能不能繼續(xù)。那些東西只是一個外部系統(tǒng)訪問的話你看不出來的，或者你只監(jiān)控一下，網(wǎng)絡也沒問題，硬盤什么都沒問題，有可能你應用隊列已經(jīng)出現(xiàn)了故障。

研發(fā)負責從代碼到線上，負責快速更新。我們研發(fā)人員去負責從代碼到線上，有快速更新、快速上線的東西，都由研發(fā)直接來做，有點像醫(yī)生在沒有護士的情況下親自操刀把所有的東西都做了。這樣的好處就是出現(xiàn)了各種各樣的問題，能夠更加快速的反應，更加快速的定位。

眾所周之，CC視頻是做SaaS服務，客戶都是to B，客戶一出問題，立刻打電話過來，處理時間的長短嚴重影響服務質(zhì)量，因此我們縮短從生產(chǎn)環(huán)境到真正線上運行的環(huán)境的環(huán)境，讓研發(fā)直接到底下去負責。

傳統(tǒng)處理線上問題流程：運維和研發(fā)相互隔離

運維收到系統(tǒng)報警，常規(guī)檢查，嘗試解決，如處理不成功，緊急上線更新包；

再將問題提交給研發(fā)，研發(fā)再讓運維提供相關資料，比如日志；

運維在服務器上收集資料并提供給研發(fā)，研發(fā)查找問題，給出解決方案。

在這種流程下，運維和研發(fā)都很著急，卻使不上勁。

CC視頻的經(jīng)驗：研發(fā)與運維聯(lián)動 快速解決問題

研發(fā)收到系統(tǒng)報警，定位問題、解決問題。

運維和研發(fā)相互給予系統(tǒng)環(huán)境級技術支持，雙方在解決完成后溝通解決方案，以及問題原因。

我們有一個視頻的緩存模塊進行一個算法更新，緩存的命中率是很重要的因素，之前命中率不是特別高，我們自己開發(fā)了一個新的緩存模塊進行算法更新。

我們線上有幾百臺服務器，我們要看算法是不是比之前要好，所以必須要做AB測試，要進行對比。同時把算法測驗在生產(chǎn)環(huán)境下運行沒有問題的時候，它還需要部署，慢慢的把所有的服務器都升級成最新的應用。

我們的工作就是由研發(fā)來操刀進行。這個如果讓運維主動去做的話，這個其實挺困難的，中間要關注非常多的數(shù)據(jù)，同時部署過程中發(fā)現(xiàn)各種各樣問題，從各種地方收集，會關注特別多的點，如果讓運維去操作這是很困難的。所以我們這個過程就是研發(fā)來主導，運維來協(xié)助配合的。

從10%發(fā)現(xiàn)沒有問題的時候，上升到50%運轉(zhuǎn)非常良好的時候，后面自動的腳本就拿出來，讓運維批量的去實施。

線上故障或異常

CC視頻有異常統(tǒng)計系統(tǒng)，我們會把每天系統(tǒng)里出現(xiàn)的異常信息統(tǒng)計出來，看看是什么樣的問題，如果統(tǒng)計出信息比較多的話會報警。

有一次我們發(fā)現(xiàn)一個異常。我們知道自己的接口可能是沒有問題的，結果檢查了，就發(fā)現(xiàn)原來有一個客戶他請求的時候參數(shù)給錯了，這種情況下我們就通知客戶進行修改，那個客戶后來發(fā)現(xiàn)他調(diào)用我們API的時候調(diào)走了，修過了就好了。

假如運維如果他不負責系統(tǒng)的日志處理，他只干服務器或者網(wǎng)絡的信息，他是查不到的。

從外表上看也看不到，因為我們整個系統(tǒng)都是正常的，只有到我們客戶的具體調(diào)用方的視角才能看到有一些什么樣的異常存在。如果他的程序?qū)懙貌粔蚝?，外表也看不出來?/p>

總結

用最短路徑對線上問題進行快速響應。我們的核心思路就是想盡量用最短的路徑，對在線的業(yè)務出現(xiàn)的技術問題進行更快速的響應。

從業(yè)務本身出發(fā)進行的技術優(yōu)化。進行技術優(yōu)化的目標，還是圍繞著業(yè)務去做。

提前開發(fā)工具，減少臨時處理。碰上臨時處理的事情救火的話是很痛苦的，如果開發(fā)團隊和運維團隊老是處在救火的狀態(tài)的話，持續(xù)不了多久，肯定有人就要考慮離職。

未來

更敏捷的持續(xù)交付。未來我們想在這些方面做更多的嘗試。

更好的自動化、工具化。利用現(xiàn)有的開源工具，在它的基礎上開發(fā)一些適合我們現(xiàn)有應用模式的更好的、更個性化的工具。

考慮結合開發(fā)與測試的環(huán)節(jié)。測試在這里面也是非常重要的一環(huán)，未來怎么把開發(fā)和測試結合起來，跟運維環(huán)節(jié)能夠更好的去融合，這塊也是我們未來想去探索的事。

DevOps實踐中的挑戰(zhàn)

既然DevOps這種理念是一個很好的東西，為什么實施的人那么少呢？其實在美國這個東西也還不是主流，也還沒有那么大影響力。

下面就是我們在實踐中的一些挑戰(zhàn)：

對研發(fā)人員的挑戰(zhàn)——對代碼之外的東西不熟悉

比如說用DevOps，這對研發(fā)人員加了很多新的要求的和新的挑戰(zhàn)。長期做研發(fā)的人員對代碼之外的東西并不是很熟悉，對工具、環(huán)境，尤其是在線運維的東西涉獵不多。

對運維人員的挑戰(zhàn)——運維開發(fā)人員不易招聘

對運維的挑戰(zhàn)，既然很多運維的職責轉(zhuǎn)給開發(fā)，那運維應該做些什么呢，他們應該朝著工具化、自動化這些方向去轉(zhuǎn)型。運維人員轉(zhuǎn)成半開發(fā)的角色，其實有很大困難，CC視頻幾乎很難招聘到這樣的人才。在很多大公司里他們也會有很擅長測試開發(fā)的人，但是那些人身價也都很高。

招聘不容易，內(nèi)部培訓也很困難，如果只是會搬服務器、插插網(wǎng)線那樣的運維，你讓他轉(zhuǎn)開發(fā)，等于從頭開始，同樣非常困難。