乾貨：魅族基礎架構運維之路

知識 07-14

已獲轉載授權

本文來自魅族雲平台系統架構師梁鵬在聽雲應用性能管理大講堂—《魅族基礎架構運維之路》分享總結

很高興能在這裡跟大家做一個分享和交流。我叫梁鵬，來自魅族雲平台，主要是負責魅族系統運維、平台建設和自動化的工作。很感謝聽雲邀請我過來，今天我分享的主題主要是魅族基礎系統架構運維之路，主要分三個方面給大家做介紹：1、發展歷程；2、運營現狀；3、系統運維的未來。

在正式分享之前，先跟大家說一下公司的背景情況。魅族的互聯網業務起步得比較早，2011年就開始，到2014年真正轉變為一家移動互聯網公司，從2014年起，我們的業務呈迅猛式增長。截止到2015年，註冊用戶超過3000萬，應用商店也超過100萬的應用，整個應用商店的下載量超過了100億，營業收入比同期增長了12倍。到2016年，我們跟很多遊戲廠商合作發行了多款遊戲，遊戲平台累計超過了3000萬用戶，遊戲月活躍超過1200萬。

隨著業務的增長，運維面臨的挑戰是越來越大，運維人員遇到的問題越來越多，運維架構也在不斷的變更優化，伺服器規模從2011年只有5台的規模到2016年超過了6000多台。右圖也可以看見近兩年魅族伺服器規模的一個增長趨勢。

發展歷程

這幾年我們一直主要圍繞著質量、效率、流程、成本來展開運維工作，並且發現我們運維遇到的問題，慢慢的由運維轉化成技術營運，來優化我們的工作，提高運維人員的技術能力，這其中包括填坑、標準化，自動化、流程化和數據化，以及我們對未來混合雲運營的一個展望。

遠古時代

下面給大家具體講一下幾個發展歷程中的時代。我們在2011年初-2011年12月份這個時代叫做「遠古時代」，我們的規模比較小，機櫃只有一個，伺服器只有5台，業務線2條，這個時代當然存在很多問題，我們說幾個主要的問題：

1、機房穩定性，主要體現在伺服器會經常宕機，系統需要重裝，需要人力來支撐。

2、監控的損失，伺服器上線之後沒有及時的監控，出現故障之後不能及時解決，業務的穩定得不到保障。

3、架構單點，業務上線之後沒有部署高可用架構，對我們業務的穩定性也是有影響。比如我們的官網、論壇等等。

針對這一系列問題，首先在穩定性方面方面我們會有一些IDC的操作人員協助我們做一些管理和操作，另外，我們還會通過帶外的管理口對伺服器做一些操作，對系統進行重裝。我們還有一些自動化的腳本，在自動監控方面早期部署了Nagios Cacti，主要是來監控系統穩定性，網路以及業務穩定性。在架構單點方面，主要還是靠人為來驅動，主要是推動業務部署高可用架構，提高業務的可用性這樣的一個解決方案。

石器時代

大家也可以看到隨著這些問題的解決，我們就步入了另外一個時代，這個時代我們叫做「石器時代」，這個時候魅族也是逐步向移動互聯網開始轉型。看一下石器時代的架構：

這個時候我們的IDC還是1個，機櫃增長了30個，伺服器和虛擬機的數量增長了800台，業務線拓展到100個，人力方面運維人員也擴展到12個，但是這個時代還是存在什麼問題呢？幾個主要的問題說一下

1、這個時代機房還存在著很多IBM的包箱、EMC的存儲，這就不符合互聯網的思維了，另外運維成本也是非常高的，在虛擬化方面我們使用的是VMware vSphere解決方案，管理和運維都給我們帶來很多的成本，而且這一套解決方案的成本還是比較高的。面對這個問題我們是怎麼解決的？其實我們跟大多數的互聯網公司一樣，逐步的使用X86伺服器來代替，提高業務的穩定性。在管理方面起到比較大的作用，還節省了不少的成本。

2、第二個問題是機房資源不足，還有擴容難，以及資源管理問題，因為這個時代業務發展是比較快，所以業務需求比較多，而且都是比較緊急的。所以裝機和交付的速度完全跟不上業務的需要。為了解決這個問題，我們部署了多個機房，並且把主要業務分多個機房部署，並且在各個機房部署冗餘資源，除了滿足業務需求的同時還滿足一些計劃外的需求。另外，在資源管理方面我們搭建了一個CMDB，來統一管理線上的一些資產。此時資源管理方面的效率大大的提升。

3、第三個問題是網路不穩定，活動日或者發布日的流量突增。面對這個問題，首先在硬體上就是更換核心網路設備，配置上有所提升，以至於在流量較大的時候，設備的承載方面沒有問題，另外在帶寬上做冗餘，那麼在網路流量突增的情況下，業務也不會因此造成影響。

這裡提到一點，隨著這些改變，我們的網路架構也變成了2.0，1.0架構是單機房，網路層面沒有做虛擬化，使用的是HSRP，2.0架構是多機房，在網路層面使用虛擬化，大二層架構。

4、第4個就是DB伺服器的IO問題導致的業務壓力，早期DB使用的是SAS磁碟，讀寫頻繁的時候，就會帶來一些io問題。

針對這麼一個問題，我們對ssd磁碟或者pciessd進行測試，針對業務的特性對不同的業務配備ssd或者pciessd來滿足業務的IO的需求。

5、第五個問題是批量操作和監控不完善，以及監控的覆蓋率問題。因為這個時候我們的發展比較快，資源包括伺服器的規模都比較多，所以這個時候會有一些批量的操作帶來很多的人力成本。我們部署的Ansible，這個軟體大家都比較熟悉，用來做一些批量的操作。在監控這方面監控，會聯動CMDB，定時對線上運營中的機器做一個巡檢，巡檢到未加監控的機器就會定時給相關人員郵件通知來解決監控覆蓋率低的問題

5、最後的問題就是安全性低，主要體現在早期所有的業務員都可以登錄線上所有機器，沒有許可權限制或者管理。另外一個是來自外網的攻擊，針對這個情況我們結合帳戶管理平台CMDB對用戶做一些許可權的劃分。舉一個例子某個用戶在CMDB上只能訪問哪幾個業務，只能登陸這幾個業務的機器，所以這就在帳號管理方面有一個大幅度的提升，而且有一個操作的審計，後面還可以跟蹤。

青銅時代

伴隨著這些問題的解決，我們其實已經進入了青銅時代，來看看這個時代的規模，我們是兩地三中心，機櫃擴展到150個，伺服器擴展到4000台，業務線也發展到200多條。在人力方面，我們有35個業務人員來支撐。

1、我們面對標準化率低的問題，而且維護成本越來越高，針對這一點，我們對標準化進行梳理，這當中包括很多比如軟體標準化、系統標準化、硬體標準化等等。在系統標準化方面，我們開發了巡檢平台，主要從系統常規、系統安全、系統內核等幾個維度定時進行巡檢，對出現問題的機器進行整改，確保線上標準化覆蓋率100%。

2、關於業務架構單點的問題，這個時代業務發展比較迅速，架構單點的情況還是比較嚴重。解決方案是人工推動，先梳理現有的單點架構業務，然後去部署高可用架構。另外此時我們在架構上做冗餘，部署兩地三中心，當單個機房出現故障的時候，業務的可用性得以保障。3.0架構使用三網分離，DCI增加了專線，流量優先專線，專線出問題後在轉到vpn。

3、另外供應商比較單一，這個供應商就是伺服器，還有網路設備供應商，供應商單一帶來很多問題，比如說成本方面，定製化方面，如果我們想追求一些定製化產品，在對單個管理過程中就很被動，所以在這個時候我們是遵循自己的一套運維設置標準，引入多個廠商來檢測它的兼容性、穩定性，以及業務系統也是聯繫多個廠商，來建立標準。與此同時，也會制定SLA標準、定製化標準，如後續有新的採購需求，都需要按照此標準。

4、配置管理方面準確性低，伺服器從上線到下線，它的狀態改變，這個流程的管理沒有一套很好的解決方案，導致現在的梳理不準確。針對這個情況，我們首先有一整套的伺服器生命周期管理流程，從伺服器的引入、生產、運營、下線一套管理流程來確保CMDB數據準確性，並且會結合一個工單平台，工單平台會跟CMDB進行對接，比如說要開發的時候，我們會發起我們CMDB的業務數，還有部門、產品線，最後當整個工單走完的時CMDB會自動去更改，狀態也會由待營運狀態改變為運營中，那麼這個全部是全自動的，不需要人工參與的。

5、第五個問題就是業務的突增造成機房規模的突增，這個時代我們已經正式步入互聯網時代，業務發展是突飛猛進的，此時面對業務的資源需求，不能及時的交付，此時我們的解決方案就是由原來的cobbler升級至裝機平台，轉化為無人職守安裝，裝機平台和cmdb對接，並沒各個機房會保持一定的資源冗餘率，以滿足業務計劃外的資源需求。後期我們也會使用容量管理對業務機器的資源使用情況進行審核。

6、最後一個問題就是故障多樣性，在供應商多的情況下，由於每個廠商的配件可能不一樣，故障後的日誌收集方案不一樣，導致故障發生時需要定義各個廠商的日誌收集方式、維修人員授權等等操作，造成太多的溝通成本，這在效率維度也是一個痛點。針對這個問題，我們統一各廠商的日誌收集方式，在業務高可用方面，部署高可用架構，當發生故障的時候，無需和業務進行溝通，直接關機進行硬體的維修操作。並按月對故障進行分析，並建立知識庫，後續對這一類的故障可以快速進行處理。

鐵器時代

隨著這些問題的解決，可以說到了現在這個時代，我們稱之為鐵器時代，從2016年1月份到現在，我們的業務呈增長趨勢。

來看一下現在的規模，IDC有多個，機櫃大約200個，伺服器數量超過了6000台，業務線大約200個，平台業務人員增長到43個。

這個時代問題還是有很多的：

1、第一個問題就是對於監控和告警的數據一直沒有量化數據，當然也不能達到可視化的一個效果，比如月度簡訊告警數量統計時，無法在平台維度直接統計數據和展示數據，進而折算簡訊成本，針對這個情況，我們做了統一的告警平台，基礎監控和業務監控都會和告警平台結合，各個平台告警數據統一從告警平台進行收斂、匹配策略後，在發送給相應的用戶，這樣就告警數據對比各個平台單獨的告警數據就會減少很多，一方面減少了告警風暴，一方面告警數據可以在平台進行展示和統計，提高了工作效率。

2、機型套餐多，業務需求個性化。我們是怎麼做的？根據線上的業務特性，比如說高IO類、一線、在線存儲類、熱點類，對線上的業務做一個分析，最後讓機型跟業務的特性做整合。另外還會對CMDB佔比比較小的做整合，比如說A業務100台，B業務只有2台，對於這種佔比小的，也可以根據業務網做一個業務特性，劃定為某一個業務的特性，然後跟不同的機型進行整合。

3、第三個問題業務的成本高，各個業務的ROI無法量化，比如某個業務投入的人力成本和開發成本遠遠大於他的產出成本這樣的情況，針對這個問題，我們還是分兩個維度：一是使用容量系統對資源進行使用率的考核，對於資源使用率較低的機器，推動業務進行業務混布，或者業務遷移至配置較低的機器上面。二是建立營收體系，搭建營收平台，統計各個業務的運營成本和營收成本。

4、工作流程化，前面說我們建立了伺服器生命周期管理一整套流程，但是我們沒有一個很好的平台管理，很多事情還是靠郵件溝通，這帶來的人力成本是很高的。我們建立了這個工單平台，工單平台完全遵循伺服器生命周期感覺的那一套流程，用於記錄各個工單的流程、處理情況、處理人、耗時等等，同時也方便後續的工單跟蹤情況，而且工單平台和cmdb對接，申請者提交需求的時候，會拉取cmdb業務樹和部門進行填寫，當工單完結的時候，會自動掛載業務以及修改伺服器運營狀態、還有對此業務的運維人員進行自動填寫功能，大大的提高了工作效率。

5、第五個問題就是資源利用率的問題，前面也有講過這個情況，就是使用容量平台來監控各個產品線的資源使用情況，然後對資源使用率較低的業務進行混布或者遷移方案。

6、最後一個問題就是預案管理，隨著魅族現在業務線越來越多，特別是遊戲，如果遊戲伺服器出問題，那麼損失還是挺大的，比如收入的損失，玩家群體的損失等等，前面也有說到我們現在部署兩地三中心，在多個數據中心部署業務，當單個數據中心出現故障的時候，可以快速切換到別的IDC伺服器，確保服務正常的運行。另外也會對專線進行定時切換演練，以測試專線切換後是否有問題發生。

講了這麼多，從2011年到現在，整個歷程的問題跟我們是怎麼解決的。再詳細的說兩點，這個業務的增長是從5台到6000台，速度很快，這就很考驗基礎設施的建設。另外一個是很考驗交付效率能力，網路架構也升級到3.0，我們用裝機平台解決我們的工單系統，跟我們的CMDB聯動，降低我們的操作。

成本控制方面其實在一個海量互聯網業務的公司來說，其實微優化可以節省很多成本，這個前幾天和騰訊溝通的時候，他們的成本把控得比較嚴。所以成本這一部分做到最低的優化。我們從幾個維度做：1、資源使用率；2、供應商方面；3、內部營收。從這三個方面進行成本控制。

運營現狀

魅族現在的運維體系跟大部分互聯網公司一樣，採用多級分層模式，所有業務和DB都部署高可用架構，我們的技術平台跟業務平台也有很多的系統，比如發布平台、監控平台等等。在自動化過程中是根據遇到的情況，我們的思路是定義優先順序，任務分解，先做最容易的，最能提高效率點，再做整合，通過各個子系統的整合，慢慢形成適合自己的自動化運維框架。

下面挑幾個比較主要的系統跟大家說一下：

監控系統

我們採用的是server-proxy-client架構，client端的agent會定時主動上報數據至proxy中做臨時緩存，proxy會定時將臨時緩存的數據上報給server端存儲在資料庫，進而講數據展示在zabbix界面。

對監控模板標準化，針對不同的業務定義不同的模板，然後在zabbix平台定義告警匹配的動作，每個業務的運維/開發人員接收自己負責業務的告警。

監控覆蓋率這個方面也是一樣的，我們會先發郵件給相應的人員去處理這個情況，以保證我們的覆蓋率，我們的覆蓋率由早期比較低的一個百分比到達一個百分之百的狀態，而且後續也會每天巡檢，要一直維持百分之百的狀態。

統一告警平台

在沒有告警平台之前，所有的告警信息都從zabbix平台發出，此時伺服器出現故障後，簡訊和郵件告警就會很多，如果不處理，則會一直告警，出現簡訊轟炸的情況，針對此情況，我們開發了告警平台，說一下工作機制：

在統一告警平台中配置服務的匹配策略和故障合并，當告警信息從zabbix生成後，通過預先設定的腳本發送給告警平台，在觸發策略，最後故障合并後，在觸發告警升級策略，即告警首先接收人，如10分鐘沒處理，則升級給團隊處理。

從上面可以看到，我們通過這個平台降低了運營成本，這是告警平台的一個截圖，左邊是應用級，應用級就包括CPU、內存等等，下面是根據業務，哪個業務按月、按天，這也是後續需要優化的。下面是一個月的尾天，哪天的告警比較多，可以根據這天的情況估計一下，保障後面的故障不會發生。

工單平台

因為業務發展比較迅速，所以業務需求還是比較個性化、多樣化的，當然還有比較緊急的。雖然我們有全生命周期管理來管理這一塊，但是我們跟他們還是有很好的溝通。另外還有就是常規性操作的，所以我們就研發了這個工單平台，並且我們工單平台會把伺服器所有流程放在裡面，而且還有一些自定義的功能，可以減少我們我們跟開發之間的溝通成本，開發只需要我們工作人員提需求，不同的需求，不同的節點，比如說OP審核節點，以及他們的開發審核節點，最後整個工單流程完成之後，所有的產品都自動化了。生命周期管理自動化，工單流程的可視化、可追蹤。以前用郵件溝通，你根本無法去追蹤這個單處理到什麼進度了，有這個工單平台，在這個平台上就可以直接查看，查看工單的處理狀態。

巡檢平台

早期我們出現過內核參數設置未生效的問題，iptables處於打開狀態，導致宿主機在大流量和高並發量的情況下網卡容易丟包，影響多個業務的穩定性。我們意識到在OS層，要做定製化和標準化，通過巡檢系統發現非標準機器，定時整改。系統巡檢主要包括系統初始化檢測、系統常規檢測、系統內核檢測、系統安全檢測和下線檢測。

這個是我們巡檢平台的界面，可以按季、按月生成一個巡檢標準率，第一點是建立標準體系，提升工作效率。我們這個巡檢平台剛剛建立的時候，梳理了15個組件系統標準化，發現問題96個，伺服器整改項目有4000多次，降低了線上系統的風險，有效的避免了因非標準因素導致的風險。

更安全的堡壘機

這個還是基於之前早期系統，早先的用戶中心資料庫會拖走，win堡壘機密碼有失竊的情況，安全隱患還是很大的。我們基於以上這些需求做了更安全的堡壘機，

我們的堡壘機架構是在不同機房部署主備堡壘機，兩台堡壘機之間的數據是同步的，用戶可以申請軟體或者硬體的Token，然後通過RSA認證登錄到堡壘機，此時IDC賬戶管理平台會對登錄用戶進行審計把控，包括用戶管理、登錄記錄、分配許可權、操作記錄等等，最後登錄到伺服器上。最後可以提高安全，提高線上系統的安全情況。

流程管理

我們建立了整套伺服器生命周期管理，從產品，伺服器的引入，生產、運營、下線，分為幾類：資源交付類、資源調動類還有一個生命周期末端流程。結合工單平台現在已經正式線上運行了，這一套流程建立之後，OP跟開發之間的溝通成本，節約的時間已經大約2倍多了。

容量系統

我們所有數據都來自於監控系統，CPU、內存、IO能力，我們通過容量系統取數據作一些分析，對使用率比較低的這些又做一些整改，上面那個圖形可以看到閱讀，或者按天資源使用率的情況。

另外，我們也會做業務成本的考核。這裡的業務成本考核是做一個幫襯作用，主要是一個營收平台，我們做了一個內部營收平台，對內的各個業務做一些核算來關注每一個業務的運營成本和產出。這樣每個部門的成本關注度也就提升了五倍。

展望

最後是我們對未來的一個展望。其實魅族也希望內外兼修，來打造精益化運營，通過運維自動化、監控自動化、安全管理、流程管理，來提高服務質量。同時我們也會協同開發平台，大數據平台，為我們的業務提供更優的服務。

本文編號2489，以後想閱讀這篇文章直接輸入2489即可。

輸入m獲取文章目錄