轉化 可用 做到 流程 登錄 成了 cmd 軟件 開發階段

本篇文章內容來自第10期魅族開放日魅族運維架構師林鐘洪的現場分享。
編輯：Cynthia

一、自動化建設歷程
1.1 魅族互聯網發展的時間線

2003-2008年被稱之為“互聯網1.0時代”。2003年，源於對音樂的夢想，魅族成立。2006年，魅族成為中國音樂播放器第一品牌，主營業務是MP3，當時其互聯網業務只有官網和BBS，這部分業務單個IDC就搞定了。
2009-2011年被稱之為“互聯網2.0時代”。2008年，魅族發布M8智能手機，並將業務從音樂播放器轉移到手機業務上，互聯網業務除了原來的官網和BBS之外，還增加了雲端服務。從這個時候起，魅族有了真正意義上的開發、運維。數據庫也有了主從的拷貝，但業務運行還是在單個IDC上。

2012-2013年被稱之為“互聯網2.5時代”。2011年魅族發布M9手機，開始進軍安卓平臺，互聯網主要功能是對手機部件的更新和應用叠代。互聯網業務擴展到官網、BBS以外的電商、微博、微信等活動，架構方面有了數據庫的分布、分表、路由，緩存上有了Redis集群，以及分布式存儲MFS。
2014年以後進入“互聯網3.0+時代”。我們的主要業務有遊戲中心、應用中心、多媒體、O2O等。這個時期有一個比較重要的標識：魅族互聯網業務成為主營業務之一。

1.2 發展給運維帶來的挑戰

隨著互聯網1.0-3.0的演變，我們的業務也在快速增長。業務的急速增長給運維帶來了許多挑戰。

● 質量上：我們踩過很多坑，包括硬件和架構方面。業務可用性低，監控體系不完善，監控混亂，覆蓋率低，經常出現漏報、誤報、錯報，監控變的不可信。
● 效率上：變更多，交付多，沒有把流程和自動化結合起來，效率低下。
● 成本上：工作不透明，沒有一個容量評估體系來幫助我們評估每一個業務需要多少容量。
● 在這種情況下，運維填坑、救火、背鍋是常事。
如何實現運維價值，改變這種現狀成為首要目標。我們實踐主要從效率、安全、質量和成本四個方面來體現。
● 質量方面最好的體現方式就是可用性。可用性指標很多，有直接的和間接的：直接的從監控上可以得到系統可用性、服務可用性、應用程序可用性等；間接的可以對標一些體驗性指標，比如速度，也可以對標一些業務上的指標，比如手機短信到達率。
● 效率方面主要是服務器的交付、線上的變更，以及積極發現故障等。
● 成本方面是主要針對業務整體的調度和交付能力進行優化改進。
● 安全是互聯網重要的基石，在安全方面我們定制了一些策略和規範。
對應這四個維度，我們有四個支撐團隊：質量方面有運維優化團隊、效率方面有運維開發團隊、成本方面有運維基礎團隊、安全方面有運維安全團隊。

1.3運維平臺現狀

同時我們也開發了一些系統，從功能上來看有資源管理系統、配置管理系統、自動化系統、監控系統與容量和安全系統。如圖所示。
● 資源管理系統，我們通過KVM、Docker建立了一個雲平臺，基於雲平臺組成虛擬計算和網絡的資源管理系統，通過CMDB進行管控；
● 配置管理系統，我們建立了LVS、CDN和DNS管理系統，對應開發一些API。這樣做的好處是我們可以精細化權限，集中在一個平臺上做管控；
● 自動化管理系統包括工單、日誌、發布系統，自研運維通道和自動巡檢系統。這些都給運維的交付和變更帶來了效率上的提升；
● 監控方面我們建立了基礎監控、自定義監控、業務監控和容量系統。容量系統可以幫助我們評估一個業務用了多少資源、容量如何；
● 我們有一個堡壘機，所有運維登錄都要在堡壘機上做一個管控，這樣可以審計用戶操作。我們還自研了一個可以自動發現漏洞的平臺——WAF系統，能夠把漏洞轉化到漏洞管理平臺，在上面進行叠代和修復。

1.4 發布平臺演進

我們的發布平臺經歷了周發布、日發布和自主發布的發展歷程。一開始我們的業務比較簡單，發布是通過人力來實現的，後來業務越來越多，人力無法達到，就出現了一些自動化工具，可以向服務器下發腳本或命令、任務等。這樣做可以解決一部分問題，但整體發布效率和成功率還是非常低的，而且還可能存在一些人為的誤操作。
在發布平臺上，我們結合業務樹和業務模塊做了一些規範和標準，有效地提升了發布成功率和容錯性。為了使發布更加靈活，我們把審核權限下發到業務，由業務負責人進行審核，整個發布流程不再需要業務運維參與其中。

我們的發布有一些特點，比如發布策略多，有組發布、自助發布、一鍵重啟、靜態文件發布等；發布類型也很多，包括常用的Jetty、PHP、C++等。經過演進，我們的發布成功率一直保持在98%以上，自助發布率也在穩步上漲，可以看到大概有90%的業務在叠代發布過程中是不需要運維參與的。

1.5 交付流程

我們的交付流程大概分為生產、測試、開發三個環境。
● 開發人員開發代碼並在本地自測
● 提交代碼到Git，通過 Jenkins打包，進行一些靜態掃描並在redmin上填寫測試單；
● 測試人員自動或者手動驗證用例；
● 運維人員準備基礎環境，提供自動部署服務、並進行日誌收集、報警監控、應用快速擴容。
這是一個微妙的平衡，這種平衡要求我們有一套完善的技術棧和環境，團隊技術框架和人員也要盡可能的穩定，這種情況下，是沒有什麽問題的，但是如果這個平衡被打破了，比如有一些流程沒有被遵守，或者說有一些相關的人員離職、我們的架構變化的比較快，這個時候整個平衡就會被打破，交付變得不可完成。

1.6交付中存在的問題

交付過程中存在哪些問題呢？
首先是質量，我們通過代碼的質量跟蹤可以看到它有沒有通過單元測試、覆蓋率如何、Bug數如何；其次是效率，我們有自動化部署、自動化測試、自動化構建，但這些分布在不同的部門，沒有和流程打通，這就造成第三個問題：溝通成本高，交付復雜。最後還可能有安全問題，比如代碼夠不夠安全、有沒有經過安全測試等。

1.7 我們追求的價值

我們追求的是價值交付，這也是魅族持續交付平臺建設的指引。
首先在最底層是一些開發框架，雲平臺能保證我們環境，保證交付所有的系統都是標準化的，
開發架構這裏有技術委員會定義和推廣的一系列基礎服務和架構，這就保證了有一套基礎的技術棧和環境自動化的流程。
持續交付流水線的核心原則是把一些標準化的流程自動化。過程當中有提測和編譯階段，有並行的研發、編譯構建、單元測試；在測試與驗證階段有環境部署、系統測試、集成測試；在發布與運維階段有生產交付、發布和生產監控等，這一系列過程都可以在這個流水線上完成。這個系統是多用戶的，支持開發、運維、測試進行協調操作，這樣對整個團隊的協作也起到了促進作用。

二、持續交付平臺

2.1 演進-標準化
自動化平臺的演進分為標準化、自動化、智能運維三個階段。

標準化方面包括監控標準化、應用監控標準化、技術棧標準化（其中用了什麽協議）、硬件標準化、質量標準化等。自動化主要是測試自動化，在測試階段包括的東西更多，比如單元測試、通過率及測試的準入準出條件（是不是允許一些bug）等。

2.2 演進-技術選型

我們在建立持續交付平臺的過程中有兩個方案：
第一種，全開源的方案，我們可以用docker做環境自動化的標準的東西，我們的日誌可以使用ES，這種方案可能對我們現有的系統的沖擊比較大，我們要使用一套全新的東西。
第二種，基於現有系統自建。基於我們現有的雲平臺加上我們的一些發布平臺這些東西進行規範和標準。
我們選擇了基於現有系統自建的方案，對我們來說阻力比較大。
首先我們需要對接很多系統，這些系統分散在各個職能部門，有PMO、測試、運維等，要推動這些不同的職能部門和相關的人員做出改變，阻力是非常大的；
其次，我們現有的一些系統，在開發的時候可能用了不同的規範，像我們的運維這邊發布平臺可能都會有規範，比如每個機房有哪些服務器，服務器上跑了什麽模塊，哪些機器有生產環境，都是基於我們的業務樹來運行。
但是開發這邊使用的各個平臺都是全開源的，比如之前使用的jekins都是全開源的，完全就沒有進行改造，這個時候就會有問題，它裏面的名字之類的標識完全都是自定義的，很難和我們的業務樹對應起來，想改造確實是比較麻煩。

2.3 演進-統一入口

在持續平臺中首先要有一個統一入口，像前面提到的Jenkins，用來打包，我們可以調用它的API，打包之後植入到系統中。
還有之前做的需求管理、bug跟蹤的信息，我們會把這些信息錄入到系統中，一旦得到一些信息我們就可以知道一個需求遺留吧多少個bug、修復情況如何。
另外，這是一個多用戶系統，我們還要把這些系統人員同步到系統當中，把他們信息都錄入進去。

2.4 持續集成流程

如圖所示，持續集成的流程是：首先把需求列入到需求階段，開發負責人對這些需求進行評估和預測，評估出一個叠代日期；然後進入開發階段，開發代碼，提交代碼然後到編譯；編譯進行靜態掃描，這當中包含代碼的覆蓋率；然後到測試階段，把代碼部署到測試環境，進行代碼測試，包括安全性測試、性能測試，有時還會做一些人工驗證，如果有問題流程會被打回，開發人員重新提交代碼，重新走一遍準入流程，如果沒有問題就進入到生產階段；開發負責人或者運維人員進行審核，通過審核之後，會先把代碼發布到灰度環境，用自動化的程序來驗證它的安全性是怎麽樣，接口通過率怎麽樣，如果都沒有問題才會放到生產發布。從需求到發布的階段，整個它的工作流程或者生命周期的管理都會在這一個平臺上進行管控，整個交付流程就有一個可視化的進度管理。

2.5 發布流程

我們單獨看一下發布流程，
第一步，環境監測，包括我們發布的服務器上相關的環境，比如它的用戶是不是存在，目錄是不是存在，還有相關的權限；
第二步，文件拉取，從打包平臺拉取要發布的包；
第三步，關閉監控，我們都知道發布的時候可能會造成短暫的服務不可用，或者發布期間不會有誤報，那麽我們可能會針對發布的機器做一些關閉監控的操作；
第四步，web下線，保證沒有流量進來；
第五步，停止服務，保證文件不被訪問占用；
第六步，更新文件，對文件進行更新；
第七步，啟動服務，恢復web服務；
第八步，健康檢查，根據健康檢測我們能確定並保證我們的服務運行正常；
第九步，web上線，健康檢測以後我們會把我們的web服務加入IOS集群上；
第十步，開啟監控，最後總的發布就完成。
發布的時候，我們因應業務環境可使用串行發布和並行發布，這樣在保證我們發布的成功率的前提下，也能提升發布效率。

2.6 產品研發模式

有了持續交付平臺就能保證滿足互聯網研發的模式，比如經常被用到的極速叠代，在平臺上可以滿足叠代性的需求還有叠代後的回顧。

2.7 數據驅動

完成了這些以後我們會有價值數據的驅動和輸出，首先這裏會有幾方面的數據，在代碼的一些規範性上面，可以知道嚴重問題是多少、阻隔問題有多少，在代碼的可讀性上，有重復率，還有一些接口和單元測試，單元測試的覆蓋率怎麽樣，通過率怎麽樣，還有性能測試的一些數據，安全測試的一些數據，甚至我們的人員構建的成功率之類的，還有發布的一些成功率，還有發布的效率。這樣就可以知道一個項目它從開始到現在它所有的質量數據的變化，通過這些質量數據的驅動能提升技術的能力，把系統上線前質量是OK的，當然我們還可以根據這些數據來考核我們的相關的子系統。

三、展望運維智能化

回頭看一下我們平臺的三個階段，標準化、自動化、智能化，智能運維是根據收集上來的數據進行學習，從而達到預測和分析的目的。
這裏我們最常見的就是預測和分析，比如根據我們的預報數據的統計說我們最近硬盤的換盤率特別高，這樣是不是可以預測一下我們的數據硬盤什麽時候損壞。
其次還有可以根據一些數據進行效率上的提升，比如說像故障方面，在故障的發現和定位上有一個比較有力的支持，或者達到故障預測。
還有就是數據中心的故障的預測，因為這個東西在當時肯定是全癱瘓了，那麽像這種故障能否做到事前的預測，這就是我們現在要解決或者想進一步解決的一些問題。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峰會，魅族科技主題桌面負責人譚林英將分享《手機廠商如何做互聯網產品》。
TOP100全球軟件案例研究峰會已舉辦六屆，甄選全球軟件研發優秀案例，每年參會者達上2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿裏、百度等一線互聯網企業的最新研發實踐。

更多TOP100案例信息及日程請前往官網查閱。4天時間集中分享2017年最值得學習的100個研發案例實踐。本平臺共送出10張開幕式單天免費體驗票，數量有限，先到先得。
免費體驗票申請入口：www.top100summit.com/?qd=juejin

TOP100summit 2017：【案例分享】魅族持續交付平臺建設實踐