共计 2727 个字符，预计需要花费 7 分钟才能阅读完成。
传统 APM 让开发者瞬间崩溃的三大问题是什么，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
如果你负责为企业创建或管理面向客户的应用程序，那么将有一长串需要担心的事情。比如，最近，企业推出了新版本的应用程序，客户在生产中却发现了严重问题，应用程序的过度延迟正在破坏其用户体验。这时，你才想起来使用 APM 解决其中一些问题，实在是太晚了。你的客户早已直接向公司抱怨，并对社交媒体表示了不满，而你的管理团队会问：“这是怎么发生的?”
这种噩梦般的场景，即使是世界上最好的公司也能体验到。例如，Google 发现流量下降了 20%，而搜索页面的生成时间多了半秒。亚马逊发现，每增加 100 毫秒的延迟，销售额就会减少 1%。如果连这些巨头都可能成为生产应用问题的受害者，它也可能发生在任何人身上。
仅依靠传统的 APM 手段可能会让企业面临三个关键领域的风险：
·无法尽早发现性能问题
·无法诊断性能问题的根本原因
·无法及时修复性能问题
发现性能问题
管理应用程序性能的最大问题之一是能否尽早找到性能问题，大多数企业的答案都是否定的。事实上，75% 的开发人员都会在报告中提到性能问题影响生产中最终用户的案例，APM 解决方案传统上被设计为仅在生产中工作。
传统 APM 不是为测试阶段而建立的，虽然传统 APM 通常专注于生产环境，但一些企业试图在开发和测试的早期阶段使用它们。他们经常发现，这些指标和报告在这些阶段无效。以生产为中心的 APM 将为应用程序性能提供统计分析，实质上是数千个事务的汇总结果。这可能有助于指出会影响业绩的重大问题，但由于没有任何交易细节，因此可能是一个非常模糊的指标。
开发人员与代码更改将如何影响整体性能是分开的两件事情。在许多公司仍然有一种情况，开发人员不直接与构建的应用程序性能挂钩。开发者构建应用程序并将其投放到生产中的操作团队，当该团队发现问题时，他们将反馈给开发团队进行修复。
DevOps 运动敦促企业通过创建一个大型的虚拟团队，将一些职能和责任从运营转移到开发，从而摆脱这种困境。
但即使在 DevOps 环境中，我们仍然可以看到许多测试正在进行，大多数 APM 工具都是面向运营或性能专家的。正因为如此，只要满足功能要求，开发人员并不觉得他们最终要负责交付代码。这在发展和运营团队之间造成了一点分歧，仍然难以找到性能问题。为了跨越这两个团队，开发人员应该有更多能力来洞察并影响他们正在构建的应用程序性能。今天，以生产为中心的 APM 并不能赋予开发者这样的能力。
诊断性能问题的来源
一旦发现应用程序问题，诊断问题根源又变成一件棘手的事情。当你从开发过程转变为生产时，这是一项越来越困难的任务。测试较晚的团队将被迫诊断复杂基础架构和场景中正在发生的性能问题。实际上，86% 的根本原因是应用程序级别问题，这些问题将在开发环境中体现出来，并与环境保持一致。因此，当找到根本原因更容易时，尽早捕捉这些应用程序级别问题是有道理的。
一旦应用程序投入生产，它就是一个大而复杂的系统的一小部分。不再仅仅是应用程序的工作，而是关于应用程序周围的所有技术，从网络基础设施到分布式系统。Dynatrace 的一项研究发现，平均来说，单个交易使用 82 种不同类型的技术，这使得试图诊断生产中的性能问题来源如同大海捞针。
由于这种复杂性使得难以准确诊断问题根源，大多数问题并没有得到真正解决，只是简单地修补。更糟糕的是，匆忙交付修补往往容易造成其他问题，每过一天，问题就越来越严重。
正如前面已经介绍过的，传统 APM 是高层次的，足以告诉你存在一个问题，并指出受影响的一般区域。它们的目的是监控难以置信的复杂基础设施，所以一般的健康报告在运营团队生产场景中非常有用。但是，传统 APM 对于那些希望诊断问题根源的开发团队来说并不重要，因为他们没有提供详细的根源分析。当检测到问题并创建了报告将其传递给开发团队时，可能需要在分阶段环境中使用其他工具集的性能专家采取可操作的数据。
通常，应用程序问题可能是有条件的，很难再现，问题可能与客户的部署环境相关，这也让问题修复变得复杂起来。
修复性能问题
这是传统 APM 最为暴露的领域，因为问题最终由开发人员解决。以生产为中心的 APM 并不与开发人员的日常工作流程保持一致，因此开发团队采用是一个挑战。开发人员已经在处理紧迫的期限和产品压力，因此传统 APM 的复杂性并不值得他们花时间去弄清楚如何获得可操作的数据。
最重要的是，在开发环境中，传统 APM 被认为是绝对的矫枉过正。毕竟，它们是为操作而开发的，并且具有许多开发人员不需要的功能。这些 APM 解决方案只能指出问题的大致方向，但不提供低层次的数据演示，以迎合开发人员解决问题的需要。因此，企业在解决传统 APM 问题时经常会遇到以下问题。
没有修复验证可用。在开发机器上设置和配置传统 APM 是一项可能回报很少的大任务，因为它们不提供有助于在开发环境中隔离，修复和测试问题的功能。传统 APM 无法为开发人员提供即时反馈，因此他们可以看到代码更改如何影响他们正在处理的应用程序性能。
为了验证错误修复，开发团队必须等部署到生产阶段。如果 bug 存在，那么修复测试周期在时间和业务影响方面会非常昂贵。代码所有者和生产问题的表现之间的长反馈循环使修复更加复杂。
修复有问题的代码往往涉及代码的开发人员，由于开发代码通常需要几个月的时间才能发布到开发环境中，开发人员直到编写代码后才看到这个有问题的代码。在这一点上，可能对代码已经不是很熟悉了，而其他代码可能已经构建在有问题的代码之上，使其成为大型代码库的一部分。在研究，复制和解决问题所需的时间中，可能会影响成百上千的客户。
小贴士
大多数公司目前处理绩效管理的方式被打破了。当你等待生产来解决应用问题时，你的客户会在你做之前找到它们。而当你把生产中发现的问题反馈给开发团队解决时，如果你在开发阶段或测试阶段就开始解决问题，那么花费的时间就会更长，成本也更高。每个团队，特别是 DevOps 专注的团队，都应该仔细研究如何提高发现，诊断和解决性能问题的速度。
如果没有及早测试，客户就会变成你的测试人员。如果将真实用户置于未经过性能测试的产品代码上，这对于丢失客户是一个很好的选择。
传统 APM 是为操作而构建的，对于生产来说必不可少，但不是为开发人员进行测试和开发而构建的。相反，开发人员需要寻找专门为开发和测试而构建的 APM 工具，尽早将工具集转向以开发为中心的解决方案。
关于传统 APM 让开发者瞬间崩溃的三大问题是什么问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
