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

持續(xù)集成的構(gòu)建背景，如上圖：

在架構(gòu)上，我們將主從數(shù)據(jù)庫(kù)分為分庫(kù)、分表、路由選擇。

在緩存方面，我們引入了Redis集群，增加了分布式存儲(chǔ)MFS()。

同時(shí)也出現(xiàn)了一些相應(yīng)的配套服務(wù)，如搜索引擎、各種MQ（Queue）等。

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

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

就質(zhì)量而言，衡量質(zhì)量的最佳方法是查看其可用性指標(biāo)。 一般我們可以把它分為直接的和間接的。

直接指標(biāo)，我們可以從監(jiān)控中看到網(wǎng)絡(luò)、服務(wù)、應(yīng)用、系統(tǒng)的可用性； 間接指標(biāo)，我們可以對(duì)一些經(jīng)驗(yàn)參數(shù)進(jìn)行基準(zhǔn)測(cè)試，比如跑步速度； 我們還可以對(duì)一些業(yè)務(wù)參數(shù)進(jìn)行，比如說手機(jī)短信的到達(dá)率。

我們的業(yè)務(wù)可用性曾經(jīng)很低，沒有完整的監(jiān)控系統(tǒng)。 同時(shí)，我們的監(jiān)控狀態(tài)也比較混亂，不僅覆蓋率低，還經(jīng)常造成一些誤報(bào)、漏報(bào)、漏報(bào)等情況。 這些直接導(dǎo)致了整個(gè)監(jiān)控的不可信。

在效率方面，效率是衡量運(yùn)維平臺(tái)功能好壞的標(biāo)準(zhǔn)，主要體現(xiàn)在服務(wù)器的交付，線上的各種變化，以及我們對(duì)故障的及時(shí)發(fā)現(xiàn)。 我們?cè)跊]有將流程與自動(dòng)化集成的情況下頻繁交付和更改，導(dǎo)致整體效率低下。

在成本方面，主要體現(xiàn)在業(yè)務(wù)的統(tǒng)籌調(diào)度和交付能力的提升和優(yōu)化上。 由于我們不完善的流程和不透明的工作，無法預(yù)估某個(gè)業(yè)務(wù)需要多少容量。 于是，“填坑”、“救火”、“背鍋”成了我們運(yùn)維的“家常便飯”。

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

隨后，建立了較為完善的安全體系，從系統(tǒng)、數(shù)據(jù)、應(yīng)用三個(gè)維度體現(xiàn)團(tuán)隊(duì)對(duì)安全問題的把控。

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

我們建立了一系列基于價(jià)值的體系。 從功能上看，主要分為以下幾個(gè)系統(tǒng)：

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

發(fā)布平臺(tái)的演變

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

后來隨著業(yè)務(wù)的大幅增長(zhǎng)，不得不用自動(dòng)化工具來代替人工操作。 例如：我們使用自動(dòng)化工具向服務(wù)器發(fā)送各種命令、腳本和任務(wù)。

這樣雖然解決了一些問題，但是整體發(fā)布效率還是比較低服務(wù)器運(yùn)維，成功率不高。

針對(duì)這個(gè)問題，我們將CMDB“業(yè)務(wù)樹”與發(fā)布平臺(tái)上的業(yè)務(wù)模塊關(guān)聯(lián)起來，制定了一些相關(guān)的發(fā)布規(guī)范和指標(biāo)，從而提高了發(fā)布的成功率和容錯(cuò)性。

為了讓發(fā)布更加靈活，我們把權(quán)限下放到了各個(gè)業(yè)務(wù)部門，由各個(gè)業(yè)務(wù)部門的負(fù)責(zé)人來審核。 這樣我們整個(gè)發(fā)布過程就不需要運(yùn)維的參與了。

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

同時(shí)支持的發(fā)布類型有Jetty、task、chef、PHP、C++等多種。

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

發(fā)貨流程

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

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

我們?cè)谶\(yùn)維生產(chǎn)環(huán)境的時(shí)候，會(huì)準(zhǔn)備一些基礎(chǔ)環(huán)境，為各種日志采集、告警監(jiān)控、應(yīng)用的快速擴(kuò)展等提供那些自動(dòng)部署的服務(wù)。

這里有一個(gè)微妙的平衡：要求我們有一個(gè)比較完善的技術(shù)環(huán)境，負(fù)責(zé)自治框架的人要盡可能穩(wěn)定。

這有助于我們有很好的文檔和技術(shù)沉淀。 否則，一旦平衡被打破，比如有些流程沒有被遵循，或者我們相關(guān)人員離職，或者我們的框架更新太快，整個(gè)交付就會(huì)變得無法接受。

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

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

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

二是整體發(fā)展框架。 我們技術(shù)委員會(huì)持續(xù)推進(jìn)基礎(chǔ)開發(fā)框架和架構(gòu)，確保我們有基礎(chǔ)的技術(shù)棧和環(huán)境化的自動(dòng)化流程。

交付管道的核心原則是自動(dòng)化標(biāo)準(zhǔn)化流程。 我們?cè)谄渲虚_發(fā)了更多的流程和規(guī)范，以實(shí)現(xiàn)可靠和可重復(fù)的持續(xù)交付流水線。

這個(gè)過程會(huì)包含很多內(nèi)容，比如：編譯階段提交并行開發(fā)，編譯構(gòu)建，單元測(cè)試，驗(yàn)證階段進(jìn)行系統(tǒng)測(cè)試和集成測(cè)試。

最后是發(fā)布和運(yùn)維階段的生產(chǎn)交付，涉及一個(gè)發(fā)布的回滾和后續(xù)的生產(chǎn)監(jiān)控。 這些過程都是在管道上完成的。

另外，系統(tǒng)是一個(gè)多角色的平臺(tái)，上面會(huì)有一些負(fù)責(zé)開發(fā)的人員，一些運(yùn)維測(cè)試人員進(jìn)行各種協(xié)調(diào)，讓平臺(tái)讓我們整個(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)化方面，我們涵蓋的內(nèi)容比較廣泛，包括：?jiǎn)卧獪y(cè)試，單元覆蓋率，以及測(cè)試的進(jìn)入和退出條件，比如在交付過程中是否允許保留一些bug。

在施工過程中，有兩種可選的技術(shù)方案：

最終，我們選擇了第二種方案。 當(dāng)然，在計(jì)劃實(shí)施過程中，由于需要對(duì)接的平臺(tái)數(shù)量眾多，我們也遇到了很大的阻力。

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

所以在這個(gè)平臺(tái)的建設(shè)中，我們的一個(gè)方法就是統(tǒng)一入口。 既然打包好了，我們就可以調(diào)用API將打包操作集成到自己的平臺(tái)中。 同時(shí)，我們也同步了需要的信息。

另外，為了實(shí)現(xiàn)Bug的記錄和跟蹤，我們還將Bug記錄的入口集成到這個(gè)平臺(tái)中。

此舉不會(huì)對(duì)我們前期的運(yùn)營(yíng)造成太大的影響，同時(shí)也解決了相互需求和bug數(shù)量的關(guān)系問題。

最后，由于是多用戶平臺(tái)，我們還需要將相關(guān)人員（包括開發(fā)、測(cè)試、運(yùn)維等）的信息錄入并同步到系統(tǒng)中。

自動(dòng)化施工

我們?cè)倏匆幌鲁掷m(xù)集成的過程：

當(dāng)然，我們也會(huì)進(jìn)行一些人工驗(yàn)證，檢查是否符合測(cè)試的錄取標(biāo)準(zhǔn)。 如果有問題服務(wù)器運(yùn)維，流程會(huì)返回給開發(fā)部門，要求他們重新提交代碼，重新執(zhí)行準(zhǔn)入流程。

在灰度環(huán)境下，我們還需要做一些自動(dòng)化測(cè)試來檢查服務(wù)的安全性。 只有它的接口通過率達(dá)到了，我們才能最終發(fā)布到生產(chǎn)環(huán)境。

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

我們?cè)倏纯窗l(fā)布過程：

在上述的發(fā)布過程中，我們會(huì)根據(jù)業(yè)務(wù)的某些特點(diǎn)進(jìn)行并行或串行發(fā)布。 這樣在保證成功率的前提下，可以進(jìn)一步提高我們的發(fā)布效率。

有了這個(gè)持續(xù)交付平臺(tái)，我們就可以用它來支撐互聯(lián)網(wǎng)通用的、快速迭代的產(chǎn)品開發(fā)模型。

既能實(shí)現(xiàn)迭代前的需求規(guī)劃，又能保證迭代中的開發(fā)、測(cè)試和發(fā)布，以及迭代后的評(píng)審。

通過收集信息和數(shù)據(jù)，我們可以看到系統(tǒng)是否存在嚴(yán)重的代碼質(zhì)量問題，是否存在堵塞。

此外，bug修復(fù)的狀態(tài)也一目了然。 我們還可以獲得代碼覆蓋率、代碼測(cè)試通過率、性能測(cè)試、安全測(cè)試和接口測(cè)試數(shù)據(jù)。

同時(shí)，我們不僅可以知道編譯通過率和發(fā)布成功率，還可以獲得其他與效率相關(guān)的數(shù)據(jù)。

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

智能運(yùn)維

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

例如：如果收集到的數(shù)據(jù)顯示最近的磁盤更換率比較高，那么我們就可以預(yù)測(cè)下一次磁盤可能發(fā)生故障的時(shí)間。

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

整理/夏立成 上海藍(lán)夢(mèng)創(chuàng)始人兼CEO，湖北IT公司副總裁，致力于以IT外包網(wǎng)絡(luò)維護(hù)服務(wù)賦能企業(yè)客戶發(fā)展，幫助企業(yè)客戶創(chuàng)新、迭代、進(jìn)化。

藍(lán)夢(mèng)成立于上海，致力于提供IT外包、弱電工程（網(wǎng)絡(luò)布線、機(jī)房建設(shè)、門禁考勤、視頻監(jiān)控、電話交換機(jī)、多媒體會(huì)議室）、系統(tǒng)集成（建網(wǎng)、網(wǎng)絡(luò)改造、WIFI覆蓋）企業(yè)客戶、數(shù)據(jù)備份、病毒防護(hù)、文件權(quán)限、虛擬化等）、云服務(wù)（微軟云、阿里云、企業(yè)郵箱等）“一站式”IT外包解決方案。 ， 咨詢。