自動化建設(shè)歷程

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

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

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

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

開發(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)的可用性； 間接指標，我們可以對一些經(jīng)驗參數(shù)進行基準測試，比如跑步速度； 我們還可以對一些業(yè)務(wù)參數(shù)進行，比如說手機短信的到達率。

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

在效率方面，效率是衡量運維平臺功能好壞的標準，主要體現(xiàn)在服務(wù)器的交付，線上的各種變化，以及我們對故障的及時發(fā)現(xiàn)。 我們在沒有將流程與自動化集成的情況下頻繁交付和更改，導致整體效率低下。

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

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

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

運維平臺狀態(tài)

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

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

發(fā)布平臺的演變

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

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

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

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

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

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

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

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

發(fā)貨流程

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

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

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

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

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

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

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

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

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

交付管道的核心原則是自動化標準化流程。 我們在其中開發(fā)了更多的流程和規(guī)范，以實現(xiàn)可靠和可重復的持續(xù)交付流水線。

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

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

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

持續(xù)集成和云交付

標準化建設(shè)

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

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

在測試自動化方面，我們涵蓋的內(nèi)容比較廣泛，包括：單元測試，單元覆蓋率，以及測試的進入和退出條件，比如在交付過程中是否允許保留一些bug。

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

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

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

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

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

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

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

自動化施工

我們再看一下持續(xù)集成的過程：

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

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

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

我們再看看發(fā)布過程：

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

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

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

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

此外，bug修復的狀態(tài)也一目了然。 我們還可以獲得代碼覆蓋率、代碼測試通過率、性能測試、安全測試和接口測試數(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ù)進行學習，達到分析預測的目的。

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

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

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

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