俗话说：如果你无法测量它，那么你就无法管理它。目前困惑网络管理的问题已经有所不同了。现在主要问题是数据太多了。由于太多数据，因此全部进行分析是不可能的。而更无法实现的是映射所有这些数据。由于数据过多，因此，我们所获得的只是一大堆没有任何真实信息的数据。

在这个问题上，IT已经长期处于两难境地。我们收集和存储了大量的数据。同时，我们还引用了使用状况、速度和响应时间等所有类型的统计，这些统计虽然描述了基础设备正在运行什么，但是并没有传输我们的业务伙伴需要执行的信息。业务伙伴并不了解技术。网络人员只是想继续他们的工作以及维持网络应有的功能。

网络团队到底能做什么？他们要如何将大量如雪崩般的有效网络数据转变成对业务管理有意义的信息的呢？这里有个过程，它有助于我们识别和转换性能数据为业务信息。在此有四个建议，它们将有助于我们决定哪些数据是重要的以及如何表现它们。

压力可以变为动力

首先，我们必须意识到任何业务人员都不太可能转变成为一个网络工程师。对于你或者对于网络团队中的任何人而言，将技术性能翻译为业务影响是非常容易的。要成为这样的人员，必经之路是扩充见识以及找最有趣的事情来做。说不定，它还可以让你摆脱困境。

确定重点

第二，练习的目标并不是表现或者重建网络状态，而是提供性能的基准。基准是为与业务相关的基础设备的运行是好或者坏进行打分的一种方式。当我们采取行动时，这是我们必须知道的。因此，我们必须知道对于业务管理有着重要意义的重要的性能度量。哪些指标（KPI）决定了它们的分红和评审？

确定与KPI相对应的网络性能参数

第三，我们可能都知道“无法分析”的问题。它发生在分析阻止决策的时候。与获得一个决定相反，它的结果是一个无法终止的确定、理解和分析数据的过程。“参数分析”是类似的情况，分析过程被卡在确定和跟踪参数中。

找出哪些网络参数和/或事件数据映射或影响了KPI。这可能是可操作数据（确定传输数据包的百分比、停机持续时间，等等）,如一个SLA的出现次数，但是也可能是非功能数据（如管理需要的网络元素的能力）。重点是要意识到哪些参数看起来是与KPI关联的。接着是向业务管理员报告和提醒他们的KPI将会发生什么情况。当被告知发生改变的订单过程将导致客户满意度大幅下降时，任何业务管理员都会采取行动，因为订单将需要花费多于50%的时间来处理，而在网络流量中增加了20%来进行通知可能只会引起一些不同的响应时间。

是相互关联还是互为因果？你在意吗？

第四，技术人员往往受制于自身的分析思维。他们把原因和结果联系起来。这对于诊断和修复而言是最佳的策略，但是当我们想要的只是提醒潜在的损害SLA或者提醒业务管理员它对KPI会有负面影响时，这并不是一个最佳方法。

关键在于确定和跟踪影响KPI的指标——不论好坏。相关的事物是一起变化的——但是并不需要在同一个方向上。因此，它们是作为KPI变化的警报的。对于警报目的而言，警报事件是否引发了该问题,或者只是与问题的变化有一个固定的关系，这都不重要——重要的是我们有足够的时间发现并且采取恰当的行动来避免或者最小化负面影响。

因此，一定要考虑非传统指标，如流量到达时间。端到端地查看过程，以便确定上行流（或者下行流）的性能瓶颈。这些并不总会有答案出现，但目的是了解网络代表全过程的一个链路。注意一下我们所关注的边界外的事物，这有可能会是使我们的整体任务变得轻松很多的关键所在。