大衆點評運維架構圖文詳解

時間 2020-02-04

原文原文鏈接

轉載說明java

這是篇頗有份量的文章，其涵蓋當時運維的通用技術架構和管理工具，即使在文章寫出後的幾年內都有着必定的技術價值。雖然我在點評時間不是很長，但能爲點評的運維架構貢獻一份力量（puppet管理系統）深感自豪，很是感謝當時的領導和一塊兒協做的同事的幫助和共同努力。python

一、點評運維團隊的配置

目前咱們運維分爲4個組，相信跟大部分公司同樣，運維團隊分爲：應用運維、系統運維、運維開發和監控運維，固然還有DBA團隊和安全團隊，這裏就不一一羅列了。整個運維團隊全算上目前是不到40人規模。nginx

咱們團隊分工是這樣的：web

應用運維：負責支持線上業務，各自會負責對應的業務線，主要職能是保證線上業務穩定性和同開發共同支撐對應業務，以及線上服務管理和持續優化。算法
運維開發：幫助運維提高工做效率，開發方便快捷的工具，實現運維平臺化自動化。docker
系統運維：負責操做系統定製和優化，IDC管理和機器交付，以及跳板機和帳號信息管理。shell
監控運維：負責發現故障，並第一時間通知相關人員，及時處理簡單故障和啓動降級方案等。vim

二、點評的總體架構

先看下點評的機房狀況。後端

點評目前是雙機房結構，A機房主跑線上業務，B機房跑測試環境和大數據處理做業，有hadoop集羣、日誌備份、災備降級應用（在建）等。點評目前機房物理機+虛擬機有近萬臺機器。緩存

點評的總體架構，仍是跟多數換聯網公司同樣，採用多級分層模式，咱們繼續來詳細看下點評總體架構。

上面這幅圖基本歸納了點評的總體架構環境：

用戶引導層用的是第三方的智能DNS+CDN。
負載均衡首先是F5作的4層負載均衡以後是dengine作的7層負載均衡（Dengine是在tengine基礎上作了二次開發）。再日後是varnish作的頁面緩存以後請求到web端 web端經過內部協議調用service（RPC）。
圖片存儲用的是mogileFS分佈式存儲。
全部業務，所有有高可用方案，應用所有是至少2臺以上。
固然，具體業務要複雜不少，這裏只是抽象出簡單層面，方便各位同窗理解。

目前，點評運維監控是從4個維度來作的：

業務層面，如團購業務每秒訪問數，團購券每秒驗券數，每分鐘支付、建立訂單等（cat）。
應用層面，每一個應用的錯誤數，調用過程，訪問的平均耗時，最大耗時，95線等（cat）。
系統資源層面：如cpu、內存、swap、磁盤、load、主進程存活等（zabbix）。
網絡層面：如丟包、ping存活、流量、tcp鏈接數等（zabbix cat）。

三、點評運維繫統介紹

點評的運維和平臺架構組作了不少實用的工具，這些工具組成了點評的總體運維體系。

目前自動化運維比較熱，但自動化運維我的以爲是一種指導思想，不必硬造概念和生搬硬套。自動化在不少公司百花齊放，各家有各家的玩法。但無論怎麼定義，運維人員都必須從不一樣緯度去面對和解決企業所存在的問題。

點評在這方面，也是摸着石頭過河，咱們的思路是先造零件，再整合，經過零件的打造和之間的整合，慢慢勾勒出一條適合本身的運維自動化框架。

咱們運維的理念是：

能用程序幹活的，堅定程序化、平臺化；
能用管理解決的問題，不用技術解決；
同一個錯誤不能犯三次；
每次故障，都是學習和提高的機會；
每一個人都要有產品化思惟，作平臺產品讓開發走自助路線；
小的，單一的功能，組合起來完成複雜的操做（任務分解）；

因此，咱們將本身的理念，融入到本身的做品中，作出了不少工具。

首先總體作個說明，點評運維工具系統彙總：

全方位監控系統：覆蓋業務、應用、網絡、系統等方面，作到任何問題，均可直觀反饋。對不一樣應用等級，作到不一樣監控策略和報警策略。
自動化工具系統：對重複的、容易出錯的、繁瑣的工做盡量工具化，經過小的策略組合，完成大的任務。
配置和管理系統：對於複雜的配置管理，儘量web化、標準化、簡單化，有模板定義，有規範遵循。
記錄和分析系統：對發生的問題和數據作記錄並分析，不斷的總結、完善和提高。

下面就跟你們來一一介紹下：

3.1 全方位監控系統

Zabbix你們應該很是熟悉了，這裏就不作介紹，主要介紹下cat監控。

業務監控：

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

除了這些，還有建立訂單、支付、首頁訪問、手機訪問等業務數據。

這張圖是從業務角度來監控的。

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

應用監控：

從業務層面往下，就是應用層面。

應用狀態大盤可清晰表示當前業務組件狀態，若是某個業務不可用，其下面某個應用大量報錯，說明多是該應用致使。

該監控大盤十分清晰明的能展現業務下面的應用狀態，可在某業務或者某域名打不開的時候，第一時間找出源頭。

下圖爲應用報錯大盤，出問題的應用會實時登榜（每秒都會刷新數據），當出現大故障時，運維人員可一眼看出問題；而當多個不一樣業務同時報錯時，則多是公共基礎服務出了問題。

再看下圖的這個功能，是Cat最強大的功能，能完整顯示應用之間調用過程，作了什麼事情，請求了那些，用了多長時間，成功率是多少，訪問量是多大，一覽無餘。 Cat幾乎無死角的覆蓋到業務和應用層面的監控，固然還可作網絡等層面監控，總之很是強大。這也是點評的鷹眼系統。

Logscan日誌掃描工具:

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

3.2 自動化工做系統

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

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

咱們遵循一個理念，能用程序跑，就不去人操做。

流程有不一樣狀態的轉化，分別爲發起、審計、執行、驗證等環節。用戶可自行發起本身的需求變動，經過運維審覈，操做（大部分是自動的），驗證。如擴容、上線、dump內存、封IP等都爲自動化流程。

以咱們線上自動化擴容流程爲展現，用戶使用時，須要填寫對應信息，提交後，運維在後臺審覈事後，就徹底自動化擴容，擴容完成會有郵件通知，全程運維不須要登陸服務器操做。（自動化倒不是太複雜的技術難題，經過小的任務組合，設置好策略便可）. 幾十臺機器的擴容，運維只需點個審覈經過按鈕，數分鐘而已。

通過長時間的推廣，點評如今98%以上變動都是經過工做流平臺完成的，全部變動所有有記錄，作到出問題時有法可依，違法可糾。

並且經過流程單的使用頻率，可作數據分析，瞭解哪些操做比較頻繁，可否自動化掉，是否還有優化空間。這纔是作平臺的意義，以用戶爲導向。

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

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

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

點評的運維，除了有些無法自動化的手動配置下，其餘基本都是開發自助。這就是自動化的威力！

Go平臺系統，是一套運維操做系統，其中包含了不少常規操做、如批量重啓、降級、切換、上下線、狀態檢測等。

該系統主要是解決運維水平良莠不齊，工具又各有各的用法，好比說批量重啓操做，有用ssh、有用fabric、有本身寫shell腳本的。乾脆直接統一，進行規範，定義出來操做，經過平臺化進行標準化。因爲長時間不出問題，偶爾出一下，運維長時間不操做，找個批量重啓腳本還要找半天。哪些不能自動化的，咱們基本都作到go裏了，在這裏基本都是一鍵式的傻瓜操做了。

如今，咱們監控團隊就能夠靈活操做，不須要有多高的技術含量，而且每次操做都有記錄，作好審計和受權。

全部後臺基本都是python、shell腳本實現，小的腳本組再整合成任務，這也是咱們的重要理念之一。對於比較複雜的任務，咱們進行分解，而後用小的，單一的功能，組合起來完成複雜的操做（任務分解）。其實咱們實現自動化也是這個思路，先造零件，再拼裝。

儘管有了puppet，go等工具，但對於一些job做業的管理，也顯得很是吃力，咱們架構組的同窗作出一套任務調度系統。至關於分佈式的crontab，而且有強大的管理端。徹底自主化管理，只須要定義你須要跑的job，你的策略，就徹底不用管了。會自動去作，而且狀態彙報、監控、等等所有都有記錄，並實現徹底自助化。

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

3.3 配置和管理系統

先介紹下puppet管理系統，相信很多同窗對puppet語法格式深惡痛絕，而且也領教過一旦改錯形成的故障嚴重性。

並且隨着多人協同工做後，模板和文件命名千奇百怪，沒法識別。

針對這些問題，點評就作了一套管理工具，主要是針對puppet語法進行解析，實現web化管理，並進行規範化約束。

跟go系統同樣的想法，將puppet中模塊進行組合，組合成模塊集（方法集），可方便識別和靈活管理。

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

點評系統不少，基本上遇到個痛點，都會有人想辦法把痛點解決。

下面就介紹下點評另外一套強大配置系統，lion。

Lion是一套應用配置管理系統，點評的全部應用用到的配置，不在本地文本文件存儲，都在一個單獨系統存儲，存儲以key/value的方式存儲。而且也是徹底平臺化，運維負責作好權限控制和審計。開發所有自助。

其核心是用了zookeeper的管理機制，將配置信息保存在 Zookeeper 的某個目錄節點中，而後將全部須要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺應用機器就會收到 Zookeeper 的通知，而後從 Zookeeper 獲取新的配置信息應用到系統中。

是否是在點評作運維輕鬆不少？各類操做都工具化，自助化，自動化了。那運維還須要作什麼。

3.4 記錄和分析系統

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

這個是咱們故障分析系統，全部的故障都會作記錄，故障結束後都會case by case的進行深刻分析和總結。其實以上不少系統，都是從這些記錄中總結出來的。

該系統爲故障記錄系統，每一個故障都有發生的原因和改進的方案，按期有人review。

運維起來很輕鬆嗎？也不輕鬆，只是工做重點有了轉移，避開了那些重複繁瑣的工做，和開發同窗深度結合，共同注重運營質量和持續優化。

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

並經過同比和環比，以及平均指標等數據，讓各開發團隊進行平臺化PK，性能差的運維會去推進改進。

最後一個須要介紹的是雷達系統，該系統是咱們最近在作的，一個比較高大上的項目。

朋友們也感覺到了，咱們系統之多，出問題查起來也比較費時。很多同窗生產環節也遇到過相似問題，出了問題究竟是什麼鬼？到底哪一塊引發的呢？結合這個問題，咱們把線上的問題作了個分類，並給了一些策略層面的算法，能快速顯示。可以讓故障有個上下文的聯繫，如：上線時間、請求數降低、錯誤數增多等，哪一個先出現，哪一個後出現？固然，這塊功能還在作，目標是實現出問題的時候，一眼就能從雷達系統定位問題類型和範圍。

以上向你們演示的就是點評的運維繫統，相信咱們點評的運維思想都在裏面體現了。

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

以前也是經過運維root登陸，而後寫腳本批量跑命令的低效運維。也經歷過CMDB系統信息不許確，上線信息錯亂的尷尬局面。也遇到過出了很大問題，運維忙來忙去，找不到rootcase。

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

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

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

變動不知道誰作的，沒法恢復，變動完也找不到根據，形成重大故障。//以前線上puppet經過vim的管理方式，因爲運維同窗失誤推了一個錯誤配置，致使所有業務不可用1個小時，咱們後面經過規範puppet配置修改並作成工具，進行權限控制，還加了流程系統，進行避免。
出了問題，開發說代碼沒問題，運維說環境沒問題，該找誰？//咱們後面作了工具，經過DOM和cat系統，可進行深度診斷，基本很容易定位問題所屬。
執行了個錯誤命令，全線都變動了，致使服務不可用。//咱們經過go系統，進行平常操做梳理，並作成工具，運維90%操做均可經過自動化流程和go平臺完成。大大縮減故障產生率，而且以後進行權限回收。
出問題了，各類系統翻來查去，沒法快速定位，找不到rootcase。//點評正在作雷達系統，就是將歷史存在的問題，進行復盤，將一些故障類型，進行分級，而後經過策略和算法，在雷達系統上進行掃描，出問題環節可快速第一時間優先顯示。
運維每天忙成狗，還不出成績，每天被開發吐槽。//點評這兩年徹底扭轉了局勢，如今是運維吊打開發，由於咱們目前，大部分系統都實現了開發自助化，運維被解放出來，開始不斷完善平臺和關注業務運營質量，咱們dom系統是可定製的，運維天天都把各業務的核心指標報表發到各位老大那裏，哪些服務質量差，響應慢，開發都會當即去改。（固然，須要老大們支持）。