主持人 > 博客 > 管理 > 持續監控 – CI/CD 管道中軟體品質檢查的自動化

持續監控 – CI/CD 管道中軟體品質檢查的自動化

現在 DevOps 的話題是炒作。 持續整合和交付管道 CI / CD 每個人都在實施它。 但大多數人並不總是適當注意確保 CI/CD 管道各個階段的資訊系統的可靠性。 在這篇文章中，我想談談我在自動化軟體品質檢查和實現其「自我修復」的可能場景方面的經驗。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源

我在某公司IT服務管理部門擔任工程師 “LANIT-整合”。 我的核心專業領域是各種應用程式效能和可用性監控系統的實施。 我經常與來自不同細分市場的 IT 客戶就監控其 IT 服務品質的當前問題進行溝通。 主要目標是最小化發布週期時間並增加發布頻率。 當然，這都是好事：更多版本 - 更多新功能 - 更滿意的用戶 - 更多利潤。 但事實上，事情並不總是一帆風順。 由於部署率非常高，我們的版本品質立即受到質疑。 即使擁有完全自動化的管道，最大的挑戰之一是將服務從測試轉移到生產而不影響應用程式的正常運行時間和用戶體驗。

根據與客戶多次交談的結果，我可以說發布品質控制、應用程式可靠性問題及其在 CI 各個階段「自我修復」（例如回滾到穩定版本）的可能性/CD 管道是最令人興奮和最相關的主題之一。

持續監控 – CI/CD 管道中軟體品質檢查的自動化
最近，我自己在客戶端工作——網路銀行應用軟體支援服務。 我們應用的架構使用了大量自寫的微服務。 最可悲的是，並不是所有的開發人員都能應對高速的開發；一些微服務的品質受到影響，這給他們和他們的創建者帶來了有趣的綽號。 有一些關於這些產品是由什麼材料製成的故事。

持續監控 – CI/CD 管道中軟體品質檢查的自動化

“問題的表述”

高頻率的發布和大量的微服務使得無論是在測試階段還是在運營階段都很難理解應用程式的整體運行情況。 變化不斷發生，如果沒有良好的監控工具，很難控制它們。 通常，在早上發布一晚的版本後，開發人員就像坐在火藥桶上一樣等待沒有任何問題發生，儘管所有檢查在測試階段都是成功的。

還有一點。 在測試階段，檢查軟體的功能：應用程式主要功能的實現以及不存在錯誤。 定性性能評估要么缺失，要么沒有考慮應用程式和整合層的所有方面。 有些指標可能根本不會被檢查。 因此，當生產環境出現故障時，技術支援部門只有在真正的使用者開始抱怨時才發現問題。 我希望盡量減少低品質軟體對最終用戶的影響。

解決方案之一是在 CI/CD Pipeline 的各個階段實施軟體品質檢查流程，並添加各種場景以在緊急情況下恢復系統。 我們還記得我們有 DevOps。 企業希望盡快收到新產品。 因此，我們所有的檢查和腳本都必須自動化。

任務分為兩個部分：

  • 在測試階段對組件進行品質控制（以自動化捕獲低品質組件的過程）；
  • 生產環境中的軟體品質控制（自動偵測問題的機制及其自我修復的可能場景）。

用於監控和收集指標的工具

為了實現既定目標，需要一個監控系統來偵測問題並將其傳輸到 CI/CD 管道各個階段的自動化系統。 如果該系統為各個團隊（開發、測試、營運）提供有用的指標，這也將是一件正面的事情。 如果也用於商業用途，那就太棒了。

要收集指標，您可以使用一組不同的系統（Prometheus、ELK Stack、Zabbix 等），但在我看來，APM 等級解決方案最適合這些任務（應用程序性能監控），這可以大大簡化您的生活。

作為支援服務工作的一部分，我開始使用 Dynatrace 的 APM 類別解決方案來做類似的專案。 現在，我在整合商工作，對監控系統市場非常了解。 我的主觀意見：Dynatrace 最適合解決這類問題。
Dynatrace 提供每個使用者操作的水平視圖，而粒度等級一直到程式碼執行層級。 您可以追蹤各種資訊服務之間的整個互動鏈：從 Web 和行動應用程式的前端層級、後端應用程式伺服器、整合匯流排到對資料庫的特定呼叫。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源。 自動建置系統元件之間的所有依賴關係

持續監控 – CI/CD 管道中軟體品質檢查的自動化源。 服務運行路徑自動檢測與構建

我們還記得我們需要與各種自動化工具整合。 這裡的解決方案有一個方便的 API，可讓您發送和接收各種指標和事件。

接下來，讓我們更詳細地了解如何使用 Dynatrace 系統解決這些問題。

任務 1. 測試階段組件品質控制的自動化

第一個挑戰是儘早發現應用程式交付管道中的問題。 只有「好的」程式碼建置才能投入生產。 為此，測試階段的管道應包含額外的監視器來檢查服務品質。

持續監控 – CI/CD 管道中軟體品質檢查的自動化

讓我們逐步了解如何實現此流程並自動化此流程：

持續監控 – CI/CD 管道中軟體品質檢查的自動化源

下圖顯示了自動化軟體品質測試步驟的流程：

  1. 部署監控系統（安裝代理程式）；
  2. 識別用於評估軟體品質的事件（指標和閾值）並將其傳輸到監控系統；
  3. 產生負載和效能測試；
  4. 收集監控系統中的效能和可用性數據；
  5. 基於軟體品質評估事件的測試資料從監控系統傳輸到 CI/CD 系統。 裝配體的自動分析。

步驟一、監控系統部署

首先，您需要在測試環境中安裝代理程式。 同時，Dynatrace 解決方案有一個很好的功能 - 它使用安裝在作業系統實例（Windows、Linux、AIX）上的通用代理程式 OneAgent，自動檢測您的服務並開始收集它們的監控資料。 您不需要為每個進程配置單獨的代理程式。 雲端平台和容器平台的情況類似。 同時，您也可以自動化代理安裝過程。 Dynatrace 完美契合「基礎設施即程式碼」概念（基礎設施即代碼或 IaC)：有適用於所有流行平台的現成腳本和說明。 您將代理程式嵌入到服務的配置中，當您部署它時，您會立即收到具有已工作代理程式的新服務。

第 2 步：定義軟體品質事件

現在您需要決定服務和業務運營的清單。 準確考慮那些對您的服務至關重要的使用者操作非常重要。 在這裡我建議諮詢業務和系統分析師。

接下來，您需要確定要在每個層級的審核中包含哪些指標。 例如，這可以是執行時間（分為平均值、中位數、百分位數等）、錯誤（邏輯、服務、基礎設施等）和各種基礎設施指標（記憶體堆、垃圾收集器、執行緒計數等）。

為了 DevOps 團隊的自動化和易用性，出現了「Monitoring as Code」的概念。 我的意思是，開發人員/測試人員可以編寫一個簡單的 JSON 檔案來定義軟體品質保證指標。

讓我們看一下此類 JSON 檔案的範例。 Dynatrace API 中的物件用作鍵/值對（API 描述可以在此處找到 Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

該檔案是時間序列定義的陣列：

  • timeseriesId – 正在檢查的指標，例如回應時間、錯誤計數、使用的記憶體等；  
  • 聚合 - 指標聚合的級別，在我們的例子中為 avg，但您可以使用您需要的任何一個（avg、min、max、sum、count、percentile）；
  • Tags – 監控系統中的物件標籤，也可以指定特定的物件識別碼；
  • 嚴重和警告——這些指標調節我們指標的閾值；如果測試值超過嚴重閾值，那麼我們的構建被標記為不成功。

下圖顯示了使用此類閾值的範例。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源

第 3 步：負載生成

一旦我們確定了服務的品質水平，我們就需要產生測試負載。 您可以使用任何您熟悉的測試工具，例如 Jmeter、Selenium、Neotys、Gadling 等。

Dynatrace 的監控系統可讓您從測試中擷取各種元數據，並識別哪些測試屬於哪個發布週期和哪個服務。 建議向 HTTP 測試請求新增額外的標頭。

下圖顯示了一個範例，其中使用附加標頭 X-Dynatrace-Test，我們表明此測試與測試將商品添加到購物車的操作相關。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源

當您執行每個負載測試時，您可以使用 CI/CD 伺服器中的事件 API 將其他上下文資訊傳送到 Dynatrace。 這樣，系統就可以區分出不同的測試。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源。 監控系統中有關負載測試開始的事件

步驟 4-5。 收集性能數據並將數據傳輸到 CI/CD 系統

與產生的測試一起，將需要收集有關檢查服務品質指標的資料的事件傳輸到監控系統。 它還指定了我們的 JSON 文件，該文件定義了關鍵指標。

持續監控 – CI/CD 管道中軟體品質檢查的自動化關於需要檢查 CI/CD 伺服器上產生的軟體品質以傳送到監控系統的事件

在我們的範例中，品質檢查事件稱為 perfSigDynatrace報告 （性能_簽名) - 這是準備好了 普拉金 用於與 Jenkins 集成，Jenkins 是由 T-Systems Multimedia Solutions 的人員開發的。 每個測試啟動事件都包含有關服務、版本號和測試時間的資訊。 該插件在建置時收集效能值，對其進行評估，並將結果與先前的建置和非功能需求進行比較。

持續監控 – CI/CD 管道中軟體品質檢查的自動化監控系統中有關建置品質檢查開始的事件。 源

測試完成後，所有評估軟體品質的指標都會傳回持續整合系統，例如Jenkins，產生結果報告。

持續監控 – CI/CD 管道中軟體品質檢查的自動化CI/CD伺服器上程式集的統計結果。 源

對於每個單獨的構建，我們都會看到在整個測試過程中設定的每個指標的統計數據。 我們也會查看是否存在違反某些閾值（警告和嚴重閾值）的情況。 根據聚合指標，整個構建被標記為穩定、不穩定或失敗。 此外，為了方便起見，您可以將指標新增至報表中，將目前版本與先前版本進行比較。

持續監控 – CI/CD 管道中軟體品質檢查的自動化查看 CI/CD 伺服器上程序集的詳細統計資料。 源

兩個組件的詳細比較

如有必要，您可以轉到 Dynatrace 介面，在那裡您可以更詳細地查看每個建置的統計資料並將它們相互比較。

持續監控 – CI/CD 管道中軟體品質檢查的自動化Dynatrace 中建構統計資料的比較。 源
 
發現

因此，我們獲得了「監控即服務」服務，在持續整合管道中實現自動化。 開發人員或測試人員只需在 JSON 檔案中定義指標列表，其他一切都會自動發生。 我們收到透明的版本品質控制：有關效能、資源消耗或架構回歸的所有通知。

任務 2. 生產環境中軟體品質控制的自動化

這樣，我們就解決如何在Pipeline中自動化測試階段的監控流程的問題。 透過這種方式，我們可以最大限度地減少進入生產環境的低品質組件的百分比。

但是，如果不良軟體最終被出售，或者某些東西壞了，該怎麼辦？ 對於烏托邦，我們希望有自動偵測問題的機制，如果可能的話，系統本身可以恢復其功能，至少在晚上。

為此，類比上一節，我們需要在生產環境中提供自動的軟體品質檢查，並基於場景進行系統自癒。

持續監控 – CI/CD 管道中軟體品質檢查的自動化
自動更正為代碼

大多數公司已經累積了各類常見問題的知識庫以及解決這些問題的操作列表，例如重新啟動進程、清理資源、回滾版本、恢復無效的配置更改、增加或減少組件的數量。集群，切換藍色或綠色輪廓等。

雖然與我交談過的許多團隊多年來都知道這些用例，但很少有人考慮或投資自動化它們。

如果您考慮一下，實現自我修復應用程式效能的流程並沒有什麼太複雜的；您需要以程式碼腳本的形式呈現管理員已知的工作場景（「自動修復為程式碼」概念） ，您針對每個具體案例提前編寫了該內容。 自動修復腳本的目的應該是消除問題的根本原因。 您自己決定應對事件的正確行動。

監控系統中的任何指標都可以作為啟動腳本的觸發器，最主要的是這些指標可以準確地確定一切都不好，因為您不希望在生產環境中出現誤報。

您可以使用任何系統或系統集：Prometheus、ELK Stack、Zabbix 等。 但我將給出一些基於 APM 解決方案的範例（Dynatrace 將再次作為範例），這也將有助於讓您的生活更輕鬆。

首先，就應用程式操作而言，一切都與效能相關。 該解決方案提供了數百個不同級別的指標，您可以將其用作觸發器：

  • 使用者層級（瀏覽器、行動應用程式、物聯網設備、使用者行為、轉換等）；
  • 服務和操作水平（性能、可用​​性、錯誤等）；
  • 應用程式基礎設施等級（主機作業系統指標、JMX、MQ、Web 伺服器等）；
  • 平台層級（虛擬化、雲端、容器等）。

持續監控 – CI/CD 管道中軟體品質檢查的自動化Dynatrace 中的監控等級。 源

其次，正如我之前所說，Dynatrace擁有開放的API，這使得它非常容易與各種第三方系統整合。 例如，當超出控制參數時向自動化系統發送通知。

下面是與 Ansible 互動的範例。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源

下面我將舉幾個例子來說明可以進行什麼樣的自動化。 這只是案例的一部分；您環境中的案例清單僅受您的想像和監控工具功能的限制。

1. 錯誤部署 – 版本回滾

即使我們在測試環境中對所有內容進行了很好的測試，新版本仍然有可能在生產環境中殺死您的應用程式。 同樣的人為因素並沒有被取消。

在下圖中我們看到服務上的操作的執行時間出現了急劇的跳躍。 此跳轉的開始時間與部署到應用程式的時間一致。 我們將所有這些資訊作為事件傳輸到自動化系統。 如果在我們設定的時間之後服務的效能沒有恢復正常，則會自動呼叫一個腳本將版本回滾到舊版本。

持續監控 – CI/CD 管道中軟體品質檢查的自動化部署後操作效能下降。 源

2.資源加載100%－新增節點到路由

在下列範例中，監控系統確定其中一個元件正在經歷 100% CPU 負載。

持續監控 – CI/CD 管道中軟體品質檢查的自動化CPU負載100%
 
此事件可能有幾種不同的場景。 例如，監控系統另外檢查資源缺乏是否與服務負載的增加有關。 如果是這樣，則執行一個腳本，自動將節點新增至路由中，從而恢復整個系統的功能。

持續監控 – CI/CD 管道中軟體品質檢查的自動化事件發生後擴展

3.硬碟空間不足－磁碟清理

我認為很多人已經自動化了這些過程。 使用 APM，您還可以監視磁碟子系統上的可用空間。 如果沒有空間或磁碟運行緩慢，我們調用腳本來清理它或添加空間。

持續監控 – CI/CD 管道中軟體品質檢查的自動化
持續監控 – CI/CD 管道中軟體品質檢查的自動化光碟負載 100%
 
4. 使用者活躍度低或轉換率低－在藍色和綠色分支之間切換

我經常看到客戶在生產環境中對應用程式使用兩個循環（藍綠部署）。 這使您可以在交付新版本時在分支之間快速切換。 通常，部署後，可能會發生無法立即註意到的巨大變更。 在這種情況下，可能不會觀察到效能和可用性的下降。 為了快速回應此類變化，最好使用反映使用者行為的各種指標（會話和使用者操作數、轉換率、跳出率）。 下圖顯示了一個範例，當轉換率下降時，會發生軟體分支之間的切換。

持續監控 – CI/CD 管道中軟體品質檢查的自動化在軟體分支之間切換後，轉換率會下降。 源

自動問題檢測機制

最後，我再舉一個例子來說明為什麼我最喜歡 Dynatrace。

在我的故事中關於在測試環境中自動進行組件品質檢查的部分中，我們手動確定了所有閾值。 這對於測試環境來說是正常的；測試人員在每次測試前根據負載自行確定指標。 在生產環境中，希望能夠自動偵測問題，同時考慮各種基線機制。

Dynatrace 具有有趣的內建人工智慧工具，這些工具基於確定異常指標（基線）並建立所有組件之間的交互圖、相互比較和關聯事件的機制，確定服務運行中的異常情況並提供詳細資訊有關每個問題和根本原因的資訊。

透過自動分析組件之間的依賴關係，Dynatrace 不僅可以確定有問題的服務是否是根本原因，還可以確定其對其他服務的依賴關係。 在下面的範例中，Dynatrace 會自動監控和評估交易執行中每個服務的運作狀況，將 Golang 服務識別為根本原因。

持續監控 – CI/CD 管道中軟體品質檢查的自動化確定故障根本原因的範例。 源

下圖顯示了從事件開始時監控應用程式問題的過程。

持續監控 – CI/CD 管道中軟體品質檢查的自動化透過顯示所有元件和事件來視覺化新出現的問題

監控系統收集了與所出現問題相關的完整事件年表。 在時間軸下方的視窗中，我們可以看到每個元件上的所有關鍵事件。 根據這些事件，您可以以程式碼腳本的形式設定自動更正的過程。

此外，我建議您將監控系統與服務台或錯誤追蹤器整合。 當問題發生時，開發人員可以快速收到完整的訊息，以便在生產環境中進行程式碼層級的分析。

結論

結果，我們最終得到了一個 CI/CD 管道，在 Pipeline 中內建了自動化軟體品質檢查。 我們最大限度地減少低品質組件的數量，提高整個系統的可靠性，如果我們的系統仍然故障，我們會啟動恢復機制。

持續監控 – CI/CD 管道中軟體品質檢查的自動化
自動化軟體品質監控絕對值得投入精力；這並不總是一個快速的過程，但隨著時間的推移，它會取得成果。 我建議在生產環境中解決新事件後，您立即考慮在測試環境中添加哪些監視器進行檢查，以避免錯誤的建置進入生產環境，並建立腳本來自動修正這些問題。

我希望我的例子對您的努力有所幫助。 我也有興趣查看您用於實現自我修復系統的指標範例。

持續監控 – CI/CD 管道中軟體品質檢查的自動化源

來源： www.habr.com

添加評論