【51CTO精选译文】今天要与各位读者分享另一则颇有意思的故事。我确信，只要读者是应用所有者，或者负责运行Web应用程序，那么大多数人都会有兴趣。
我们最近为我们的大多数实际运行的网站改变了验证服务。本人负责的这个网站是Compuware APM Community。验证服务发生变化是一件大事，我们先在测试环境上上测试了这个变化，之后才部署到线上的生产环境。测试环境下一切看起来很好。结果部署到线上环境之后发现，有一个方面我们遗漏了，导致特定的用户组当中有几个用户受到了影响，他们现在访问不了网站上的某些内容。
我前前后后花了5分钟时间来查找这个问题、确认带来的影响，并且为我们的操作部门提供了足够多的信息，以便解决问题。
编者注：本文来自Compuware dynaTrace的团队博客，以下的操作步骤主要是试用dynaTrace网站监测工具来完成，有产品宣传的意思在里面。不过重要的是发现线上环境问题的一个思路，这个思路仍然有一定参考意义。
***个问题：有没有问题是我们在测试环境中没有发现的？
打开应用程序概况图后显示，我们的Community门户网站上某个事务出现的失败率非常高：
应用程序概况图表明了我们的其中一个事务出现的失败率很高。
先来回答***个问题：没错，我们确实遇到了问题！
第二个问题：究竟是什么问题？
下一步是查看自动检测到的错误，这些错误表明这种问题与HTTP 4xx请求有关——这意味着，许多用户访问几个页面的请求被拒绝：
访问拒绝问题是导致失败率很高的根源。
现在，我们完全知道了访问这些页面出现了限制问题。至于这是个实际的问题还是只是用户试图访问受限制的内容，还没有搞清楚。
第三个步骤：这是个实际的问题吗？如果是，我能为操作部门提供什么样的信息以解决问题？
正如前面所说的那样，这可能是由于许多用户只是试图访问受限制的内容——这种情况下，我们觉得这些错误没什么大不了，因为本来就会是这样。查看了底层的错误信息（比如异常）后，我们发现，问题实际上与我们的验证服务有关。看来我们在改用新的验证系统之后没有把所有的安全组迁移过去：
异常详细信息表明，我们的安全组遇到了一个问题。
这些信息足以让操作部门搞清楚为什么这些安全组没有被迁移过去。
第四个问题：哪些用户受到了影响？我们能够积极主动地联系这些用户、表示歉意吗？
由于我们现在知道这个问题出在我们身上，我们想知道哪些用户受到了影响。作为应用程序所有者，我想积极主动地联系这些用户，解释他们看来遇到了问题（尽管他们还没有报告这些问题），并且让他们知道我们正在积极寻求解决办法。借助我们的用户体验解决方案，我们完全搞清楚了遇到这些异常的每一个访客的具体情况：
受到验证问题影响的访客
结束语
幸好，我们在测试环境测试了这套系统，因而我们得以解决了这方面的问题。但要是能真正看清生产环境下出现的问题，那就更好了，因为并不总是可能测试每一种场景。
原文：Field Report: 5 Minutes to Identify a Production Problem and its Impact about:performance
