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

一级:希望和祈祷

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

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

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

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

2级:心跳

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

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

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

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

3级:APM

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

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