合成監控

2017 年 1 月 25 日

合成監控(也稱為語義監控 [1])會定期對應用程式的自動化測試子集執行實況生產系統測試。結果會推送到監控服務,並在發生故障時觸發警示。這項技術結合了自動化測試和監控,以偵測生產環境中失敗的業務需求。

在小型獨立服務和頻繁部署的時代,很難使用與生產環境中稍後存在的版本完全相同的組合來測試預生產環境。減輕此問題的一種方法是將可測試性從預生產環境擴充到生產環境,這正是 生產環境中的 QA 背後的概念。這麼做會將心態從專注於平均故障間隔時間 (MTBF) 轉移到 專注於平均復原時間 (MTTR)。

對於大多數類型的 F,MTTR > MTBF

-- John Allspaw

合成監控就是一種技術,我們在一家客戶那裡使用過,該客戶是一個數位汽車市場,在十幾個國家/地區擁有數百萬個分類廣告。他們在生產環境中有近百項服務,每項服務每天部署多次。在將服務部署到生產環境之前,會在 持續交付 管線中執行測試。整合測試的相依性不會使用 測試替身,而是對生產環境中的元件執行測試。

以下是這些非常適合合成監控的測試範例。它模擬使用者將分類廣告加入她最愛清單的動作。她執行的步驟如下

為了將測試要求排除在分析之外,我們會將參數(例如 excluderequests=true)新增到 URL。當此參數設為 true 時,會暫時傳遞給所有下游服務,而每個服務都會抑制分析和第三方腳本。

我們可以使用 excluderequests 參數在後端資料儲存區中將資料標記為合成資料。在我們的案例中,這並不相關,因為我們重複使用相同的使用者帳戶,並在測試開始時清除其狀態。缺點是我們無法同時執行此測試。或者,我們可以為每次測試執行建立一個新的使用者帳戶。為了讓測試使用者易於識別,這些帳戶在電子郵件地址中會有特定的前綴或後綴。另一個選項是有一個自訂 HTTP 標頭,會在每個要求中傳送以將其識別為測試,儘管這對於 API 來說更為常見。

我們的測試使用 Selenium 網頁驅動程式執行,並每 5 分鐘使用 PhantomJS 對生產中的服務執行。測試結果會提供給監控系統,並顯示在團隊的儀表板上。根據測試功能的重要性,失敗也可能觸發待命任務的警示。

廣泛堆疊測試的選項位於測試金字塔的頂端,非常適合用於合成監控。這些將會是 UI 測試、使用者旅程測試、使用者驗收測試或 Web 應用程式的端對端測試;或 API 的消費者驅動合約測試 (CDC)。執行一組 UI 測試的替代方案(例如在批次處理作業的背景下)是將合成交易提供給系統,並斷言其所需的最終狀態,例如資料庫條目、佇列上的訊息或目錄中的檔案。

進一步閱讀

致謝

感謝 Henry Lawson 的回饋。

特別感謝 Martin Fowler 的支持、建議和花時間幫助我們改善此 Bliki。

備註

1: Ryan Murray 創造了「語意監控」一詞,並在 2012 年底出現在Thoughtworks 技術雷達上。然而「合成監控」似乎是使用更廣泛的術語,並在合成交易的概念上發揮了作用。