運維服務進化論

本文作者苗輝先生負責白山第一個產(chǎn)品線CDN-X的相關研發(fā)工作，帶領團隊在3個月內(nèi)實現(xiàn)CDN-X系統(tǒng)從無到有，依靠獨特的SHAQUE、MANTA、TUNA、DOLFIN技術和質(zhì)量化運維體系取得平臺4個月上量500G，90%以上客戶PK第一名的成績。

作為網(wǎng)絡傳輸優(yōu)化專家，苗輝先生在運營支撐與性能優(yōu)化方面積累了豐富經(jīng)驗。2007年至2011年，就職于網(wǎng)宿，帶領團隊創(chuàng)建網(wǎng)宿科技CDN運營監(jiān)控體系；2011年至2014年任百度架構師，負責百度自建CDN架構和服務質(zhì)量的優(yōu)化改進，自建CDN穩(wěn)定性業(yè)內(nèi)首達4個9，并成功承載百度搜索等80%的百度核心業(yè)務。

下文是苗輝先生對于質(zhì)量化運維思考與實踐的分享：

自動化運維的話題大家都已經(jīng)很熟悉了。不過，正如世間萬物一樣，運維服務也處于不斷進化之中。在白山云科技有限公司（簡稱“白山”）的團隊看來，在如今云服務時代，相對于自動化運維，我們更需要質(zhì)量化運維。

圖片中天臺上運維同學的壓力并非來自于老板與同事，而是來自于圖中沒有畫出來的客戶！因為服務沒做好，全公司都處在被動的境地，客戶通過老板與同事把壓力傳達給了運維。

樓下的同事哪一個不苦逼，哪一個無壓力？今天之所以站在天臺上的是運維而不是別的角色，恰恰說明運維與服務質(zhì)量關系最為重大。

要在這樣的環(huán)境中做好運維，必須要明白運維的本質(zhì)—— 做好服務才是運維的本質(zhì)。

眾所周知，服務是互聯(lián)網(wǎng)行業(yè)的立足之本，云服務時代的到來，更是一切皆服務。在這個時代運維的方式也發(fā)生了改變。此時的運維與服務的關系更為直接，與最終用戶的距離也前所未有的近。

有人說做好自動化運維，矛盾不就解決了嗎�？墒钦娴氖沁@樣嗎？

舉個例子，面對不可規(guī)避的宕機和網(wǎng)絡問題，你開發(fā)了一個高水平的智能調(diào)度系統(tǒng)，它能夠及時辨別各個IP的服務質(zhì)量高低，并且你設立了一個閾值，如果低于客戶要求，就會立即自動切走。這算是高級而精密的運維自動化系統(tǒng)了，可是這樣一個運維自動化平臺真的能讓服務質(zhì)量達到客戶要求嗎？很可能最終你發(fā)現(xiàn)調(diào)來調(diào)去你的服務質(zhì)量就是達不到客戶的要求，因為你的每個節(jié)點的服務質(zhì)量就是這樣了。

這個皮球可能被你暫時踢給了研發(fā)和產(chǎn)品，但這個球終究還是會回到你這里，并且會使你更加痛苦。因為整個平臺的服務質(zhì)量并沒有提高。

 

我們不僅需要能夠提高效率、減少出錯、消除故障的自動化運維，我們更需要以提高服務質(zhì)量為核心的，涉及自動化、服務質(zhì)量檢測、快速的持續(xù)服務能力、客戶有效溝通等諸多環(huán)節(jié)的質(zhì)量化運維。

其實就是盡一切努力為客戶提供更好的、符合要求的服務。這不僅是概念上的改變，更是平臺架構和服務理念的革新。

運維。

 

當然，質(zhì)量化的基礎在于自動化。

 

自動化

自動化必須要做，沒有自動化，保證服務質(zhì)量就無從談起。一家配置全部需要人肉登錄服務器進行修改的公司，客戶能放心使用它的服務嗎？

快速定位與質(zhì)量敏感體系

只有自動化遠遠不夠，面對諸多用戶反饋的各種質(zhì)量問題，很多自動化工具無能為力。你還需要進行細節(jié)分析才能找到問題的根本。因此我們需要一個快速定位功能和質(zhì)量敏感體系，讓我們能夠先于客戶發(fā)現(xiàn)質(zhì)量問題，并且快速找到問題所在。

透明化

很多時候客戶對服務質(zhì)量的評判手段跟你的并不相同。作為服務提供方，我們最了解服務質(zhì)量內(nèi)部的細微變動，而很多客戶則會在若干小時之后才能用其自己的判斷手段感受到。所以我們還需要一個透明化的機制，讓客戶和我們同步看到服務質(zhì)量的細微變化。

同其他互聯(lián)網(wǎng)公司一樣，在運維自動化方面，我們也投入了大量的精力。

上圖是白山的運維自動化體系，大體分為三層：

 

1.內(nèi)容管理數(shù)據(jù)庫

以CMDB為核心，用以記錄資源信息、資源狀態(tài)、應用類型、客戶信息、客戶配置信息等核心基礎數(shù)據(jù)；

 

2.資源層面

構建了自動掃描、自動監(jiān)控、自動部署、自動配置和故障自動處理等小粒度自動化操作；

 

3.業(yè)務層面

在內(nèi)部兩層的基礎上，結合流程引擎來實現(xiàn)業(yè)務層面自動化上包括：

1>資源管理自動化：節(jié)點的自動上下架、自動割接等；

2>服務管理自動化：服務開通自動化、服務終止自動化等；

3>服務質(zhì)量調(diào)度自動化：根據(jù)每個IP當前服務質(zhì)量來動態(tài)調(diào)度覆蓋，持續(xù)保證穩(wěn)定可用和高服務質(zhì)量；

4>計費賬單自動化：按不同客戶要求自動統(tǒng)計出賬單，并發(fā)送給客戶。

 

我們在做自動化的過程中，有一個貫穿始終的原則

就是：適合的才是最好的。我們不怕重復造輪子，就怕輪子拿來用不上。

接下來我們通過舉例來進一步介紹我們的運維自動化體系。

上圖是我們的節(jié)點建設自動化流程圖。

我們集成了設備自動掃描、軟件自動部署、配置自動安裝等業(yè)務層的自動化過程。

節(jié)點建設自動化是每家公司都在做的，并且許多公司已經(jīng)做得比較完善，思路通常就是將節(jié)點建設過程中復雜的部分剝離給供應商，讓供應商按要求裝好系統(tǒng)，甚至把軟件部署在服務器上，運維只需要下發(fā)配置就可啟動。

但這對于創(chuàng)業(yè)公司來講，是根本不可能的，原因很簡單，供應商不愿陪你這樣玩。 以白山為例，我們單次采購量也就上百臺服務器，我們采購的核心標準就兩個：一是設備必須滿足我們的要求；二是在入圍供應商中選相對便宜的，這樣對方自然不愿提供額外的自動化支持；另一方面，我們目前合作的供應商有數(shù)十家之多，在自動化方面分別管理協(xié)調(diào)供應商的成本遠遠高于自己實現(xiàn)的成本。于是我們設計了這個適用的節(jié)點建設的自動化流程，但是就解放運維生產(chǎn)力的角度來說已經(jīng)足夠。

啟用該自動化流程之前，我們面對的是一堆零散的自動化腳本，需要一個運維同學用兩個小時跟蹤執(zhí)行這些腳本�，F(xiàn)在運維同學被解放出來了，只需要在平臺規(guī)劃好每臺服務器的用途即可全自動完成，這個過程只需運維同學幾分鐘。

這樣，我們就可以將運維人員的精力釋放出來，轉移到提高服務質(zhì)量上。

白山第三版配置自動化架構可以分為如下部分：

以CMDB為核心，通過消息隊列來進行配置文件生成與配置文件分發(fā)大交互。之所以演化三個版本最終這樣設計，是為了解決實際運營中的痛點：

1. 高并發(fā)：平臺要支持每分鐘上百次的配置變更需求，而每次配置變更都將涉及上千臺服務器上配置文件發(fā)布和生效；

2. 支持事務：對于客戶提交的配置，發(fā)布途中客戶發(fā)現(xiàn)語義錯誤需要撤回，平臺要能立即回退所有已發(fā)布的配置；

3. 灰度發(fā)布：分批次灰度部署，配置自動化測試和監(jiān)控將風險控制在最低。

目前我們所有客戶通過portal自助修改的配置和運維同學通過后臺修改的配置，其后臺都是使用上述架構在支撐。

上圖是我們?nèi)�球智能調(diào)度系統(tǒng)DOLFIN的原理圖。智能調(diào)度是服務質(zhì)量的生命和大腦，目前我們是國內(nèi)唯一一家將解析系統(tǒng)做到全球邊緣化的公司。利用DOLFIN系統(tǒng)，實現(xiàn)了基于服務質(zhì)量的調(diào)度，切換從原來的分鐘級提升到秒級。（此架構去年我們的架構師符立佳已經(jīng)進行了一次分享，大家可以關注白山官方微信baishancloud獲取）

不過自動化運維還遠遠不夠。做完自動化，質(zhì)量化運維才剛剛開始。

自動化實現(xiàn)后，我們會發(fā)現(xiàn)客戶的不滿確實有所減少，但你還是無法完全避免。那我們是怎么解決的呢？

通常做法是查看監(jiān)控系統(tǒng)找異常，審查日志找線索，復盤整個操作過程。在一個三層網(wǎng)絡架構中，復盤過程可能會橫跨3-4臺服務器。這個過程少則30分鐘，多則需要3-4天，有時可能更長。所以我們需要一個快速定位來解決這個痛苦的過程。

所謂天下武功唯快不破�？蛻舨⒎遣辉试S出問題，而是怕出現(xiàn)問題后解決速度慢。所以我們需要快速定位的功能來找到根本問題。

上圖是快速定位的實現(xiàn)過程。

我們將以往的運維手工操作升級到了自動化。IDO打通了運營支撐的各個平臺，將監(jiān)控系統(tǒng)跟CMDB以及配置管理系統(tǒng)、日志系統(tǒng)、流程引擎等數(shù)據(jù)結合，針對不同場景快速在各平臺中搜索匹配的監(jiān)控數(shù)據(jù)或變更行為，在3分鐘內(nèi)定位問題。

這樣已經(jīng)很自動化了，定位質(zhì)量問題也夠快了，可這樣還是一種被動響應，因為這樣依然是“救火”的思維。

服務變差那客服損失的可是真金白銀。有沒有辦法提前于客戶發(fā)現(xiàn)質(zhì)量問題呢？

因此，我們還建立了質(zhì)量敏感體系。質(zhì)量敏感體系建設的目標是先于客戶發(fā)現(xiàn)服務質(zhì)量問題。

如上圖所示，我們進行了兩個層面的建設。

首先，我們通過日志和網(wǎng)絡層數(shù)據(jù)分析，結合外部平臺監(jiān)控，匹配客戶對服務質(zhì)量要求的算法，時時分析服務質(zhì)量，一旦發(fā)現(xiàn)異常立即報警。 

其次，我們梳理了與服務質(zhì)量相關的高風險操作和基礎故障，并以風險預警的方式發(fā)送給運維。

最開始，我們通過分析日志建模，模擬與用戶同樣的算法匹配服務質(zhì)量的變化。但在分析過程中，我們發(fā)現(xiàn)日志其實是一個黑盒子。通過日志可以統(tǒng)計用戶訪問的狀態(tài)碼比例、成功率，但日志實際記錄的只是用戶請求到達及內(nèi)容寫入網(wǎng)卡緩沖的時間，而數(shù)據(jù)包則需要經(jīng)歷兩個甚至更長的網(wǎng)絡傳輸，以及至少五個緩沖區(qū)。

所以日志紀錄了零毫秒，但客戶實際感受到的可能是1s，內(nèi)核偷走了你的時間。因此，對于小文件來說，發(fā)送計時永遠不準確。

另外，以流媒體服務來說，用戶非常關心首次緩沖時間，而日志記錄的是用戶訪問播放流媒體的完整時間，無法獲取首次緩沖時間。

為解決日志問題，我們實現(xiàn)了一個內(nèi)核模塊在四層進行完整的訪問過程監(jiān)控。從開始收到SYN包到整個TCP連接過程結束，可以實時監(jiān)控到整個連接上的每一刻的丟包率、傳輸速率�；�于此，我們可以得到小文件的傳輸所用時間。另外，對于流媒體的首次緩沖時間，同樣可以通過近似的算法計算得出（例如計算第一個500K字節(jié)傳輸完畢的時間）。同時我們可以實時計算視頻的播放碼流，評判客戶播放的服務質(zhì)量。

上圖是信息報警的展示。

一切都做好了，客戶總該滿意了。然而信息的不對稱，卻使客戶的焦慮并未消除。

所以，我們必須將服務透明化，讓客戶清晰地知道我們的服務到底發(fā)生了什么。

首先，與網(wǎng)購物流跟蹤類似，通過白山的質(zhì)量化運維平臺，客戶可以方便地跟蹤當前需求/問題的處理狀態(tài)，預估解決時間，甚至可以直接聯(lián)系運維人員進行催單。

其次，我們將整個服務過程公開給客戶。上圖展示了四層監(jiān)控全量采樣的用戶實時服務質(zhì)量�？蛻敉ㄟ^portal可以看到以上信息。同時，我們將秒推系統(tǒng)的工作過程以及動態(tài)路由選路過程也實時展現(xiàn)給客戶。

透明化其實沒那么可怕！做好透明化，會使客戶對于服務具有更強的掌控力，對我們的服務更放心，產(chǎn)生更好的信任，進而與我們產(chǎn)生更多的交流互助。最后帶來的效果就是服務質(zhì)量的不斷提升，與客戶滿意度的不斷提高。

再回到我們的起點。在我們看來，從自動化到質(zhì)量化不僅僅是概念上的迭代！

改變也不只一點點。

因為白山做到了質(zhì)量化運維，實現(xiàn)了平臺建起四個月上量500G，超過90%的客戶PK服務質(zhì)量第一。

白山不存在PK平臺，我們只建設全質(zhì)量平臺，保證客戶在測試和正式上量使用的服務質(zhì)量完全一致。

這就是關于質(zhì)量化運維我要給大家分享的內(nèi)容，歡迎各位關注白山的官方微信“baishancloud”和官方微博“白山云科技”，或通過各種方式與白山開展交流互動。