很高興能在這兒跟大家做一個分享和交流。我叫樑鵬，來自魅族雲平臺，主要是負責魅族系統運維、平臺建設和自動化的工作。很感謝聽雲邀請我過來，今天我分享的主題主要是魅族基礎系統架構運維之路，主要分三個方面給大家做介紹：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的操作人員協助我們做一些管理和操作，另外，我們還會通過帶外的管理口對伺服器做一些操作，對系統進行重灌。我們還有一些自動化的指令碼，在自動監控方面早期部署了NagiosCacti，主要是來監控系統穩定性，網路以及業務穩定性。在架構單點方面，主要還是靠人為來驅動，主要是推動業務部署高可用架構，提高業務的可用性這樣的一個解決方案。

石器時代

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

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

1、這個時代機房還存在著很多IBM的刀箱、EMC的儲存，這就不符合網際網路的思維了，另外運維成本也是非常高的，在虛擬化方面我們使用的是VMwarevSphere解決方案，管理和運維都給我們帶來很多的成本，而且這一套解決方案的成本還是比較高的。面對這個問題我們是怎麼解決的？其實我們跟大多數的網際網路公司一樣，逐步的使用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，定時對線上運營中的機器做一個巡檢，巡檢到未加監控的機器就會定時給相關人員郵件通知來解決監控覆蓋率低的問題。

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

青銅時代

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

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

1、線上伺服器的標準化率低，比如系統層未做標準化，比如yum源未標準化，這樣就可能會造成一些安裝軟體的相容性問題或者一些其他的問題，我們對於標準化，主要也是從幾個維度來做的，比如系統標準化方面，統一yum源伺服器，其他的還有軟體標準化、元件標準化、硬體標準化等等。在系統標準化方面，我們開發了巡檢平臺，主要從系統常規、系統安全、系統核心等幾個維度定時進行巡檢，對出現問題的機器進行整改，確保線上標準化覆蓋率100%。

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

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

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

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

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

鐵器時代

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

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

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

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

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

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

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

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

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

這6點大部分在發展歷程中已經詳細講解了，這裡在抽出兩個描述一下：

一個就是基礎設施的規劃，從遠古時代到鐵器時代，這個業務突飛猛進的發展，伺服器從5臺到6000臺，網路架構也升級到3.0，這就很考驗基礎設施的建設。另外一個是很考驗交付效率能力，我們使用裝機平臺來安裝系統，並使用工單系統聯動CMDB平臺，降低我們的操作，提高工作效率。

另外一個就是成本控制方面，其實在一個海量網際網路業務的公司來說，稍微優化就可以節省很多成本，此時控制成本也稱為一項勢在必行的工作。

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

二、運營現狀

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

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

監控系統

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

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

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

統一告警平臺

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

在統一告警平臺中配置服務的匹配策略和故障合併，當告警資訊從zabbix生成後，通過預先設定的指令碼傳送給告警平臺，在觸發策略，最後故障合併後，在觸發告警升級策略，即告警首先接收人，如10分鐘沒處理，則升級給團隊處理。

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

工單平臺

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

巡檢平臺

早期我們出現過核心引數設定未生效的問題，iptables處於開啟狀態，導致宿主機在大流量和高併發量的情況下網絡卡容易丟包，影響多個業務的穩定性。我們意識到在OS層，要做定製化和標準化，通過巡檢系統發現非標準機器，定時整改。

系統巡檢主要包括系統初始化檢測、系統常規檢測、系統核心檢測、系統安全檢測和下線檢測。

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

更安全的堡壘機

我們建立這個更安全的堡壘的初衷也是線上發生了一些安全事故，比如使用者中心資料庫會拖走，win堡壘機密碼有失竊的情況，安全隱患還是很大的。我們基於以上這些需求做了更安全的堡壘機。

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

我們的堡壘機體系是通過RSA Token +堡壘機模式實現角色管理與授權審批、資訊資源訪問控制、操作記錄和審計、系統變更和維護控制。避免了登入賬號管理混亂、運維許可權劃分不明、認證方式過於簡單、對運維過程沒有監控措施、對研發人員的運維次數沒有合理的運維統計方式。

流程管理

在流程管理這塊，我們建立伺服器生命週期管理。

伺服器的引入、生產、運營、利舊、退役的生命週期閉環，需要高效的自動化流程支撐。通過流程設計建立每個流程的模型，一般每個流程都要涉及到多個部門角色和系統，需要確定關鍵環節、職責分工、系統間介面，為了降低流程開發成本，需要考慮原子流程-組合流程-業務流程的分級實現模式。

通過流程管理，我們各個團隊之間節省溝通時間想比較之前已大於兩倍，資產準確性100%。

容量系統

我們容量系統的資料來自於監控系統，監控系統會對伺服器各個部件進行監控，目前我們容量系統伺服器的計算能力，在伺服器cpu、記憶體、io、網路能力中取最大值，算作伺服器的高負載情況。對資源使用率較低的機器，我們會驅動業務進行資源整合、或者遷移業務至低配置的伺服器中，或者遷移至docker中。

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

三、系統運維未來的展望

最後是我們對未來的一個展望。其實魅族也希望內外兼修，來打造精益化運營，根據運營場景設計串接各個自動化節點，逐漸形成自動化運營的場景閉環。通過運維自動化、監控自動化、安全管理、流程管理，來提高服務質量。同時我們也會協同開放平臺，大資料平臺，為我們的業務提供更優質的服務。

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