【51CTO.com原創(chuàng)稿件】運(yùn)維能交付的價(jià)值不是背鍋，填坑和救火，主動(dòng)應(yīng)對(duì)變化和風(fēng)險(xiǎn)是做好運(yùn)維的一個(gè)重要能力。

魅族運(yùn)維團(tuán)隊(duì)通過(guò)構(gòu)建持續(xù)集成云端交付平臺(tái)提高應(yīng)對(duì)變化的能力，實(shí)現(xiàn)主動(dòng)應(yīng)對(duì)變化提高效益的價(jià)值目標(biāo)，向用戶以及產(chǎn)品團(tuán)隊(duì)提供高效的交付體驗(yàn)。通過(guò)這段自研歷程，希望能給大家?guī)?lái)些啟示。

2017 年 12 月 01 日-02 日，由 51CTO 主辦的 WOTD 全球軟件開發(fā)技術(shù)峰會(huì)在深圳中州萬(wàn)豪酒店隆重舉行。

本次峰會(huì)以軟件開發(fā)為主題，魅族資深架構(gòu)師古日旗在創(chuàng)新運(yùn)維探索專場(chǎng)與來(lái)賓分享"魅族持續(xù)集成云端交付之路"的主題演講，為大家?guī)?lái)魅族在運(yùn)維自動(dòng)化建設(shè)的探索以及實(shí)踐經(jīng)驗(yàn)。

本次分享分為三個(gè)部分：

• 自動(dòng)化建設(shè)歷程
• 持續(xù)集成及云端交付
• 展望運(yùn)維智能化

自動(dòng)化建設(shè)歷程

魅族持續(xù)集成的建設(shè)背景，如上圖：

• 2003 年到 2008 年，互聯(lián)網(wǎng) 1.0 時(shí)代。我們的互聯(lián)網(wǎng)業(yè)務(wù)還僅限于官網(wǎng)和 BBS，服務(wù)端即為 PHP + MySQL。
• 2009 年到 2011 年，互聯(lián)網(wǎng) 2.0 時(shí)代。我們這時(shí)有了真正意義上的服務(wù)端和運(yùn)維的工作，包括：LVS 的架構(gòu)模式和主從復(fù)制的數(shù)據(jù)庫(kù)設(shè)計(jì)。但是我們的各個(gè)業(yè)務(wù)仍然運(yùn)行在單個(gè) IDC 上。
• 2012 年到 2013 年，互聯(lián)網(wǎng) 2.5 時(shí)代。在互聯(lián)網(wǎng)業(yè)務(wù)方面，我們?cè)黾恿藨?yīng)用中心、多媒體、和 O2O 等。

在架構(gòu)方面，我們將主從復(fù)制的數(shù)據(jù)庫(kù)進(jìn)行了分庫(kù)、分表，和路由選擇。

在緩存方面，我們引入了 Redis 集群，并且增添了分布式的存儲(chǔ) MFS（MooseFS）。

與此同時(shí)，一些相應(yīng)的支撐服務(wù)也隨之出現(xiàn)，如搜索引擎、各種 MQ（Message Queue）等。

• 到了 2014 年，邁入互聯(lián)網(wǎng) 3.0 時(shí)代。這個(gè)時(shí)代一個(gè)重要的里程碑就是：我們的互聯(lián)網(wǎng)業(yè)務(wù)已經(jīng)成為了主營(yíng)業(yè)務(wù)之一。

發(fā)展給運(yùn)維帶來(lái)的挑戰(zhàn)

在從互聯(lián)網(wǎng) 1.0 到 3.0 的演變過(guò)程中，隨著業(yè)務(wù)的急速增長(zhǎng)，我們的運(yùn)維面對(duì)了各種挑戰(zhàn)，主要從質(zhì)量、效率、成本、安全四個(gè)方面來(lái)進(jìn)行解析。

質(zhì)量方面，衡量質(zhì)量的最佳方式是看它的可用性指標(biāo)。一般我們分為直接和間接兩種。

直接指標(biāo)，我們可以從監(jiān)控上看到網(wǎng)絡(luò)、服務(wù)、應(yīng)用、以及系統(tǒng)的可用性；間接指標(biāo)，我們可以對(duì)標(biāo)一些體驗(yàn)性的參數(shù)，比如說(shuō)運(yùn)行速度；也可以對(duì)標(biāo)一些業(yè)務(wù)上的參數(shù)，比如說(shuō)手機(jī)短信的到達(dá)率。

我們的業(yè)務(wù)可用性曾經(jīng)非常低，沒(méi)有一個(gè)完善的監(jiān)控體系。同時(shí)我們的監(jiān)控狀態(tài)也比較混亂，不但覆蓋率較低，而且經(jīng)常會(huì)造成一些誤報(bào)、漏報(bào)、錯(cuò)報(bào)等狀況。這些直接導(dǎo)致了整個(gè)監(jiān)控的不可相信。

效率方面，效率是衡量運(yùn)維平臺(tái)功能性的標(biāo)準(zhǔn)，主要體現(xiàn)為服務(wù)器的交付，線上的各種變更，以及我們對(duì)故障的及時(shí)發(fā)現(xiàn)水平。我們頻繁地交付和變更，卻沒(méi)有將流程與自動(dòng)化結(jié)合起來(lái)，因此整體效率低下。

成本方面，主要體現(xiàn)在業(yè)務(wù)的總體調(diào)度，和交付能力的改進(jìn)與優(yōu)化。由于我們的流程不完善、工作不透明，導(dǎo)致了某個(gè)業(yè)務(wù)到底需要多少容量完全無(wú)法評(píng)估。因此“填坑”、“救火”、“背鍋”就成了我們運(yùn)維的“家常便飯”。

安全方面，是整個(gè)互聯(lián)網(wǎng)產(chǎn)品的生命基線。所以在早期產(chǎn)品研發(fā)的過(guò)程中，我們就制定了一些安全的規(guī)范和制度。

隨后又建立了一套比較完善的安全體系，從而通過(guò)系統(tǒng)、數(shù)據(jù)和應(yīng)用等維度，來(lái)體現(xiàn)團(tuán)隊(duì)對(duì)于安全問(wèn)題的管控程度。

運(yùn)維平臺(tái)現(xiàn)狀

我們以價(jià)值為導(dǎo)向建立了一系列的系統(tǒng)。從功能上來(lái)看，主要分成以下幾個(gè)系統(tǒng)：

• 資源管理系統(tǒng)，我們通過(guò) KVM + Docker 建立了一個(gè)云平臺(tái)?；谠撛破脚_(tái)，我們組建了一個(gè)虛擬化計(jì)算與網(wǎng)絡(luò)的資源管理系統(tǒng)，并通過(guò) CMDB 進(jìn)行管控。
• 配置管理系統(tǒng)，我們擁有 LVS、CDN、DNS 等管理系統(tǒng)。同時(shí)我們對(duì)外開放了一些 API，這樣做的好處在于可以精細(xì)化其相應(yīng)的權(quán)限，從而實(shí)現(xiàn)所有的操作都能在我們的系統(tǒng)上得到管控。
• 自動(dòng)化系統(tǒng)，我們有工單、日志、發(fā)布、自研運(yùn)維通道、以及自動(dòng)巡檢系統(tǒng)。這些都能為運(yùn)維的交付和變更提供效率上的提升。
• 監(jiān)控和容量系統(tǒng)，我們有基礎(chǔ)監(jiān)控、自定義監(jiān)控、業(yè)務(wù)監(jiān)控、和容量系統(tǒng)。容量系統(tǒng)既可以幫我們?cè)u(píng)估某個(gè)業(yè)務(wù)到底需要多少資源，又可以針對(duì)該業(yè)務(wù)實(shí)現(xiàn)成本上的管控。
• 安全系統(tǒng)，我們所有的運(yùn)維都是通過(guò)堡壘機(jī)進(jìn)行登錄的。此舉可方便我們審計(jì)用戶的各種操作。

通過(guò)自研的 WAF 系統(tǒng)和漏洞管理系統(tǒng)，我們可以自主地發(fā)現(xiàn)攻擊和各個(gè)漏洞。然后進(jìn)一步將漏洞信息導(dǎo)入到漏洞管理平臺(tái)中，進(jìn)行迭代、修復(fù)、與跟蹤。

發(fā)布平臺(tái)演進(jìn)

我們的發(fā)布平臺(tái)經(jīng)歷了周發(fā)布、日發(fā)布和自助發(fā)布三個(gè)發(fā)布?xì)v程。由于業(yè)務(wù)剛開始時(shí)較簡(jiǎn)單，我們當(dāng)時(shí)采用的是手動(dòng)方式。

后來(lái)隨著業(yè)務(wù)的大幅增長(zhǎng)，手動(dòng)操作不得不被自動(dòng)化工具所取代。比如：我們用自動(dòng)化工具向服務(wù)器下發(fā)各種命令、腳本、以及任務(wù)。

這樣雖然解決了一些問(wèn)題，但是其整體的發(fā)布效率仍比較低下，而且成功率也不高。

針對(duì)此問(wèn)題，我們?cè)诎l(fā)布平臺(tái)將 CMDB 的“業(yè)務(wù)樹”與業(yè)務(wù)模塊進(jìn)行了關(guān)聯(lián)，并制定出了發(fā)布的一些相關(guān)規(guī)范和指標(biāo)，從而提升了發(fā)布的成功率和容錯(cuò)性。

為了把發(fā)布做得更為靈活，我們把權(quán)限下發(fā)到了各個(gè)業(yè)務(wù)部門，由各個(gè)業(yè)務(wù)部門的負(fù)責(zé)人來(lái)進(jìn)行審核。如此一來(lái)，我們的整個(gè)發(fā)布過(guò)程就不需要運(yùn)維的參與了。

我們來(lái)看當(dāng)前的發(fā)布平臺(tái)現(xiàn)狀。我們的特點(diǎn)是發(fā)布策略比較多，有自主發(fā)布、一鍵重啟、靜態(tài)文件發(fā)布等。

同時(shí)，支持的發(fā)布類型也比較多，常見的有 Jetty、task、chef、PHP、C++ 等。

如圖所示，我們發(fā)布的成功率一直都能保持在 98% 以上，而我們的自助發(fā)布率也是在持續(xù)增長(zhǎng)中。在發(fā)布的過(guò)程，我們有超過(guò) 90% 的業(yè)務(wù)不需要運(yùn)維的參與。

交付流程

我們的交付流程可分為開發(fā)、測(cè)試和生產(chǎn)三個(gè)環(huán)境。開發(fā)，是在本地編寫代碼，通過(guò)自測(cè)、然后再提交到頁(yè)面。

通過(guò) Jenkins 的打包，然后再到 WTS Redmine。這樣的測(cè)試就會(huì)進(jìn)行一次測(cè)試環(huán)境的部署，然后再進(jìn)行一些自動(dòng)或者手動(dòng)的驗(yàn)證。

而我們?cè)趯?duì)生產(chǎn)環(huán)境進(jìn)行運(yùn)維時(shí)都會(huì)準(zhǔn)備一些基礎(chǔ)性的環(huán)境，以提供給那些自動(dòng)部署的服務(wù)進(jìn)行各種日志的搜集、報(bào)警監(jiān)控、和應(yīng)用的快速擴(kuò)容等。

這里存在著一個(gè)微妙的平衡：它要求我們有一套比較完善的技術(shù)環(huán)境，而且負(fù)責(zé)自主框架的人員應(yīng)當(dāng)盡可能地穩(wěn)定。

這樣有利于我們擁有良好的文檔和技術(shù)上的沉淀。否則一旦該平衡被打破，如一些流程沒(méi)有被遵守、或是我們的相關(guān)人員出現(xiàn)離職、又或者我們的框架更新太快，都會(huì)導(dǎo)致整個(gè)交付變得不可完成。

那么在交付過(guò)程中，存在過(guò)哪些問(wèn)題呢？我們總結(jié)如下：

• 在質(zhì)量上，我們發(fā)現(xiàn)有些代碼未完成單元測(cè)試，我們需要統(tǒng)計(jì)其相應(yīng)的覆蓋率和 Bug 數(shù)量。
• 在效率上，自動(dòng)化部署、自動(dòng)化測(cè)試和自動(dòng)化構(gòu)建這些都服務(wù)分散在不同的職能部門，造成了“圍墻”未被打通，因此我們也無(wú)法做到精細(xì)化的運(yùn)營(yíng)。
• 溝通的成本高，交付變得很復(fù)雜。
• 我們的代碼是否安全，是否能通過(guò)安全測(cè)試，這些都需要予以解決。

那么我們追求的是一個(gè)什么樣的價(jià)值框架呢？如圖所示，最下面是一個(gè)開發(fā)框架平臺(tái)。

首先我們的云平臺(tái)需要實(shí)現(xiàn)落地環(huán)境的自動(dòng)化，這樣就可以保證我們所交付出去的環(huán)境都是標(biāo)準(zhǔn)化的。

其次是整體開發(fā)框架，我們的技術(shù)委員會(huì)持續(xù)推行基礎(chǔ)性的開發(fā)框架、及架構(gòu)，從而保證我們擁有一套基礎(chǔ)性的技術(shù)棧，和一個(gè)環(huán)境化的自動(dòng)化流程。

交付流水線的一個(gè)核心原則就是：將標(biāo)準(zhǔn)化的流程自動(dòng)化。我們?cè)谄渲兄贫溯^多的流程和規(guī)范，以實(shí)現(xiàn)一個(gè)可靠的、可重復(fù)的持續(xù)交付流水線。

該過(guò)程會(huì)包含許多的內(nèi)容，如：提交編譯階段的并行研發(fā)、編譯構(gòu)建、單元測(cè)試，以及驗(yàn)證階段的系統(tǒng)測(cè)試與集成測(cè)試。

最后是發(fā)布與運(yùn)維階段的生產(chǎn)交付，涉及到某個(gè)發(fā)布的回滾，以及后繼的生產(chǎn)監(jiān)控。這些過(guò)程都是在該流水線上完成的。

另外，該系統(tǒng)是一個(gè)多角色的平臺(tái)，上面會(huì)有一些負(fù)責(zé)開發(fā)的人員角色和一些運(yùn)維測(cè)試的人員進(jìn)行各種協(xié)調(diào)，使得該平臺(tái)對(duì)于我們整個(gè)團(tuán)隊(duì)都能受益。

持續(xù)集成及云端交付

標(biāo)準(zhǔn)化建設(shè)

我們的自動(dòng)化分為三個(gè)階段，分別是標(biāo)準(zhǔn)化、自動(dòng)化和智能化。

在標(biāo)準(zhǔn)化方面，我們有硬件的標(biāo)準(zhǔn)化、組件的標(biāo)準(zhǔn)化，和技術(shù)棧的標(biāo)準(zhǔn)化（例如我們所用到的協(xié)議類型），以及監(jiān)控的標(biāo)準(zhǔn)化。

在測(cè)試自動(dòng)化方面，我們會(huì)涉及到廣泛的內(nèi)容，包括：?jiǎn)卧獪y(cè)試、單元覆蓋率、測(cè)試的準(zhǔn)入準(zhǔn)出條件，例如在交付的過(guò)程中，是否允許遺留一些 Bug 等。

而在建設(shè)過(guò)程中曾有兩種可選的技術(shù)方案：

• 全開源，我們可以用 Docker 來(lái)進(jìn)行環(huán)境自動(dòng)化標(biāo)準(zhǔn)的相關(guān)操作，并且用 ES 來(lái)做日志系統(tǒng)。但是該方案對(duì)于我們現(xiàn)有系統(tǒng)的沖擊較大。
• 基于現(xiàn)有的各種平臺(tái)系統(tǒng)實(shí)踐，我們?cè)?CMDB、發(fā)布平臺(tái)上做出了一些規(guī)范及流程。

最終我們選擇了第二個(gè)方案，當(dāng)然在方案的實(shí)施過(guò)程中，由于需要對(duì)接的平臺(tái)較多，我們也遇到了不小的阻力。

鑒于這些平臺(tái)分散在 PMO、測(cè)試、運(yùn)維等不同的部門，要打通這些部門，我們?cè)陂_發(fā)的過(guò)程中就用到了不同的規(guī)范，例如：

• 在運(yùn)維處，發(fā)布平臺(tái)會(huì)涉及到與機(jī)房有關(guān)的規(guī)范，包括機(jī)房里面有哪些服務(wù)器，服務(wù)器上又有哪些業(yè)務(wù)，哪些服務(wù)器是灰度環(huán)境的，哪些服務(wù)器屬于生產(chǎn)環(huán)境等。這些都是通過(guò) CMDB 的業(yè)務(wù)樹來(lái)進(jìn)行運(yùn)營(yíng)的。
• 在開發(fā)處，開發(fā)人員可能會(huì)用到一些全開源的平臺(tái)，如 Jenkins。由于它是完全開源，且未經(jīng)改造過(guò)，那么其包含的各種運(yùn)營(yíng)規(guī)范和一些名字的標(biāo)識(shí)，是無(wú)法與我們的業(yè)務(wù)樹相對(duì)應(yīng)的。這些無(wú)不增加了改造的難度。

因此在該平臺(tái)建設(shè)中，我們的一種做法是統(tǒng)一入口。鑒于 Jenkins 是打包過(guò)的，我們完全可以調(diào)用 Jenkins 的 API，把該打包操作整合到自己的平臺(tái)之中。同時(shí)，我們把需求的信息也同步到了 Redmine。

此外，為了實(shí)現(xiàn)對(duì) Bug 的錄入和跟蹤，我們將 Bug 錄入的入口也整合到此平臺(tái)之上。

此舉既不會(huì)對(duì)我們前期操作造成大的沖擊，又解決了相互間需求與Bug數(shù)量相關(guān)聯(lián)的問(wèn)題。

最后由于它是一個(gè)多用戶的平臺(tái)，我們還需要把相關(guān)人員的信息（包括開發(fā)、測(cè)試、運(yùn)維等負(fù)責(zé)人）都錄入、且同步到該系統(tǒng)之中。

自動(dòng)化建設(shè)

我們?cè)賮?lái)看持續(xù)集成流程：

• 首先是需求階段，比如：我們的某個(gè)產(chǎn)品運(yùn)營(yíng)人員會(huì)把他的需求錄入到該系統(tǒng)中。隨后開發(fā)負(fù)責(zé)人就會(huì)對(duì)此需求進(jìn)行分析或預(yù)演，評(píng)估出一個(gè)交付的日期。
• 然后進(jìn)入開發(fā)階段，包括編寫代碼、提交代碼、以及編譯構(gòu)建。在構(gòu)建的時(shí)候還會(huì)進(jìn)行一些靜態(tài)的掃描，同時(shí)涉及到代碼的覆蓋率。
• 而在測(cè)試階段，系統(tǒng)又會(huì)進(jìn)行一次測(cè)試環(huán)境的部署，同時(shí)進(jìn)行一些自動(dòng)化的測(cè)試，其中包括各種安全測(cè)試和性能測(cè)試。

當(dāng)然，我們也會(huì)進(jìn)行一些手動(dòng)的驗(yàn)證，來(lái)檢查它是不是符合測(cè)試的準(zhǔn)入標(biāo)準(zhǔn)。如果有問(wèn)題的話，該流程就會(huì)被退回開發(fā)部門，需要他們重新提交代碼，并再執(zhí)行一次準(zhǔn)入的流程。

• 如果該階段沒(méi)有問(wèn)題的話，開發(fā)負(fù)責(zé)人或者業(yè)務(wù)運(yùn)維人員就開始進(jìn)行發(fā)布的審核，并且把代碼發(fā)布到灰度環(huán)境之中。

在灰度環(huán)境里，我們同樣需要做一些自動(dòng)化的測(cè)試，以檢查該服務(wù)的安全性。只有達(dá)到其接口通過(guò)率，我們才能最后發(fā)布到生產(chǎn)環(huán)境中。

可見，從項(xiàng)目需求到發(fā)布的整個(gè)階段，我們都是在自己的平臺(tái)上進(jìn)行操作的，整個(gè)交付流程實(shí)現(xiàn)了細(xì)粒度的進(jìn)度管理。

下面我們?cè)賮?lái)看發(fā)布流程：

• 首先是環(huán)境檢查，這里主要檢查服務(wù)器上是否有一系列的用戶目錄，以及一些相關(guān)的權(quán)限。
• 同時(shí)，我們會(huì)從打包平臺(tái)將文件拉取到 IDC 處。
• 然后需要關(guān)閉監(jiān)控。因?yàn)樵谠摲?wù)的部署過(guò)程中，會(huì)有短暫的不可用，進(jìn)而會(huì)引發(fā)監(jiān)控的報(bào)警；所以我們會(huì)針對(duì)相應(yīng)的服務(wù)器進(jìn)行監(jiān)控的關(guān)閉。
• 當(dāng)然也要將 Web 下線，從而使得新的流量不再涌入。
• 隨后便是停止服務(wù)，以確保該文件不會(huì)被占用。
• 我們進(jìn)行更新文件操作。
• 我們?cè)谏鲜鲞^(guò)程完成之后再啟動(dòng)服務(wù)。
• 而在啟動(dòng)服務(wù)之后，我們還需進(jìn)行監(jiān)控檢查。該檢查的主要目的是為了保證我們更新上去的服務(wù)為可用的。
• 隨后就是 Web 上線，我們把服務(wù)加入到 LVS 的集群之上。
• 最后再開啟監(jiān)控。

在上述發(fā)布的過(guò)程中，我們會(huì)針對(duì)業(yè)務(wù)的某些特點(diǎn)進(jìn)行并行或者串性的發(fā)布。這樣在能夠保證成功率的前提下，也能夠進(jìn)一步地提升我們的發(fā)布效率。

有了該持續(xù)交付平臺(tái)之后，我們就可以用它來(lái)支撐互聯(lián)網(wǎng)常見的、急速迭代的產(chǎn)品研發(fā)模式。

我們既可以實(shí)現(xiàn)迭代前的需求計(jì)劃，又能保證迭代中的開發(fā)、測(cè)試和發(fā)布，以及迭代后的回顧。

通過(guò)收集信息和數(shù)據(jù)，我們可以看到：系統(tǒng)在代碼質(zhì)量上有沒(méi)有出現(xiàn)過(guò)嚴(yán)重的問(wèn)題，有沒(méi)有發(fā)生阻塞的情況。

另外，Bug fix 的情況也是一目了然。我們還可以獲取代碼的覆蓋率，代碼測(cè)試的通過(guò)率，性能測(cè)試、安全測(cè)試和接口測(cè)試的數(shù)據(jù)。

同時(shí)，我們不但能夠獲知編譯的通過(guò)率、發(fā)布的成功率，還能夠獲取其他與效率相關(guān)的數(shù)據(jù)。

這些質(zhì)量數(shù)據(jù)可以驅(qū)動(dòng)和提升我們的技術(shù)能力，保證系統(tǒng)在上線前的質(zhì)量。當(dāng)然我們也可以利用這些數(shù)據(jù)來(lái)進(jìn)一步地完善和優(yōu)化交付流程，以確保交付過(guò)程的可靠。

運(yùn)維智能化

回顧上述自動(dòng)化建設(shè)的三個(gè)階段，我們可以發(fā)現(xiàn)：運(yùn)維智能化主要是通過(guò)搜集數(shù)據(jù)來(lái)進(jìn)行學(xué)習(xí)，并實(shí)現(xiàn)分析和預(yù)測(cè)的目的。

例如：搜集的數(shù)據(jù)如果顯示近期磁盤的換盤率比較高，那么我們就能預(yù)測(cè)到該磁盤下一次可能出故障的時(shí)間。

同時(shí)，我們還能進(jìn)一步預(yù)測(cè)那些可能導(dǎo)致數(shù)據(jù)中心全面癱瘓的關(guān)鍵交換機(jī)的出錯(cuò)點(diǎn)。

[[223522]]

古日旗，曾工作于金山和奇虎 360，參與過(guò)快盤、天擎等項(xiàng)目，2015 年加入魅族，現(xiàn)任職魅族科技運(yùn)維架構(gòu)師，負(fù)責(zé)運(yùn)維自動(dòng)化平臺(tái)建設(shè)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】