应用程序性能成熟度的六个级别

一级:希望和祈祷

许多公司会迭代地构建业务应用程序，从概念验证开始，然后利用创造性的内部和外部人才将概念构建到一个工作原型中，然后将其扩展到产品中。

我见过这样构建的系统能够提供非常强大的创新思想。挑战在于，它们的设计往往不考虑如何操作。

我曾见过基于云的基础设施构建于基础之上，具有多租户代码库，没有监视集成。

结果如你所料，对所有人来说都是一段艰难的学习经历。

2级:心跳

没有计划监视可用性或性能的公司，通常会在发现问题后添加自定义系统，因为这似乎是一种低成本、快速解决问题的方法。

通过构建用于ping特定服务器的脚本并将输出导入到日志文件中，可以在仪表板上显示数据并提供成就感。

我看到很多公司甚至承担起了支持的责任，每30秒在他们的web服务器实例上按一次F5来确认他们还在工作。和利用海外资源,他们可以做这个24×7材料预算要求。

当它不工作的时候，它就会工作。这时，企业意识到，仅仅因为服务器有一个脉冲，网站显示一个登录页面，这并不代表用户的可用性或性能。问题依然存在，不管你刷新了多少服务器或web页面，一个红着脸的客户在电话上抱怨他们每次都无法执行他们为赢得的服务而付费。

3级:APM

应用程序性能监视(APM)已经被接受了几十年。这个想法很简单，您需要监视技术的关键参数，以确保一切都按预期运行，如果有任何东西运行速度低于预期，或根本没有运行，您将收到警报。

但个人系统不再是商业上的问题。有了冗余和故障转移，问题通常不是单个系统资源失败的问题。现在的问题要复杂得多。APM系统会提醒您每一个细微的差别，并且很难从大量的假阳性中识别出关键的警报。当一系列关键事件取出业务流程时，识别和纠正根本原因的难度可能与使用heartbeat警报一样高。

许多APM解决方案的客户发现，他们需要更多关于他们的APM供应商解决方案所提供的环境元素的知识，尽管数据表上的支持组件列表上有一些五颜六色的标记。

第4级:具有深度脚本的APM

APM解决方案的客户开始向他们的应用程序添加代码，以开始提供他们的APM解决方案，他们需要能够理解所有可用的警报。在他们知道之前，他们的操作团队正在管理数百万行代码。该代码需要维护，以支持随着业务的发展而实现的平台、基础设施和应用程序的所有更改。管理这段代码的团队总是在为保持最新的代码而奋斗，随着员工的不断变化，这将成为他们提高性能能力的一个昂贵的限制因素。

询问任何CIO或运营总监关于他们维护的作为APM解决方案一部分的脚本的代码库，您将会看到关于挫折的字典定义。

5级:事务跟踪

虽然作为一种技术的事务跟踪不仅被那些监视业务应用程序的人使用，它还提供了一个重要的步骤，以改进业务对客户使用其应用程序时的体验的理解。

事务跟踪允许在业务事务经过的每个步骤中查看它。例如，您可以跟踪一个事务，从用户访问一个网站的那一刻起，一直到事务完成，用户离开该站点为止。

单个事务可以通过数百个系统移动，但是通过了解它是如何流动的，您可以在用户之前看到问题的指示器。

APM类型系统捕获的所有数据现在都可以在上下文中考虑。计算事务的实际数据。

这与APM的区别是深远的。操作团队现在可以按照应用程序所有者的设想监视业务。共享的目标允许应用程序堆栈的所有部分考虑相同的期望结果，从而缩短了对动作的决定时间。当问题发生时，它们会被迅速识别和纠正。

对用户的影响也是深远的，他们可能会看到完全没有可用性问题的性能。

除了第5级之外，改进还允许操作团队做得更多，效率更高。

第6级:具有机器学习的事务跟踪

使用基于机器学习的人工智能，可以使用事务数据来确定问题，并从最细微的指标中预测所需的操作。

警报没有提供对最可能的原因和最有效的行动的分析。更多流程的自动化允许增加规模。

一旦一个企业达到了其成熟度的第6级，他们就会使用最新的最具创新性的解决方案，并且能够以业务的速度增长业务，而不会看到成本的直线增长。

它们已经达到了规模提供自身经济优势的地步。