Dropbox每天會進行近35,000次構建，執行數百萬個自動化測試用例。其中有一些測試可能會由於代碼變更而執行失敗，有一些執行失敗的測試用例無法重現。因爲Dropbox的測試規模很大，手動禁用失敗的測試用例、回滾錯誤的代碼提交以及通知測試所有者是很困難的。於是，Dropbox開發了Athena，目的是爲了自動化這些操作。Athena可以將測試的失敗用例通知給測試所有者，並檢測和隔離失敗的測試。它不會回滾錯誤的代碼提交。
代碼提交從基本的“預提交”測試開始，與主分支合併後進行“後提交”測試。後提交測試的成本比較高，包括UI和端到端測試。這一類測試會因爲時間、日期和基礎設施等環境因素髮生失敗，也有可能會因爲併發性和隨機數生成等代碼固有特點而發生失敗。Dropbox之前有一個輪班團隊負責回滾這些變更。InfoQ聯繫了Dropbox的軟件工程師Utsav Shah，瞭解更多有關Athena的細節。
Athena使用一種多步驟算法來確定一個測試用例是否存在問題。在一個週期內失敗多次的後提交測試將被標記，並且允許代碼通過。失敗的測試將繼續運行，以便確定失敗是因爲故障還是因爲糟糕的代碼導致的。Athena還可以指出導致測試失敗的代碼提交位置。該系統通過自動隔離這類測試減少了Dropbox的運行開銷。Shah指出，Athena被用來“監控Dropbox所有服務（後端、前端）的大部分測試，不過還沒有被用來監控桌面或移動應用程序的測試。”
Dropbox使用了持續集成（CI），儘管不同服務的部署策略不同。Shah表示：
Dropbox的後端服務由很多特定團隊負責，還有一個主要的Web應用程序在支撐dropbox.com。我們要求所有相關的測試用例都是綠色的，非活動站點/實驗性服務除外。一些服務所有者選擇了持續部署，而另一些則喜歡手動部署。
Athena提供了一個用戶界面用來監控服務的狀態，爲開發者提供可見性，Shah解釋說:
我們顯示每個測試用例的進度指標，以及它們基於不同代碼提交的執行結果。每個測試用例都有一個對應的消息，指出哪個代碼提交處於平分線狀態，以及可能會導致測試失敗的下界和上界。如果進度緊急，他們可以自己捕獲並解決問題。
那麼如何監控Athena系統呢？Shah說，在這方面需要做更多的工作：
我們有一組單元測試，它們使用內部CI系統的一個虛擬版本來捕獲業務邏輯中的迴歸問題，比如平分線中的bug。我們針對CI系統進行集成測試，驗證API的保證機制，這樣可以捕獲大多數問題。
Dropbox的服務編排系統可以自動生成警報，捕捉很多基本問題。不過我們還沒有對Athena進行實時監控。除非CI系統出現了問題，否則系統通常可以正常工作，我們大多數人都已經知道這種情況了。當某些上游API運行緩慢並且出現超時時，由於缺乏監控，有時會出問題，因此我們正在考慮添加一些基本警報來捕捉這些問題。
Athena功能路線圖中包含了自動回滾錯誤的代碼提交和桌面測試。由於存在內部依賴關係，目前還沒有將其開源的計劃。
原文鏈接：
Athena: Automated Build Health Monitoring at Dropbox Engineering