自動化建設歷程

持續集成的構建背景，如上圖：

在架構上，我們將主從數據庫分為分庫、分表、路由選擇。

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

同時也出現了一些相應的配套服務，如搜索引擎、各種MQ（Queue）等。

開發給運維帶來的挑戰

在互聯網1.0到3.0的演進過程中，隨著業務的快速增長，我們的運維面臨著各種各樣的挑戰，主要從質量、效率、成本、安全四個方面來分析。

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

直接指標，我們可以從監控中看到網絡、服務、應用、系統的可用性； 間接指標，我們可以對一些經驗參數進行基準測試，比如跑步速度； 我們還可以對一些業務參數進行，比如說手機短信的到達率。

我們的業務可用性曾經很低，沒有完整的監控系統。 同時，我們的監控狀態也比較混亂，不僅覆蓋率低，還經常造成一些誤報、漏報、漏報等情況。 這些直接導致了整個監控的不可信。

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

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

在安全方面，它是整個互聯網產品的生命線。 因此，在早期的產品開發過程中，我們制定了一些安全規范和制度。

隨后，建立了較為完善的安全體系，從系統、數據、應用三個維度體現團隊對安全問題的把控。

運維平臺狀態

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

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

發布平臺的演變

我們的發布平臺經歷了三個發布流程：周發布、日發布、自助發布。 由于剛開始業務比較簡單，我們當時采用的是人工方式。

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

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

針對這個問題，我們將CMDB“業務樹”與發布平臺上的業務模塊關聯起來，制定了一些相關的發布規范和指標，從而提高了發布的成功率和容錯性。

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

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

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

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

發貨流程

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

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

我們在運維生產環境的時候，會準備一些基礎環境，為各種日志采集、告警監控、應用的快速擴展等提供那些自動部署的服務。

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

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

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

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

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

二是整體發展框架。 我們技術委員會持續推進基礎開發框架和架構，確保我們有基礎的技術棧和環境化的自動化流程。

交付管道的核心原則是自動化標準化流程。 我們在其中開發了更多的流程和規范，以實現可靠和可重復的持續交付流水線。

這個過程會包含很多內容，比如：編譯階段提交并行開發，編譯構建，單元測試，驗證階段進行系統測試和集成測試。

最后是發布和運維階段的生產交付，涉及一個發布的回滾和后續的生產監控。 這些過程都是在管道上完成的。

另外，系統是一個多角色的平臺，上面會有一些負責開發的人員，一些運維測試人員進行各種協調，讓平臺讓我們整個團隊受益。

持續集成和云交付

標準化建設

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

在標準化方面，我們有硬件標準化、組件標準化、技術棧標準化（比如我們使用的協議類型），還有監控標準化。

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

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

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

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

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

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

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

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

自動化施工

我們再看一下持續集成的過程：

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

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

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

我們再看看發布過程：

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

有了這個持續交付平臺，我們就可以用它來支撐互聯網通用的、快速迭代的產品開發模型。

既能實現迭代前的需求規劃，又能保證迭代中的開發、測試和發布，以及迭代后的評審。

通過收集信息和數據，我們可以看到系統是否存在嚴重的代碼質量問題，是否存在堵塞。

此外，bug修復的狀態也一目了然。 我們還可以獲得代碼覆蓋率、代碼測試通過率、性能測試、安全測試和接口測試數據。

同時，我們不僅可以知道編譯通過率和發布成功率，還可以獲得其他與效率相關的數據。

這些質量數據可以驅動和提升我們的技術能力，保證系統上線前的質量。 當然，我們也可以利用這些數據進一步完善和優化配送流程，確保配送流程的可靠性。

智能運維

回顧以上自動化建設的三個階段，我們可以發現，智能運維主要是通過收集數據進行學習，達到分析預測的目的。

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

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

整理/夏立成 上海藍夢創始人兼CEO，湖北IT公司副總裁，致力于以IT外包網絡維護服務賦能企業客戶發展，幫助企業客戶創新、迭代、進化。

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