java解決錯誤經驗

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

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

在下面的文章中，我們將分享我們關于此類錯誤的故事，與我們在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解決錯誤經驗

總結

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

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