運維服務進化論

發布時間：2016-07-10 01:17:36

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

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

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

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

1. 再問運維的本質

作為從事運維工作的一員，大家可能深都有體會：運維同學很苦逼。

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

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

要在這樣的環境中做好運維，必須要明白運維的本質—— 做好服務才是運維的本質。

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

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

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

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

2. 何為質量化運維

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

2. 何為質量化運維？

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

運維。

當然，質量化的基礎在于自動化。

自動化

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

快速定位與質量敏感體系

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

透明化

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

3. 白山質量化運維實踐

同其他互聯網公司一樣，在運維自動化方面，我們也投入了大量的精力。

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

1.內容管理數據庫

以CMDB為核心，用以記錄資源信息、資源狀態、應用類型、客戶信息、客戶配置信息等核心基礎數據；

2.資源層面

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

3.業務層面

在內部兩層的基礎上，結合流程引擎來實現業務層面自動化上包括：

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

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

3>服務質量調度自動化：根據每個IP當前服務質量來動態調度覆蓋，持續保證穩定可用和高服務質量；

4>計費賬單自動化：按不同客戶要求自動統計出賬單，并發送給客戶。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上圖是快速定位的實現過程。

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

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

服務變差那客服損失的可是真金白銀。有沒有辦法提前于客戶發現質量問題呢？

因此，我們還建立了質量敏感體系。質量敏感體系建設的目標是先于客戶發現服務質量問題。

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

首先，我們通過日志和網絡層數據分析，結合外部平臺監控，匹配客戶對服務質量要求的算法，時時分析服務質量，一旦發現異常立即報警。

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

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

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

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

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