1. 程式人生 > >內行人是怎樣看待大眾點評的運維架構?

內行人是怎樣看待大眾點評的運維架構?

今天分享專題大綱如圖所示,從5個方面跟大家一起探討:

wKioL1WBjfHhWcJHAAQ8NNMCcDw937.jpg

1、點評運維團隊的配置

目前我們運維分為4個組,相信跟大部分公司一樣,運維團隊分為:應用運維、系統運維、運維開發和監控運維,當然還有DBA團隊和安全團隊,這裡就不一一羅列了。整個運維團隊全算上目前是不到40人規模。

wKioL1WBjgzi4ltuAATbQ9sE12s530.jpg

我們團隊分工是這樣的:

  • 應用運維:負責支援線上業務,各自會負責對應的業務線,主要職能是保證線上業務穩定性和同開發共同支撐對應業務,以及線上服務管理和持續優化。

  • 運維開發:幫助運維提升工作效率,開發方便快捷的工具,實現運維平臺化自動化。

  • 系統運維:負責作業系統定製和優化,IDC管理和機器交付,以及跳板機和賬號資訊管理。

  • 監控運維:負責發現故障,並第一時間通知相關人員,及時處理簡單故障和啟動降級方案等。

2、點評的整體架構

先看下點評的機房情況。

wKiom1WBjHHS8i6rAATfjXwyTGM692.jpg

點評目前是雙機房結構,A機房主跑線上業務,B機房跑測試環境和大資料處理作業,有hadoop叢集、日誌備份、災備降級應用(在建)等。點評目前機房物理機+虛擬機器有近萬臺機器。

點評的整體架構,還是跟多數換聯網公司一樣,採用多級分層模式,我們繼續來詳細看下點評整體架構。

wKiom1WBjIXwCWgNAAhDZGLUZfM736.jpg

上面這幅圖基本概括了點評的整體架構環境:

  • 使用者引導層用的是第三方的智慧DNS+CDN。

  • 負載均衡首先是F5做的4層負載均衡 之後是dengine做的7層負載均衡(Dengine是在tengine基礎上做了二次開發)。再往後是varnish做的頁面快取  之後請求到web端 web端通過內部協議呼叫service(RPC)。

  • 圖片儲存用的是mogileFS分散式儲存 。

  • 所有業務,全部有高可用方案,應用全部是至少2臺以上。

  • 當然,具體業務要複雜很多,這裡只是抽象出簡單層面,方便各位同學理解。

目前,點評運維監控是從4個維度來做的:

  1. 業務層面,如團購業務每秒訪問數,團購券每秒驗券數,每分鐘支付、建立訂單等(cat)。

  2. 應用層面,每個應用的錯誤數,呼叫過程,訪問的平均耗時,最大耗時,95線等(cat)。

  3. 系統資源層面:如cpu、記憶體、swap、磁碟、load、主程序存活等 (zabbix)。

  4. 網路層面: 如丟包、ping存活、流量、tcp連線數等(zabbix cat)。

3、點評運維繫統介紹

wKioL1WBjkqSxSw0AAX6sVpFNBA249.jpg

點評的運維和平臺架構組做了很多實用的工具,這些工具組成了點評的整體運維體系。

目前自動化運維比較熱,但自動化運維個人覺得是一種指導思想,沒必要硬造概念和生搬硬套。自動化在很多公司百花齊放,各家有各家的玩法。但不管怎麼定義,運維人員都必須從不同緯度去面對和解決企業所存在的問題。

點評在這方面,也是摸著石頭過河,我們的思路是先造零件,再整合,通過零件的打造和之間的整合,慢慢勾勒出一條適合自己的運維自動化框架。

我們運維的理念是:

  1. 能用程式幹活的,堅決程式化、平臺化;

  2. 能用管理解決的問題,不用技術解決;

  3. 同一個錯誤不能犯三次;

  4. 每次故障,都是學習和提升的機會;

  5. 每個人都要有產品化思維,做平臺產品讓開發走自助路線;

  6. 小的,單一的功能,組合起來完成複雜的操作(任務分解);

所以,我們將自己的理念,融入到自己的作品中,做出了很多工具。

首先整體做個說明,點評運維工具系統彙總:

  • 全方位監控系統:覆蓋業務、應用、網路、系統等方面,做到任何問題,都可直觀反饋。對不同應用等級,做到不同監控策略和報警策略。

  • 自動化工具系統:對重複的、容易出錯的、繁瑣的工作儘可能工具化,通過小的策略組合,完成大的任務。

  • 配置和管理系統:對於複雜的配置管理,儘可能web化、標準化、簡單化,有模板定義,有規範遵循。

  • 記錄和分析系統:對發生的問題和資料做記錄並分析,不斷的總結、完善和提升。

下面就跟大家來一一介紹下:

3.1 全方位監控系統

Zabbix大家應該非常熟悉了,這裡就不做介紹,主要介紹下cat監控。

wKiom1WBjLKTZBxNAAJ-4MXzQDQ844.jpg

  • 業務監控:

這張是cat的應用監控圖表,可直觀從業務角度看出問題,可跟基線的對比,發現問題所在。如圖所示,此時支付遠偏離基線,流量正常,可能後端出了問題。

除了這些,還有建立訂單、支付、首頁訪問、手機訪問等業務資料。

這張圖是從業務角度來監控的。
wKiom1WBjMqgxOdWAAQoJ-JP7JY437.jpg

這張也是從業務層面來監控的,該圖展示的是手機的訪問量趨勢圖,下面包括延遲、成功率、連結型別、運營商等都有明確資料,該監控可全方位覆蓋業務。

wKioL1WBjo-Qgbg6AAJCIg1LATI683.jpg

  • 應用監控:

從業務層面往下,就是應用層面。應用狀態大盤可清晰表示當前業務元件狀態,如果某個業務不可用,其下面某個應用大量報錯,說明可能是該應用導致。該監控大盤十分清晰明的能展示業務下面的應用狀態,可在某業務或者某域名打不開的時候,第一時間找出源頭。

下圖為應用報錯大盤,出問題的應用會實時登榜(每秒都會重新整理資料),當出現大故障時,運維人員可一眼看出問題;而當多個不同業務同時報錯時,則可能是公共基礎服務出了問題。

wKiom1WBjPeAC-IhAAKvZmIFiBM957.jpg

再看下圖的這個功能,是Cat最強大的功能,能完整顯示應用之間呼叫過程,做了什麼事情,請求了那些,用了多長時間,成功率是多少,訪問量是多大,盡收眼底。 Cat幾乎無死角的覆蓋到業務和應用層面的監控,當然還可做網路等層面監控,總之非常強大。這也是點評的鷹眼系統。

wKioL1WBjr_RwlNKAAhjZSha1bs593.jpg

  • Logscan日誌掃描工具:

wKioL1WBjtbCcJ1BAAQ7oJ-ZNr4083.jpg

Logscan系統,是一套日誌掃描工具,可根據你定義的策略,對日誌內容進行定時掃描,該工具可覆蓋到基於日誌內容的檢測,結合zabbix和cat,實現無死角覆蓋。 比如有一些攻擊的請求,一直遍歷你的url,通過cat、zabbix等都無法靈活捕獲,有了日誌掃描,便可輕鬆發現。

3.2 自動化工作系統

首先介紹下點評的流程系統-workflow系統

顧名思義workflow是一套流程系統,其核心思想是把線上所有的變更以標準化流程的方式,梳理出來。

我們遵循一個理念,能用程式跑,就不去人操作。

流程有不同狀態的轉化,分別為發起、審計、執行、驗證等環節。使用者可自行發起自己的需求變更,通過運維稽核,操作(大部分是自動的),驗證。 如擴容、上線、dump記憶體、封IP等都為自動化流程。

wKioL1WBjvGgyyKMAAYKe8OzK1E610.jpg

以我們線上自動化擴容流程為展示,使用者使用時,需要填寫對應資訊,提交後,運維在後臺稽核過後,就完全自動化擴容,擴容完成會有郵件通知,全程運維不需要登入伺服器操作。(自動化倒不是太複雜的技術難題,通過小的任務組合,設定好策略即可). 幾十臺機器的擴容,運維只需點個稽核通過按鈕,數分鐘而已。

wKiom1WBjVfh5dhCAARJqA54FRI147.jpg

經過長時間的推廣,點評現在98%以上變更都是通過工作流平臺完成的,所有變更全部有記錄,做到出問題時 有法可依,違法可糾。而且通過流程單的使用頻率,可做資料分析,瞭解哪些操作比較頻繁,能否自動化掉,是否還有優化空間。 這才是做平臺的意義,以使用者為導向。

wKioL1WCGv6Bjr3VAAIvudCi5jc534.jpg

流程系統就介紹到這裡,朋友們可關注下其中核心思想。

下面介紹另一套重量級核心系統:Button系統

Button是一套程式碼管理、打包、部署上線系統,開發可完全自主化進行上傳程式碼,自動化測試,打包,預發,灰度上線,全部上線,問題回滾等操作。 全程運維不用幹預,完全平臺自主化。

wKiom1WCFviRF5VyAASTRjdWYpI724.jpg

點評的運維,除了有些沒法自動化的手動配置下,其他基本都是開發自助。 這就是自動化的威力!

Go平臺系統,是一套運維作業系統,其中包含了很多常規操作、如批量重啟、降級、切換、上下線、狀態檢測等。該系統主要是解決運維水平參差不齊,工具又各有各的用法,比如說批量重啟操作,有用ssh、有用fabric、有自己寫shell指令碼的。 乾脆直接統一,進行規範,定義出來操作,通過平臺化進行標準化。 由於長時間不出問題,偶爾出一下,運維長時間不操作,找個批量重啟指令碼還要找半天。 哪些不能自動化的,我們基本都做到go裡了,在這裡基本都是一鍵式的傻瓜操作了。

wKiom1WCFx2BNuJPAAb_uvfQn_o709.jpg

現在,我們監控團隊就可以靈活操作,不需要有多高的技術含量,並且每次操作都有記錄,做好審計和授權。

wKioL1WCGOjhwjcsAAR2pdoyRL0572.jpg

所有後臺基本都是python、shell指令碼實現,小的指令碼組再整合成任務,這也是我們的重要理念之一。 對於比較複雜的任務,我們進行分解,然後用小的,單一的功能,組合起來完成複雜的操作(任務分解)。 其實我們實現自動化也是這個思路,先造零件,再拼裝。

wKioL1WCGRWgeXe0AAZF1iEbm6c263.jpg

儘管有了puppet,go等工具,但對於一些job作業的管理,也顯得非常吃力,我們架構組的同學做出一套任務排程系統。相當於分散式的crontab,並且有強大的管理端。 完全自主化管理,只需要定義你需要跑的job,你的策略,就完全不用管了。會自動去做,並且狀態彙報、監控、等等全部都有記錄,並實現完全自助化。

wKiom1WCF3jzfFmqAAXU0KD1a5I654.jpgwKioL1WCGUDwEphgAAXTATADQag222.jpg

以上這些系統都非常注重體驗,都有非常詳細的資料統計和分析,每過一段時間,都有人去看,不斷改進和優化,真正做到產品自運營。還有一些自動化系統就不一一介紹了。

3.3 配置和管理系統

先介紹下puppet管理系統,相信不少同學對puppet語法格式深惡痛絕,並且也領教過一旦改錯造成的故障嚴重性。而且隨著多人協同工作後,模板和檔案命名千奇百怪,無法識別。針對這些問題,點評就做了一套管理工具,主要是針對puppet語法進行解析,實現web化管理,並進行規範化約束。跟go系統一樣的想法,將puppet中模組進行組合,組合成模組集(方法集),可方便識別和靈活管理。

wKiom1WCF6LxwXygAAdF-zEUKj0316.jpg

下面展示的是我們的軟負載均衡管理頁面,該系統是線上SLB的管理系統。 其核心在於把nginx語法通過xml進行解析,實現web化管理,傻瓜式配置,規範化配置,避免誤操作,版本控制,故障回滾等。

wKioL1WCGWXQxBcqAAVhkC32hGc149.jpg

wKiom1WCF9OT_k44AAQDbfPf6Tc921.jpg

點評系統很多,基本上遇到個痛點,都會有人想辦法把痛點解決。下面就介紹下點評另一套強大配置系統,lion。

wKiom1WCGdmjB-7IAAY1zp6UzXw384.jpg

Lion是一套應用配置管理系統,點評的所有應用用到的配置,不在本地文字檔案儲存,都在一個單獨系統儲存,儲存以key/value的方式儲存。並且也是完全平臺化,運維負責做好許可權控制和審計。開發全部自助。

其核心是用了zookeeper的管理機制,將配置資訊儲存在 Zookeeper 的某個目錄節點中,然後將所有需要修改的應用機器監控配置資訊的狀態,一旦配置資訊發生變化,每臺應用機器就會收到 Zookeeper 的通知,然後從 Zookeeper 獲取新的配置資訊應用到系統中。是不是在點評做運維輕鬆很多?各種操作都工具化,自助化,自動化了。那運維還需要做什麼。

3.4 記錄和分析系統

此類系統雖然不怎麼起眼,但對我們幫助也是特別大的,我們通過一些系統的資料記錄和分析,發現了不少問題,也解決不少潛在問題,更重要的是,在這個不斷完善總結的過程中,學習到了很多東西。

這個是我們故障分析系統,所有的故障都會做記錄,故障結束後都會case by case的進行深入分析和總結。其實以上很多系統,都是從這些記錄中總結出來的。

wKioL1WCG6Khz9Y5AAIgn8Eo_js630.jpg

該系統為故障記錄系統,每個故障都有發生的緣由和改進的方案,定期有人review。運維起來很輕鬆嗎?也不輕鬆,只是工作重點有了轉移,避開了那些重複繁瑣的工作,和開發同學深度結合,共同注重運營質量和持續優化。

再來看下圖所示是點評的DOM系統,即運營質量管理平臺,該平臺彙總了線上的伺服器狀態、應用響應質量、資源利用率、業務故障等全方位的資料彙總平臺。

wKioL1WCHAvBAZk0AAa0UG48DsE758.jpg

並通過同比和環比,以及平均指標等資料,讓各開發團隊進行平臺化PK,效能差的運維會去推動改進。

wKiom1WCGmvShrV0AAZPMDJnDpk749.jpg

最後一個需要介紹的是雷達系統,該系統是我們最近在做的,一個比較高大上的專案。朋友們也感受到了,我們系統之多,出問題查起來也比較費時。 不少同學生產環節也遇到過類似問題,出了問題到底是什麼鬼?到底哪一塊引起的呢? 結合這個問題,我們把線上的問題做了個分類,並給了一些策略層面的演算法,能快速顯示。 可讓故障有個上下文的聯絡,如:上線時間、請求數下降、錯誤數增多等,哪個先出現,哪個後出現? 當然,這塊功能還在做,目標是實現 出問題的時候,一眼就能從雷達系統定位問題型別和範圍。

wKiom1WCGEmiqkVuAAToYRGqbfM269.jpg

以上向大家演示的就是點評的運維繫統,相信我們點評的運維思想都在裡面體現了。

運維點評這幾年的發展,主要目標是實現平臺規範化、運維高效化、開發自主化 。

之前也是通過運維root登入,然後寫指令碼批量跑命令的低效運維。也經歷過CMDB系統資訊不準確,上線資訊錯亂的尷尬局面。也遇到過出了很大問題,運維忙來忙去,找不到rootcase。

好在,通過努力,這些問題現在都有了很大改觀,相信朋友們通過展示的系統,能感覺出點評運維的進步。

4、運維踩過的坑和改進的地方

我就這些年,點評運維出的一些case案例,跟大家聊一聊我們做了哪些具體工作:

  1. 變更不知道誰做的,無法恢復,變更完也找不到根據,造成重大故障。//之前線上puppet通過vim的管理方式,由於運維同學失誤推了一個錯誤配置,導致全部業務不可用1個小時,我們後面通過規範puppet配置修改並做成工具,進行許可權控制,還加了流程系統,進行避免。

  2. 出了問題,開發說程式碼沒問題,運維說環境沒問題,該找誰?//我們後面做了工具,通過DOM和cat系統,可進行深度診斷,基本很容易定位問題所屬。

  3. 執行了個錯誤命令,全線都變更了,導致服務不可用。//我們通過go系統,進行日常操作梳理,並做成工具,運維90%操作都可通過自動化流程和go平臺完成。大大縮減故障產生率,並且之後進行許可權回收。

  4. 出問題了,各種系統翻來查去,無法快速定位,找不到rootcase。//點評正在做雷達系統,就是將歷史存在的問題,進行復盤,將一些故障型別,進行分級,然後通過策略和演算法,在雷達系統上進行掃描,出問題環節可快速第一時間優先顯示。

  5. 運維天天忙成狗,還不出成績,天天被開發吐槽。//點評這兩年完全扭轉了局勢,現在是運維吊打開發,因為我們目前,大部分系統都實現了開發自助化,運維被解放出來,開始不斷完善平臺和關注業務運營質量,我們dom系統是可定製的,運維每天都把各業務的核心指標報表發到各位老大那裡,哪些服務質量差,響應慢,開發都會立即去改。(當然,需要老大們支援)。

5、未來關注的領域和方向

點評也有些前沿的關注點,比如比較熱的Paas技術。

PaaS和雲很熱,還有docker技術,點評也不能掉隊,目前點評有數千個docker的例項在跑線上的業務。

wKioL1WCGgzTxp1DAAVVIpzxBLE754.jpg

wKiom1WCGHTwJJ8tAAKvNdrfX48794.jpg

上圖java都是跑的docker例項

wKioL1WCGjOjMkvbAAUIF_xCGso981.jpg

目前點評Docker這塊可做到10秒內快速部署業務並可響應使用者請求。30秒內可完成一次例項無縫遷移。 個人感覺docker技術不在於底層這塊,在於上層管理系統的構造。底層一方面是持續優化,挖掘效能,但更重要的是在策略層和排程層。 如何快速部署、遷移、恢復、降級、擴容等,做好這些還有不少挑戰。

點評這兩年成長很多,但需要走的路也很多,未來關注的點會在多系統的有機整合和新技術的嘗試以及發展,還會更多的關注智慧策略層面。

結束語

在最後結束時,感謝各位到場朋友捧場,也感謝點評運維和平臺架構的每一位同事,有了你們,點評運維才走到了今天,我們共同努力,來創造新時代的運維體系。點評很多系統都是第一次拿出跟大家分享,大家可看一下設計理念和思想。文章內容選自51CTO學院講師馬哥部落格,Linux運維架構師成長之路:http://edu.51cto.com/course/course_id-3559.html