【51CTO.com原創(chuàng)稿件】運維能交付的價值不是背鍋，填坑和救火，主動應(yīng)對變化和風險是做好運維的一個重要能力。

魅族運維團隊通過構(gòu)建持續(xù)集成云端交付平臺提高應(yīng)對變化的能力，實現(xiàn)主動應(yīng)對變化提高效益的價值目標，向用戶以及產(chǎn)品團隊提供高效的交付體驗。通過這段自研歷程，希望能給大家?guī)硇﹩⑹尽?/p>

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

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

本次分享分為三個部分：

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

自動化建設(shè)歷程

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

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

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

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

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

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

發(fā)展給運維帶來的挑戰(zhàn)

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

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

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

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

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

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

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

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

運維平臺現(xiàn)狀

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

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

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

發(fā)布平臺演進

我們的發(fā)布平臺經(jīng)歷了周發(fā)布、日發(fā)布和自助發(fā)布三個發(fā)布歷程。由于業(yè)務(wù)剛開始時較簡單，我們當時采用的是手動方式。

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

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

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

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

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

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

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

交付流程

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

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

而我們在對生產(chǎn)環(huán)境進行運維時都會準備一些基礎(chǔ)性的環(huán)境，以提供給那些自動部署的服務(wù)進行各種日志的搜集、報警監(jiān)控、和應(yīng)用的快速擴容等。

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

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

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

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

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

首先我們的云平臺需要實現(xiàn)落地環(huán)境的自動化，這樣就可以保證我們所交付出去的環(huán)境都是標準化的。

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

交付流水線的一個核心原則就是：將標準化的流程自動化。我們在其中制定了較多的流程和規(guī)范，以實現(xiàn)一個可靠的、可重復(fù)的持續(xù)交付流水線。

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

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

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

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

標準化建設(shè)

我們的自動化分為三個階段，分別是標準化、自動化和智能化。

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

在測試自動化方面，我們會涉及到廣泛的內(nèi)容，包括：單元測試、單元覆蓋率、測試的準入準出條件，例如在交付的過程中，是否允許遺留一些 Bug 等。

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

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

最終我們選擇了第二個方案，當然在方案的實施過程中，由于需要對接的平臺較多，我們也遇到了不小的阻力。

鑒于這些平臺分散在 PMO、測試、運維等不同的部門，要打通這些部門，我們在開發(fā)的過程中就用到了不同的規(guī)范，例如：

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

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

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

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

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

自動化建設(shè)

我們再來看持續(xù)集成流程：

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

當然，我們也會進行一些手動的驗證，來檢查它是不是符合測試的準入標準。如果有問題的話，該流程就會被退回開發(fā)部門，需要他們重新提交代碼，并再執(zhí)行一次準入的流程。

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

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

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

下面我們再來看發(fā)布流程：

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

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

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

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

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

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

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

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

運維智能化

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

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

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

[[223522]]

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

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