传统APM让开发者瞬间崩溃的三大问题是什么,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
,如果你负责为企业创建或管理面向客户的应用程序,那么将有一长串需要担心的事情。比如,最近,企业推出了新版本的应用程序,客户在生产中却发现了严重问题,应用程序的过度延迟正在破坏其用户体验。这时,你才想起来使用APM解决其中一些问题,实在是太晚了。你的客户早已直接向公司抱怨,并对社交媒体表示了不满,而你的管理团队会问:“这是怎么发生的?”
这种噩梦般的场景,即使是世界上最好的公司也能体验到。例如,谷歌发现流量下降了20%,而搜索页面的生成时间多了半秒。亚马逊发现,每增加100毫秒的延迟,销售额就会减少1%。如果连这些巨头都可能成为生产应用问题的受害者,它也可能发生在任何人身上。
仅依靠传统的APM手段可能会让企业面临三个关键领域的风险:
<强>。无法尽早发现性能问题
<强>。无法诊断性能问题的根本原因
<强>。无法及时修复性能问题
<>强发现性能问题
管理应用程序性能的最大问题之一是能否尽早找到性能问题,大多数企业的答案都是否定的。事实上,75%的开发人员都会在报告中提到性能问题影响生产中最终用户的案例,APM解决方案传统上被设计为仅在生产中工作。
传统APM不是为测试阶段而建立的,虽然传统APM通常专注于生产环境,但一些企业试图在开发和测试的早期阶段使用它们。他们经常发现,这些指标和报告在这些阶段无效。以生产为中心的APM将为应用程序性能提供统计分析,实质上是数千个事务的汇总结果。这可能有助于指出会影响业绩的重大问题,但由于没有任何交易细节,因此可能是一个非常模糊的指标。
开发人员与代码更改将如何影响整体性能是分开的两件事情。在许多公司仍然有一种情况,开发人员不直接与构建的应用程序性能挂钩。开发者构建应用程序并将其投放到生产中的操作团队,当该团队发现问题时,他们将反馈给开发团队进行修复。
DevOps运动敦促企业通过创建一个大型的虚拟团队,将一些职能和责任从运营转移到开发,从而摆脱这种困境。
但即使在DevOps环境中,我们仍然可以看到许多测试正在进行,大多数APM工具都是面向运营或性能专家的。正因为如此,只要满足功能要求,开发人员并不觉得他们最终要负责交付代码。这在发展和运营团队之间造成了一点分歧,仍然难以找到性能问题。为了跨越这两个团队,开发人员应该有更多能力来洞察并影响他们正在构建的应用程序性能。今天,以生产为中心的APM并不能赋予开发者这样的能力。
<强>诊断性能问题的来源
一旦发现应用程序问题,诊断问题根源又变成一件棘手的事情。当你从开发过程转变为生产时,这是一项越来越困难的任务。测试较晚的团队将被迫诊断复杂基础架构和场景中正在发生的性能问题。实际上,86%的根本原因是应用程序级别问题,这些问题将在开发环境中体现出来,并与环境保持一致。因此,当找到根本原因更容易时,尽早捕捉这些应用程序级别问题是有道理的。
一旦应用程序投入生产,它就是一个大而复杂的系统的一小部分。不再仅仅是应用程序的工作,而是关于应用程序周围的所有技术,从网络基础设施到分布式系统.Dynatrace的一项研究发现,平均来说,单个交易使用82种不同类型的技术,这使得试图诊断生产中的性能问题来源如同大海捞针。
由于这种复杂性使得难以准确诊断问题根源,大多数问题并没有得到真正解决,只是简单地修补。更糟糕的是,匆忙交付修补往往容易造成其他问题,每过一天,问题就越来越严重。
正如前面已经介绍过的,传统APM是高层次的,足以告诉你存在一个问题,并指出受影响的一般区域。它们的目的是监控难以置信的复杂基础设施,所以一般的健康报告在运营团队生产场景中非常有用。但是,传统APM对于那些希望诊断问题根源的开发团队来说并不重要,因为他们没有提供详细的根源分析。当检测到问题并创建了报告将其传递给开发团队时,可能需要在分阶段环境中使用其他工具集的性能专家采取可操作的数据。
