我們?nèi)绾握J(rèn)識到解決預(yù)生產(chǎn)錯誤的舊方法還不夠，以及我們?nèi)绾文軌蚋淖冞@種情況

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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