《魅族基礎架構運維之路》要點：
本文介紹了魅族基礎架構運維之路，希望對您有用。如果有疑問，可以聯(lián)系我們。

很高興能在這兒跟大家做一個分享和交流.我叫梁鵬,來自魅族云平臺,主要是負責魅族系統(tǒng)運維、平臺建設和自動化的工作.很感謝聽云邀請我過來,今天我分享的主題主要是魅族基礎系統(tǒng)架構運維之路,主要分三個方面給大家做介紹：1、發(fā)展歷程；2、運營現(xiàn)狀；3、系統(tǒng)運維的未來.

在正式分享之前,先跟大家說一下公司的背景情況.魅族的互聯(lián)網(wǎng)業(yè)務起步得比較早,2011年就開始,到2014年真正轉變?yōu)橐患乙苿踊ヂ?lián)網(wǎng)公司,從2014年起,我們的業(yè)務呈迅猛式增長.截止到2015年,注冊用戶超過3000萬,應用商店也超過100萬的應用,整個應用商店的下載量超過了100億,營業(yè)收入比同期增長了12倍.到2016年,我們跟很多游戲廠商合作發(fā)行了多款游戲,游戲平臺累計超過了3000萬用戶,游戲月活躍超過1200萬.

隨著業(yè)務的增長,運維面臨的挑戰(zhàn)是越來越大,運維人員遇到的問題越來越多,運維架構也在不斷的變更優(yōu)化,服務器規(guī)模從2011年只有5臺的規(guī)模到2016年超過了6000多臺.右圖也可以看見近兩年魅族服務器規(guī)模的一個增長趨勢.

一、發(fā)展歷程

這幾年我們一直主要圍繞著質量、效率、流程、成本來展開運維工作,并且發(fā)現(xiàn)我們運維遇到的問題,慢慢的由運維轉化成技術營運,來優(yōu)化我們的工作,提高運維人員的技術能力,這其中包括填坑、標準化,自動化、流程化和數(shù)據(jù)化,以及我們對未來混合云運營的一個展望.

遠古時代

下面給大家具體講一下幾個發(fā)展歷程中的時代.我們在2011年初-2011年12月份這個時代叫做“遠古時代”,我們的規(guī)模比較小,機柜只有一個,服務器只有5臺,業(yè)務線2條,這個時代當然存在很多問題,我們說幾個主要的問題：

1. 機房穩(wěn)定性,主要體現(xiàn)在服務器會經(jīng)常宕機,系統(tǒng)需要重裝,也就是說需要投入人力來支撐.
2. 監(jiān)控的損失,服務器上線之后沒有及時的監(jiān)控,出現(xiàn)故障之后不能及時解決,業(yè)務的穩(wěn)定得不到保障.
3. 架構單點,業(yè)務上線之后沒有部署高可用架構,對我們業(yè)務的穩(wěn)定性也是有影響.比如我們的官網(wǎng)、論壇等等.

 

針對這一系列問題,首先在穩(wěn)定性方面方面,我們會有一些IDC的操作人員協(xié)助我們做一些管理和操作,另外,我們還會通過帶外的管理口對服務器做一些操作,對系統(tǒng)進行重裝.我們還有一些自動化的腳本,在自動監(jiān)控方面早期部署了NagiosCacti,主要是來監(jiān)控系統(tǒng)穩(wěn)定性,網(wǎng)絡以及業(yè)務穩(wěn)定性.在架構單點方面,主要還是靠人為來驅動,主要是推動業(yè)務部署高可用架構,提高業(yè)務的可用性這樣的一個解決方案.

石器時代

大家也可以看到隨著這些問題的解決,我們就步入了另外一個時代,這個時代我們叫做“石器時代”,這個時候魅族也是逐步向移動互聯(lián)網(wǎng)開始轉型.看一下石器時代的架構：

這個時候我們的IDC還是1個,機柜增長了30個,服務器和虛擬機的數(shù)量增長了800臺,業(yè)務線拓展到100個,人力方面運維人員也擴展到12個,但是這個時代還是存在什么問題呢?幾個主要的問題說一下

1、這個時代機房還存在著很多IBM的刀箱、EMC的存儲,這就不符合互聯(lián)網(wǎng)的思維了,另外運維成本也是非常高的,在虛擬化方面我們使用的是VMwarevSphere解決方案,管理和運維都給我們帶來很多的成本,而且這一套解決方案的成本還是比較高的.面對這個問題我們是怎么解決的?其實我們跟大多數(shù)的互聯(lián)網(wǎng)公司一樣,逐步的使用X86服務器來代替,提高業(yè)務的穩(wěn)定性.在管理方面起到比較大的作用,還節(jié)省了不少的成本.

2、第二個問題是機房資源不足,還有擴容難,以及資源管理問題,因為這個時代業(yè)務發(fā)展是比較快,所以業(yè)務需求比較多,而且都是比較緊急的.所以裝機和交付的速度完全跟不上業(yè)務的需要.為了解決這個問題,我們部署了多個機房,并且把主要業(yè)務分多個機房部署,并且在各個機房部署冗余資源,除了滿足業(yè)務需求的同時還滿足一些計劃外的需求.另外,在資源管理方面我們搭建了一個CMDB,來統(tǒng)一管理線上的一些資產(chǎn).

此時資源管理方面的效率大大的提升.

3、第三個問題是網(wǎng)絡不穩(wěn)定,活動日或者發(fā)布日的流量突增.面對這個問題,首先在硬件上就是更換核心網(wǎng)絡設備,配置上有所提升,以至于在流量較大的時候,設備的承載方面沒有問題,另外在帶寬上做冗余,那么在網(wǎng)絡流量突增的情況下,業(yè)務也不會因此造成影響.

這里提到一點,隨著這些改變,我們的網(wǎng)絡架構也變成了2.0,1.0架構是單機房,網(wǎng)絡層面沒有做虛擬化,使用的是HSRP,2.0架構是多機房,在網(wǎng)絡層面使用虛擬化,大二層架構.

4、第4個就是DB服務器的IO問題導致的業(yè)務壓力,早期DB使用的是SAS磁盤,讀寫頻繁的時候,就會帶來一些io問題. 針對這么一個問題,我們對ssd磁盤或者pciessd進行測試,針對業(yè)務的特性對不同的業(yè)務配備ssd或者pciessd來滿足業(yè)務的IO的需求.

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

6、最后的問題就是安全性低,主要體現(xiàn)在早期所有的業(yè)務員都可以登錄線上所有機器,沒有權限限制或者管理.另外一個是來自外網(wǎng)的攻擊,針對這個情況我們部署RSA堡壘機結合帳戶管理平臺對用戶做一些權限的劃分.舉一個例子某個用戶在CMDB上只有幾個業(yè)務,那么賬戶管理平臺權限分配也只能看到這幾個業(yè)務的業(yè)務,堡壘機只能登錄這幾臺機器,所以這就在安全方面有一個大幅度的提升,而且還會對用戶的操作進行審計和記錄,后面還可以跟蹤.

青銅時代

伴隨著這些問題的解決,我們已經(jīng)進入了青銅時代,來看看這個時代的規(guī)模,我們是兩地三中心,機柜擴展到150個,服務器擴展到4000臺,業(yè)務線也發(fā)展到200多條.在人力方面,我們有35個運維人員來支撐.

在青銅時代,我們還是有很多問題存在的：

1、線上服務器的標準化率低,比如系統(tǒng)層未做標準化,比如yum源未標準化,這樣就可能會造成一些安裝軟件的兼容性問題或者一些其他的問題,我們對于標準化,主要也是從幾個維度來做的,比如系統(tǒng)標準化方面,統(tǒng)一yum源服務器,其他的還有軟件標準化、組件標準化、硬件標準化等等.在系統(tǒng)標準化方面,我們開發(fā)了巡檢平臺,主要從系統(tǒng)常規(guī)、系統(tǒng)安全、系統(tǒng)內(nèi)核等幾個維度定時進行巡檢,對出現(xiàn)問題的機器進行整改,確保線上標準化覆蓋率100%.

2、關于業(yè)務架構單點的問題,這個時代業(yè)務發(fā)展比較迅速,架構單點的情況還是比較嚴重.解決方案是人工推動,先梳理現(xiàn)有的單點架構業(yè)務,然后去部署高可用架構.另外此時我們在架構上做冗余,部署兩地三中心,當單個機房出現(xiàn)故障的時候,業(yè)務的可用性得以保障.此時的網(wǎng)絡架構也隨之升級到3.0架構,3.0架構使用三網(wǎng)分離,DCI增加了專線,流量優(yōu)先專線,專線出問題后在轉到vpn.

3、第三個就是供應商比較單一,比如我們在采購服務器的時候,一些廠商的定制化要求無法滿足,最明顯的例子就是帶外管理的一些功能無法定制化,此時就沒有其他廠商可以選擇,而且在成本方面也不能得到一個很好的成本控制.此時我們就引入多個供應商,按照測試標準進行測試,確認設備是否可以滿足業(yè)務的需求,或者兼容性是否滿足,亦或者是穩(wěn)定性是否滿足等等,測試通過后,確認設備可以正常引入.與此同時,也會制定SLA標準、定制化標準,如后續(xù)有新的采購需求,都需要按照此標準.

4、第4個在資源配置管理方面,準確性低服務器從上線到下線,它的狀態(tài)改變,這個流程的管理沒有一套很好的解決方案,導致現(xiàn)在的平臺數(shù)據(jù)不準確.針對這個情況,我們首先建立一整套的服務器生命周期管理流程,從服務器的引入、生產(chǎn)、運營、下線一套管理流程來確保CMDB數(shù)據(jù)準確性,并且會結合工單平臺,工單平臺會跟CMDB進行對接,比如說開發(fā)提交需求的時候,會拉取CMDB平臺的業(yè)務樹,還有部門、產(chǎn)品線等等,最后當整個工單走完的時CMDB會自動去更改,狀態(tài)也會由待營運狀態(tài)改變?yōu)檫\營中,那么這個全部是全自動的,不需要人工參與的.

5、第5個問題就是業(yè)務的突增造成機房規(guī)模的突增,這個時代我們已經(jīng)正式步入互聯(lián)網(wǎng)時代,業(yè)務發(fā)展是突飛猛進的,此時面對業(yè)務的資源需求,不能及時的交付,此時我們的解決方案就是由原來的cobbler升級至裝機平臺,轉化為無人職守安裝,裝機平臺和cmdb對接,并沒各個機房會保持一定的資源冗余率,以滿足業(yè)務計劃外的資源需求.后期我們也會使用容量管理對業(yè)務機器的資源使用情況進行審核.

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

鐵器時代

隨著這些問題的解決,可以說到了現(xiàn)在這個時代,我們稱之為鐵器時代,從2016年1月份到現(xiàn)在,我們的業(yè)務呈增長趨勢.

來看一下現(xiàn)在的規(guī)模,IDC有多個,機柜大約200個,服務器數(shù)量超過了6000臺,業(yè)務線大約200個,平臺運維人員增長到43個.

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

1、第一個問題就是對于監(jiān)控和告警的數(shù)據(jù)一直沒有量化數(shù)據(jù),當然也不能達到可視化的一個效果,比如月度短信告警數(shù)量統(tǒng)計時,無法在平臺維度直接統(tǒng)計數(shù)據(jù)和展示數(shù)據(jù),進而折算短信成本,針對這個情況,我們做了統(tǒng)一的告警平臺,基礎監(jiān)控和業(yè)務監(jiān)控都會和告警平臺結合,各個平臺告警數(shù)據(jù)統(tǒng)一從告警平臺進行收斂、匹配策略后,在發(fā)送給相應的用戶,這樣就告警數(shù)據(jù)對比各個平臺單獨的告警數(shù)據(jù)就會減少很多,一方面減少了告警風暴,一方面告警數(shù)據(jù)可以在平臺進行展示和統(tǒng)計,提高了工作效率.

2、第二個問題就是機型套餐多,業(yè)務需求個性化.我們是怎么做的?根據(jù)線上的業(yè)務特性,比如說高IO類、一線、在線存儲類、熱點類,對線上的業(yè)務做一個分析,最后讓機型跟業(yè)務的特性做整合.另外還會對CMDB占比比較小的做整合,比如說A業(yè)務100臺,B業(yè)務只有2臺,對于這種占比小的,也可以根據(jù)業(yè)務特性做分析,劃定為某一類業(yè)務的特性,然后根據(jù)不同的機型進行整合.

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

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

5、第5個問題就是資源利用率的問題,前面也有講過這個情況,就是使用容量平臺來監(jiān)控各個產(chǎn)品線的資源使用情況,然后對資源使用率較低的業(yè)務進行混布或者遷移方案.

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

這6點大部分在發(fā)展歷程中已經(jīng)詳細講解了,這里在抽出兩個描述一下：

一個就是基礎設施的規(guī)劃,從遠古時代到鐵器時代,這個業(yè)務突飛猛進的發(fā)展,服務器從5臺到6000臺,網(wǎng)絡架構也升級到3.0,這就很考驗基礎設施的建設.另外一個是很考驗交付效率能力,我們使用裝機平臺來安裝系統(tǒng),并使用工單系統(tǒng)聯(lián)動CMDB平臺,降低我們的操作,提高工作效率.

另外一個就是成本控制方面,其實在一個海量互聯(lián)網(wǎng)業(yè)務的公司來說,稍微優(yōu)化就可以節(jié)省很多成本,此時控制成本也稱為一項勢在必行的工作.

我們從幾個維度做：1、資源使用率；2、供應商方面；3、內(nèi)部營收.從這三個方面進行成本控制.

二、運營現(xiàn)狀

魅族現(xiàn)在的運維體系跟大部分互聯(lián)網(wǎng)公司一樣,采用多級分層模式,所有業(yè)務和DB都部署高可用架構,我們的技術平臺跟業(yè)務運維做了很多實用的系統(tǒng),比如發(fā)布平臺、監(jiān)控平臺等等.在自動化過程中我們根據(jù)遇到的情況,找出痛點,歸納整理出需求,并考慮如何實現(xiàn).我們的思路是定義優(yōu)先級,任務分解,先做最容易的,最能提高效率點,再做整合,通過各個子系統(tǒng)的整合,慢慢形成適合自己的自動化運維框架.

下面挑幾個比較主要的系統(tǒng)跟大家說一下：

監(jiān)控系統(tǒng)

我們采用的是server-proxy-client架構,client端的agent會定時主動上報數(shù)據(jù)至proxy中做臨時緩存,proxy會定時將臨時緩存的數(shù)據(jù)上報給server端存儲在數(shù)據(jù)庫,進而講數(shù)據(jù)展示在zabbix界面.

對監(jiān)控模板標準化,針對不同的業(yè)務定義不同的模板,然后在zabbix平臺定義告警匹配的動作,每個業(yè)務的運維/開發(fā)人員接收自己負責業(yè)務的告警.

監(jiān)控覆蓋率這個方面也是一樣的,我們會先發(fā)郵件給相應的人員去處理這個情況,以保證我們的覆蓋率,我們的覆蓋率由早期比較低的一個百分比到達一個百分之百的狀態(tài),而且后續(xù)也會每天巡檢,要一直維持百分之百的狀態(tài).

統(tǒng)一告警平臺

在沒有告警平臺之前,所有的告警信息都從zabbix平臺發(fā)出,此時服務器出現(xiàn)故障后,短信和郵件告警就會很多,如果不處理,則會一直告警,出現(xiàn)短信轟炸的情況,針對此情況,我們開發(fā)了告警平臺,說一下工作機制：

在統(tǒng)一告警平臺中配置服務的匹配策略和故障合并,當告警信息從zabbix生成后,通過預先設定的腳本發(fā)送給告警平臺,在觸發(fā)策略,最后故障合并后,在觸發(fā)告警升級策略,即告警首先接收人,如10分鐘沒處理,則升級給團隊處理.

從上面可以看到,我們通過這個平臺降低了運營成本,這是告警平臺的一個截圖,左邊是應用級,應用級就包括CPU、內(nèi)存等等,下面是根據(jù)業(yè)務,哪個業(yè)務按月、按天,這也是后續(xù)需要優(yōu)化的.下面是一個月的每天告警情況,哪天的告警比較多,可以根據(jù)這天的情況分析一下,保障后面的類似故障不會發(fā)生.

工單平臺

因為業(yè)務發(fā)展比較迅速,所以業(yè)務需求還是比較個性化、多樣化的,當然還有比較緊急的.雖然我們有全生命周期管理來管理這一塊,但是我們跟他們還是有很多的溝通成本.所以我們就研發(fā)了這個工單平臺,工單平臺會把服務器所有流程放在里面,而且還有一些自定義的功能,可以減少我們我們跟開發(fā)之間的溝通成本,開發(fā)只需要在平臺提交需求,填寫完成后,流程到達下一節(jié)點,根據(jù)不通流程的設計特點,到達不通的節(jié)點,比如領導審核節(jié)點、業(yè)務資源池審核節(jié)點,最后由OP審核,實現(xiàn)業(yè)務的上線,上線的同時,cmdb的狀態(tài)和業(yè)務樹也會隨之發(fā)生變化,無需人為操作.這樣就可以減少人為溝通的一個成本,而且實現(xiàn)了生命周期管理自動化,并且流程方面也可以實現(xiàn)可視化、可追蹤的一個情況.

巡檢平臺

早期我們出現(xiàn)過內(nèi)核參數(shù)設置未生效的問題,iptables處于打開狀態(tài),導致宿主機在大流量和高并發(fā)量的情況下網(wǎng)卡容易丟包,影響多個業(yè)務的穩(wěn)定性.我們意識到在OS層,要做定制化和標準化,通過巡檢系統(tǒng)發(fā)現(xiàn)非標準機器,定時整改.

系統(tǒng)巡檢主要包括系統(tǒng)初始化檢測、系統(tǒng)常規(guī)檢測、系統(tǒng)內(nèi)核檢測、系統(tǒng)安全檢測和下線檢測.

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

更安全的堡壘機

我們建立這個更安全的堡壘的初衷也是線上發(fā)生了一些安全事故,比如用戶中心數(shù)據(jù)庫會拖走,win堡壘機密碼有失竊的情況,安全隱患還是很大的.我們基于以上這些需求做了更安全的堡壘機.

我們的堡壘機架構是在不同機房部署主備堡壘機,兩臺堡壘機之間的數(shù)據(jù)是同步的,用戶可以申請軟件或者硬件的Token,然后通過RSA認證登錄到堡壘機,此時IDC賬戶管理平臺會對登錄用戶進行審計把控,包括用戶管理、登錄記錄、分配權限、操作記錄等等,最后登錄到服務器上.

我們的堡壘機體系是通過RSA Token +堡壘機模式實現(xiàn)角色管理與授權審批、信息資源訪問控制、操作記錄和審計、系統(tǒng)變更和維護控制.避免了登錄賬號管理混亂、運維權限劃分不明、認證方式過于簡單、對運維過程沒有監(jiān)控措施、對研發(fā)人員的運維次數(shù)沒有合理的運維統(tǒng)計方式.

流程管理

在流程管理這塊,我們建立服務器生命周期管理.

服務器的引入、生產(chǎn)、運營、利舊、退役的生命周期閉環(huán),需要高效的自動化流程支撐.通過流程設計建立每個流程的模型,一般每個流程都要涉及到多個部門角色和系統(tǒng),需要確定關鍵環(huán)節(jié)、職責分工、系統(tǒng)間接口,為了降低流程開發(fā)成本,需要考慮原子流程-組合流程-業(yè)務流程的分級實現(xiàn)模式.

通過流程管理,我們各個團隊之間節(jié)省溝通時間想比較之前已大于兩倍,資產(chǎn)準確性100%.

容量系統(tǒng)

我們?nèi)萘肯到y(tǒng)的數(shù)據(jù)來自于監(jiān)控系統(tǒng),監(jiān)控系統(tǒng)會對服務器各個部件進行監(jiān)控,目前我們?nèi)萘肯到y(tǒng)服務器的計算能力,在服務器cpu、內(nèi)存、io、網(wǎng)絡能力中取最大值,算作服務器的高負載情況.對資源使用率較低的機器,我們會驅動業(yè)務進行資源整合、或者遷移業(yè)務至低配置的服務器中,或者遷移至docker中.

另外,我們也會做業(yè)務成本的考核.這里的業(yè)務成本考核是做一個幫襯作用,主要是一個營收平臺,我們做了一個內(nèi)部營收平臺,對內(nèi)的各個業(yè)務做一些核算來關注每一個業(yè)務的運營成本和產(chǎn)出.這樣每個部門的成本關注度也就提升了五倍.

三、系統(tǒng)運維未來的展望

最后是我們對未來的一個展望.其實魅族也希望內(nèi)外兼修,來打造精益化運營,根據(jù)運營場景設計串接各個自動化節(jié)點,逐漸形成自動化運營的場景閉環(huán).通過運維自動化、監(jiān)控自動化、安全管理、流程管理,來提高服務質量.同時我們也會協(xié)同開放平臺,大數(shù)據(jù)平臺,為我們的業(yè)務提供更優(yōu)質的服務.

文章來自微信公眾號：運維幫

轉載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4076.html