当前的商业环境与二十年前相比发生了很大改变，很显著的情况是几乎没有哪个行业的发展能够缺少IT技术作为基础支撑平台的一部分。而提供各种功能的IT系统我们都可以将其分成两个部分来看待，一是借助IT系统来开展业务的相关内容，二是满足业务需要所必须的技术支撑部分，包括了满足业务需求所进行的系统开发、部署上线和确保正常运行，第二部分工作内容的好坏直接影响了第一部分业务的开展，因而就保证第二部分工作内容的高效完成，我们需要关注的内容非常多，这里我们从应用性能管理的角度略做分析。

我们从一个最简单的应用场景开始。假设用户使用浏览器登陆某一个Web系统，等待了20秒之后，跳转到一个错误页面，提示登陆失败，再重复两次，还是同样的情况；1个小时之后用户再次登陆该系统，等待了10秒之后，登陆成功。相信这样的场景很多人都会遇到过，从这个场景我们能看出什么来呢？

首先，毫无疑问的一点，用户对这样的体验绝对是不满意的，如果处理的是一个紧急的事情，体验更是糟糕无比。

其次，业务部分是肯定不希望这样的情况还长期的持续下去，因为这必然会导致用户的流失和交易量的下降，业务部门会要求技术部门确保系统避免此类问题的持续发生。

对于技术部门而言，这肯定是个糟糕的情况，这通常意味着来了一个新问题，很可能还是突发性的工作，需要加班加点研究解决办法，那么就会衍生出后续和一系列的相关工作。

谁来告诉我问题出现哪里？

是应用本身存在问题，还是网络的原因？

是数据中心网络配置的问题还是外部网络不稳定的问题？

网络管理团队告诉开发团队“网络没有问题”，应用上可能存在问题，但是是Web服务器出现问题还是数据库存在问题呢？

为什么之前都是正常的刚才会出现问题呢？为什么现在又正常了呢？下次节假日的时候还会不会再出现问题呢？

为什么用户需要10秒钟才能登陆而不是3秒钟呢？怎么才能让时间缩短到3秒钟？系统进行优化后是不是真的达到了我们期望的3秒钟呢？

所有上面这些问题没人拍拍脑袋就能告诉你，IT系统是一个程序化的产物，能够告诉你为什么用户登录会失败，为什么登录需要10秒钟的，只有系统运行的所产生的数据，而且是生产环境中的运行数据。要避免这样的问题，以及更严重的导致交易无法进行的问题，必须知道系统在处理什么，处理的结果是什么，必须获得应用系统的运行可视性。

系统运行会产生哪些数据？而哪些数据是我们需要看到的？这些数据通过什么样的方式展示给我们是最方便有效的呢？我们需要对这些有清楚认识和明确的期望。

    我们把用户和IT系统的交互类比成一次购买行为，你掏出钱递给便利店服务员说“给我一瓶农夫山泉”，服务员从她后面的冰柜中拿出一瓶水递给你，购买完成。这说明，我们和系统是存在交换的具体“数据”内容的，数据需要“传递”给响应的“对象”的，然后经过“处理”后才返回给你，这里每个环节出现了错误都会导致这次的交互行为的失败，因此我们需要了解系统运行相关的数据包括下面这些内容。

数据从用户A提交到系统处理完成返回结果，数据流经了哪些环节？

这要求我们能够监测一笔完整的交易中数据流经的所有节点。

    每个环节的处理结果是失败的还是成功的？

这要求我们标识出节点的处理结果是成功还是失败。

如果是环节N上处理失败，那么是系统运行依赖关系中的哪个因素出现了问题导致的？这可能是CPU、内存、磁盘I/O或是系统代码执行本身？

这要求我们能够标识出运行依赖各因素的实时状态数据。

为什么这个用户访问需要10秒而不是3秒呢？时间都花销在哪里了呢？应该优化哪个模块呢？

这就要求我们能够监测在整个应用交付链上各个环节的时间消耗。

系统代码出错了错误在哪个模块哪个方法呢？错误信息记录在哪个日志文件中？错误提示信息是什么？

这要求我们能够提供足够详细的运行错误细节。

同样的错误出现了多少次？都有哪些用户收到了影响？

这需要我们能够把错误和用户进行直接关联。

而上面这些问题需要在最快的时间内获得答案，减少不同人员沟通的时间，减少从海量日志中查找错误信息的时间，这要求我们在一个统一的平台上进行所有工作的处理，在一个界面中查看更多的信息，将更多的人工操作交给系统自动完成。

现在系统运行是正常的，以前出现的问题怎么查找？

这要求所有交易出错的历史数据我们都需要能够保留。

满足了上述内容后，我们就可以“看得见”哪个节点出错，从而进行故障隔离，协调具体负责团队进行处理，“摸得着”出错的详细信息，知道了错误影响了多少用户，就能够确定“改得了”系统，明确系统优化的重点和方向。