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

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

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

第一幕：發(fā)現(xiàn)問題

幾周前，我們的AWS服務(wù)器開始發(fā)送遇險信號。 我們的質(zhì)量檢查團隊在其中一項測試中遇到了該問題，并抱怨服務(wù)器無法進行負載測試。 他們求助于我們的研發(fā)副總裁尋求幫助。 研發(fā)副總裁掏出信用卡，增加了服務(wù)器負載，并告訴質(zhì)量檢查人員問題已解決。

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

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

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

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

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

java解決錯誤經(jīng)驗

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。