[持續交付實踐] 交付流水線設計：基於測試腳本的線上撥測監控系統

前言

持續交付這個專題到如今已經寫了七八篇文章，前面重點都是在寫pipeline的總體實現，這塊大體的內容也都寫的差很少了（docker這個坑先不去挖它）。論壇裏一些同窗的承認，既讓人欣慰又有些惶恐，原本已經好久沒有寫博文,但本身挖的這個大坑無論怎麼樣含淚也要填完吧 。
今天又看了一次目錄，暫且先跳過中間各個測試方法（有點審美疲勞），決定先開始聊聊最末端的監控（別問爲何，就是任性哈哈）。

線上監控概述

也許持續交付理論更多的是強調做爲軟件開發交付的過程實踐，發佈後線上監控在《持續交付》這本書中其實已經可貴覓到相關內容（這也是我的以爲這本書稍顯遺憾的地方）。
但當把軟件部署到機器，APP發佈到商店之後，並不意味着就萬事大吉了，任何一個環節出錯線上故障就會出現。因此咱們還須要一整套完整線上監控體系對系統運行狀況進行監測，但願一有問題就能及時發現解決，並避免問題的大面積擴大，這也是質量保障很是重要的一個環節。
目前通用的監控方法和手段主要包括：
1.運維層面的監控：包括主機資源狀況、機房網絡狀況等
2.業務層面的監控：如在線用戶數，用戶活躍度等
3.APP/WEB層面的錯誤監控：如Crash率，卡頓，性能，頁面錯誤等
4.服務層面的監控：如服務的請求量，tps,code反饋狀況，鏈路狀態等。
5.安全層面的監控：惡意安全掃描請求，安全感知，行爲風控等
6.測試層面的監控：這篇會重點先介紹下這個，經過測試撥測實現對線上功能和可用性的監控。

線上撥測監控產生

幾年前咱們開始實施自動化測試的覆蓋，從UI層到接口層，自動化測試腳本在不停的積累，並在測試環境中經過持續集成的方式發揮效力，在發佈到線上之後，咱們也會抽取一部分腳本進行線上的驗收，但在發佈驗收完之後仍是時不時會跑出一些故障。
緣由多種多樣，好比CDN不穩定的問題，系統性能的問題，受人惡意攻擊，發佈後人爲操做錯誤，配置不當等等。出現故障之後你們壓力都很大，測試同窗也以爲很是委屈，發佈到大半夜我作了各類驗收確認那時候都是沒問題的，但後面不知怎麼回事又出問題了，這時我就會想是否能夠把這些線上驗收的腳本在線上就讓他按期跑起來，監測咱們全部的服務（不論是域名服務仍是域名後面的各個子服務），出現問題後就經過報警機制發佈給相關開發測試同窗，第一時間排查問題，因此就有了這套線上撥測監控系統。
目前這套撥測監控機制已經穩定運行了三年，積累了數千個監控點。我我的對它也是又愛又恨，愛的是它確實有效發現了線上無數的故障，成爲了團隊應急處理的首選響應信號，恨的是多少個晚上被短信報警驚醒，須要起來召集你們排查問題，固然如今已經逐漸把報警細分到項目成員，我參與應急處理的也逐漸少了，但一些大面積的故障仍是要及時參與。

需求概述

撥測監控系統是一款用於監控公司全部應用以及核心業務是否正常運行的系統。系統須要實現如下目標：
一、能夠7×24小時自動運行。
二、監控任務範圍、執行時間可動態配置。
三、能夠針對Web服務、WebService服務、Hessian服務、Dubbo服務、數據庫、緩存、消息隊列等等多種服務進行監控。
四、發現異常後須要郵件、短信進行報警

總體設計

軟件功能模塊
監控系統主要包含三個模塊，分別爲：
a. 各個應用監控腳本，各個負責監控各個應用或業務是否正常運行，若是出現異常發送報警短信以及郵件。
b. 監控任務調度模塊，負責任務調度，定時執行監控腳本。
c. 短信以及郵件報警模塊，在監控異常的時候嚮應用負責人發送郵件以及短信報警。
軟件技術架構設計
監控系統主要採用Jenkins + Java技術來實現。Jenkins主要負責任務調度、監控任務管理、監控報告發送。Java負責各個監控功能實現，具體還涉及Spring、HttpClient、Selenium、Appium、Maven、JUnit等框架。說白了就是CI平臺+自動化測試腳本+報警模塊。
監控系統架構圖

 

監控框架流程圖

 

 

功能流程

數據庫監控流程
經過對應用數據庫中重要表字段進行監控，當發現有異常數據入庫，或者應用系統異常表中有數據插入時，能第一時間發現問題，下發短信通知相關人員跟進，確保線上系統的正常運行。主體流程圖以下：

 

消息隊列監控流程
經過按期輪詢各隊列提供者，當發現某個隊列等待長度超過閥值時，說明隊列消費存在問題，發送短信通知相關人員進行跟進。目前已實現的監控隊列系統有：ActiveMQ、RabbitMQ、Kafka。

 

應用可用性監控流程
此功能是本系統實現的重點，針對每一個線上應用，選擇不一樣的重點功能進行監控。經過對重點功能的用例設計，制定合理的監控策略，設置準確的預期結果，經過對預期結果的斷言，採集相關的返回信息，如有異常，及時下發短信通知相關人員。已覆蓋超過90%的線上系統，爲線上系統的正常運行提供了有力的支撐。

 

敏感請求越權監控
探測方法：這個是安全方面的一些監控，天天定時執行檢查涉及敏感信息的接口或頁面，檢查是否存在越權獲取數據的狀況。
規則：只容許獲取有權限的數據，無權限的數據不能獲取，若是獲取了無權限的數據就報警。
其實還有很多其餘監控點，好比一些業務指標的對比，一些重要定時任務的執行等，均可以按需去增長。

 

實施要點

1.穩定，穩定，仍是穩定。撥測腳本的斷言點必需要保證穩定，寧肯少必須精，誰也受不了大半夜被監控驚醒而後發現是一通誤報。
2.與發佈平臺的配合，在發佈的時候會先中止相應的監控腳本，並在發佈完之後自動啓動。
3.儘可能選取讀取操做進行監控，不要污染線上數據，好比說註冊，購買之類的操做就儘可能不要監控了。數據庫監控也是隻會作讀操做，不容許作寫入操做。
4.報警內容必需要描述清晰，具體到哪一個應用，哪一個服務器，在哪一個環節出現了哪些錯誤，方便儘快的進行問題定位。

結語

在之前的理念裏，線上的監控彷佛都是運維團隊的事情，但光靠運維對主機網絡的監控，其實遠發現不了應用自己的一些故障，而若是經過錯誤日誌的監控，成本較大並且線上日誌打印通常都比較混亂，也不能及時有效的發現問題。利用測試團隊積累的自動化測試腳本的方式對線上進行撥測，實現成本很小會是一種不錯的實現方式。不足之處是這套機制只能發現哪裏有問題，但不能詳細的給出問題的緣由，因此咱們通常還需配合鏈路監控的機制進行排查，鏈路監控和安全監控這兩個我相對熟悉的專題後面有時間的話我也會想辦法整理下。因此這篇就先到這裏了，重點介紹測試層面的監控，15年的時候看到過一個ricky_qiu（這傢伙據說已經轉型CTO了）的PPT，也開展過相似的工做，你們也能夠找來看看，其實沒有太複雜的東西，在我看來就是把一些最穩定的自動化測試腳本搬到線上定時運行，並增長相應報警機制而已，每一個團隊均可以嘗試實施。