我們如何認識到解決預生產錯誤的舊方法還不夠，以及我們如何能夠改變這種情況

第一次嘗試時就沒有完美的代碼，我們所有人都可以證明我們已經學到了很難的方法。 不管我們使用多少測試周期，代碼審查或工具，總有至少一個偷偷摸摸的錯誤設法使我們感到驚訝。

在下面的文章中，我們將分享我們關于此類錯誤的故事，與我們在OverOps上采用的新方法相比，開發人員用于解決該錯誤的通用工作流程。 劇透警報：日志文件不刪節，現在是時候了解原因了。

非常感謝Dor Levi ，他幫助我們完成了本期和發布的文章！

第一幕：發現問題

幾周前，我們的AWS服務器開始發出遇險信號。 我們的質量檢查小組在其中一項測試中遇到了該問題，并抱怨服務器無法處理其負載測試。 他們求助于我們的研發副總裁尋求幫助。 研發副總裁掏出了信用卡，增加了服務器負載，并告訴質量檢查人員該問題已解決。

可以猜到，問題還遠沒有結束。 在第二個投訴周期->增加AWS付款->投訴后，我們意識到此問題還有很多，需要進一步調查。 我們必須找出問題出在哪里，我們的第一步是打開Amazon CloudWatch Monitoring Details，該圖表為我們提供了以下圖表：

在我們的服務器上限制了讀取請求。 kes。

如您所見，“批處理”請求從上午10:00開始就開始混亂了，消耗了不斷增長的資源和失敗的操作，有效地導致了QA運行負載測試的過渡環境的中斷。

亞馬遜提供的數據可以告訴我們導致問題的哪種操作類型，但不能告訴我們它來自何處以及為什么會首先發生。 是時候卷起袖子，開始深入研究代碼了。 閱讀完整的白皮書，以了解下一步的工作。

翻譯自: https://www.javacodegeeks.com/2018/04/the-new-way-of-handling-java-errors-before-they-hit-production.html

總結

以上是生活随笔為你收集整理的在Java错误产生之前对其进行处理的新方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。