“唔哩”，來自于網(wǎng)絡(luò)流行語“wuli”，出處在韓語，“我們”的意思。這個畫風相當二次元的詞是90后星人的基本語匯。唔哩是一款為90后年輕一代打造的新聞資訊App，團隊一直致力于以優(yōu)質(zhì)內(nèi)容為基礎(chǔ)，以互動分享與個性化設(shè)置為特色，加入場景閱讀新元素，滿足用戶任何時間和狀態(tài)下輕松愉快的閱讀需求，做最懂90后年輕一代的貼身伴侶。

作為一款時尚、流行的APP，產(chǎn)品上線之后一直了保持較快的增長速度，經(jīng)統(tǒng)計自2016年3月份上線以來，4個月后注冊用戶已達400萬、日均活躍用戶數(shù)為25萬人次。持續(xù)快速穩(wěn)定的增長不僅與產(chǎn)品本身的話題性、強大功能密不可分，也得益于唔哩技術(shù)團隊對用戶體驗的足夠重視，同時也離不開敏捷開發(fā)/敏捷運維為產(chǎn)品提供的有力技術(shù)支撐。

一、重視持續(xù)集成，提升代碼質(zhì)量

對于創(chuàng)業(yè)公司來說，缺乏完善的流程規(guī)范和技術(shù)平臺，許多開源的技術(shù)方案并不能很好的解決面臨的困難，導致產(chǎn)品上線之初各種坑都踩了一遍。比如版本升級后，依賴模塊調(diào)用版本不對，已知bug再次復現(xiàn),數(shù)據(jù)錯誤等等；為此，唔哩設(shè)置了4種環(huán)境(dev+test+stage+prod)。

1、dev環(huán)境用于各模塊的功能開發(fā)，mock接口

2、test環(huán)境用于集成測試，集成測試通過之后，可以提交新版本到stage環(huán)境運行

3、stage環(huán)境是非常接近生產(chǎn)環(huán)境的，使用的數(shù)據(jù)是從生產(chǎn)環(huán)境同步過來的，在stage環(huán)境運行無異常后，最終提交新版本到prod環(huán)境

四個環(huán)境的操作系統(tǒng)版本和配置參數(shù)及環(huán)境變量及服務(wù)器架構(gòu)都是一致的，盡量規(guī)避因環(huán)境不一致產(chǎn)生新的bug到生產(chǎn)環(huán)境。

有了環(huán)境，接下來就可以做持續(xù)集成了。唔哩采用的比較流行方案：gitlab+jenkins，gitlab做版本控制，jenkins做代碼自動構(gòu)建、測試和打包以及把代碼自動布署到開發(fā)環(huán)境。

a)分支模型：gitlab主要分支有兩個:master和develop。

master分支保持用于線上環(huán)境的代碼。

develop分支保持下一個release版本最新的代碼，當develop分支的代碼達到release穩(wěn)定要求時，將develop分支的所有變化合并到master分支并對master打上一個tag(release版本號)。

feature分支用于開發(fā)新功能，從develop分支分出來，新功能開發(fā)完成之后合并到devleop分支。合并之后就可以刪除此分支了。

release分支主要用于大版本之后發(fā)布一些小的改動(如果有大的功能調(diào)整需要從develop分支一個feature分支開發(fā))，從develop分支分出來，然后再合并到master分支。合并之后就可以刪除此分支了。

bugfix分支用于bug修復，從主分支創(chuàng)建，然后合并到master分支和develop分支。合并之后就可以刪除此分支了。

gitlab基本不用太多的配置，需要在gitlab上創(chuàng)建一個用戶能pull需要做持續(xù)集成的項目，然后在項目的setting里設(shè)置webhooks，URL為jenkins生成的GitLabCIServiceURL，trigger可以選Pushevents/Tagpushevents/MergeRequestevents，這樣當向項目push代碼或merge請求的時候就會觸發(fā)jenkins的構(gòu)建job，也可以在jenkins里配置輪詢的方式，每過多長時間檢查一下，如果條件符合觸發(fā)構(gòu)建任務(wù)。

b)jenkins需要安裝一些插件：如Junit、Cobertura、GitlabMergeRequestBuilder等。

GitlabMergeRequestsBuilder允許在gitlab上提交mergerequest時候觸發(fā)jenkins上配置的相關(guān)的構(gòu)建任務(wù)，即在slave上將某個分支合并到另一個分支上，合并之后如果構(gòu)建成功，就將打包好的文件scp到集成環(huán)境的主機上進行布署，最后生成測試報告，并發(fā)送郵件到相關(guān)的郵件接收人。如果一切正常則可以進行codereview，這樣可以提高codereview的效率，然后在gitlab上真正合并分支。下面是jenkins構(gòu)建項目的主要項配置及截圖：

參數(shù)化構(gòu)建過程：添加4個String Parameter,名字分別為gitlab Source Repository、gitlab Source Name、gitlab Source Branch、gitlab Target Branch；

源碼管理：勾選Git

唔哩攜手聽云APM：敏捷運維提升產(chǎn)品質(zhì)量

構(gòu)建觸發(fā)器：勾選GitlabMergeRequestsBuilder,GitlabProject Path填上你的項目路徑(比如：groupName/projectName),Crontabline配置H/5****即可;

Build：RootPom參數(shù)為pom.xml,Goalsandoptions參數(shù)為:

cleancobertura:coberturapackage；

PostSteps：如下圖

唔哩攜手聽云APM：敏捷運維提升產(chǎn)品質(zhì)量

二、持續(xù)布署，每次變更都會加入跟蹤統(tǒng)計

對于生產(chǎn)環(huán)境，唔哩比較謹慎，目前采用的是人工干預的方式來發(fā)布到生產(chǎn)環(huán)境。利用jenkins自動構(gòu)建測試之后，將打包好的文件存放到版本倉庫中，然后利用saltstack布署到生產(chǎn)服務(wù)器上。在這個過程中，唔哩用python寫了一個web平臺來管理發(fā)布流程。

首先定義一個流程，由開發(fā)人員提交版本需求，并描述具體變更說明；然后由運維人員操作布署，只需在web界面點擊一下按鈕，后臺自動上線并實時展現(xiàn)日志；接下來由測試人員進行測試，并產(chǎn)生測試報告；最后流程由PM結(jié)束，PM決定一次版本上線是否結(jié)束，還是需要回退到歷史的版本；版本回退的流程也是一樣的過程，流程的每個節(jié)點都有相應(yīng)的郵件描述說明，方便下一步的人員查看。具體流程及流程的每個節(jié)點執(zhí)行哪些job都是可配置的，功能擴展很方便。 

唔哩攜手聽云APM：敏捷運維提升產(chǎn)品質(zhì)量

在做這個發(fā)版的平臺主要是基于兩個方面考慮:

1、一個是有一些web應(yīng)用前面都是Nginx做代理，布署后端服務(wù)時需要先在Nginx上剔除，布置完后端服務(wù)再添加回來，這個需要一個單獨的工具或平臺集中管理不然不好控制;

2、另一個考慮是把每次版本發(fā)布都歸檔,包括布署過程中產(chǎn)生的日志信息，方便審計，而且根據(jù)對歷史發(fā)版發(fā)布的統(tǒng)計也可以發(fā)現(xiàn)版本發(fā)布的質(zhì)量，當然是布署上線的次數(shù)越少越好。

在未來，唔哩考慮讓平臺自動去處理，不用人工干預，也可以配置成定時任務(wù)去執(zhí)行，比如一些需要在夜間時進行的版本發(fā)布，這樣就會輕松許多。現(xiàn)在我們將一些備份的任務(wù)也放到這個平臺上面來執(zhí)行，每天會定時執(zhí)行并發(fā)送執(zhí)行結(jié)果郵件通知。

三、實時監(jiān)控、持續(xù)優(yōu)化

通過以上敏捷迭代可以在很大程度上能提高生產(chǎn)環(huán)境下的代碼的質(zhì)量，避免出現(xiàn)一些Bug。但是凡事都有意外，所以對于生產(chǎn)環(huán)境正在運行的業(yè)務(wù)，做好持續(xù)的監(jiān)控很重要。

唔哩除了使用zabbix監(jiān)控CPU、內(nèi)存、磁盤IO、網(wǎng)絡(luò)流量IO、進程/端口、TCP連接、日志以及中間件運行狀態(tài)參數(shù)外，還使用了聽云的APM監(jiān)控技術(shù)。唔哩運維總監(jiān)認為：“雖然商業(yè)產(chǎn)品需要成本，但是商業(yè)產(chǎn)品可以提供完備的服務(wù)，總比自已花時間慢慢研究來的直接有效，對于創(chuàng)業(yè)公司來說時間成本是巨大的，產(chǎn)品的快速發(fā)展需要良好的用戶體驗，APM的價值對于用戶來說促進作用非常大，否則因為產(chǎn)品不穩(wěn)定導致用戶流失損失比成本更大。”

聽云APM使用了大數(shù)據(jù)技術(shù)，可以定位分析到每一次函數(shù)調(diào)用具體情況。以下示例為唔哩Server端監(jiān)控圖例說明：

唔哩攜手聽云APM：敏捷運維提升產(chǎn)品質(zhì)量

上圖中是對一個登陸的過程進行的分析，點擊“web應(yīng)用過程”，可以查看耗時百分比，響應(yīng)時間，吞吐率，錯誤率等。選擇“響應(yīng)時間”左邊一欄顯示的接口調(diào)用及平均響應(yīng)時間，右側(cè)顯示為具體的分解圖表信息，可以看到userparter/SELECT這個操作圖形占比最高，峰值近500ms，在表格中也可以看到是mysql操作，耗時占比96%，調(diào)用次數(shù)37,平均響應(yīng)時間為184ms。有了這些數(shù)據(jù)信息，如果出現(xiàn)異常就可以快速定位到具體原因，而且對于產(chǎn)品的持續(xù)優(yōu)化也有參考依據(jù)。

除了Server端，移動端和網(wǎng)絡(luò)也使用了聽云做了監(jiān)控。通過聽云App對唔哩APP的監(jiān)控可以很容易查看客戶端崩潰、網(wǎng)絡(luò)請求、劫持分析、錯誤等。使用聽云Network對網(wǎng)絡(luò)的監(jiān)控是因為聽云能提供用戶端的節(jié)點探測，比IDC節(jié)點監(jiān)控更接近真實用戶的網(wǎng)絡(luò)環(huán)境。

敏捷運維是一種思想，是讓軟件開發(fā)、測試、運維之間建立起溝通協(xié)作關(guān)系，加強角色間信息互換和共享，統(tǒng)一流程和規(guī)范，最終實現(xiàn)運維自動化，共同保證產(chǎn)品的質(zhì)量。