我们如何认识到解决预生产错误的旧方法还不够，以及我们如何能够改变这种情况
第一次尝试时就没有完美的代码，我们所有人都可以证明我们已经学到了很难的方法。 不管我们使用多少测试周期，代码审查或工具，总有至少一个偷偷摸摸的错误设法使我们感到惊讶。
在下面的文章中，我们将分享我们关于此类错误的故事，与我们在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
