为回答“有问题吗”这个问题提供必需数据的监控器，也为我们衡量是否创造了股东价值提供了关键数据。你也许还记得，以可用性作为一种指标。我们的目标是，对于问题“有问题吗”，总是回答“没有”。如果你能做到这一点， 就说明你具有很高的可用性。从客户的角度和业务的角度来衡量可用性，而不是从技术的角度来衡量它，不仅给你提供了回答“有问题吗”这个问题的工具，还可以拿你的可用性目标来衡量你自己。收人或客户可用性与技术可用性之间的差别非常重要，它们会使组织的文化发生转变，让组织受益无穷。技术专家们长期以来用他们关心的所有设备的可用性的乘积作为长期衡量的可用性。这种可用性绝对有用武之地，就成本、两次故障之间的平均时间、人员需求、冗余需求、存储平均时间等方面的考虑来说，它们是很重要的。但它们与股东或客户关心的东西并没有什么直接联系，股东和客户最关心的是服务可用，并且服务能够带来最大可能的价值。因此，实时地衡量客户体验和产生的利润对于回答我们的第一个也是最重要的一个监控问题以及衡量可用性，相对要有价值得多。只需少量的监控指标，我们就能衡量一个关键的管理指标，确保我们能识别出即将发生的事件和当前发生的事件并作出响应，从而使我们的文化与创造股东价值和客户价值保持一致。
回答“哪里有问题”的监控指标，通常也能为我们的产能规划和余量流程提供数据。这里的原始数据可以帮助我们确定我们的系统中哪里有约束，还会帮助我们把注意力放在水平扩展这些平台的预算上，或者驱使我们改变架构，以便能够更加经济有效地扩展。显然它们在故障和危机发生的过程中，非常有用，而在我们要找出如何尽早隔离这些故障或者如何避免这些故障再次发生的事后分析活动中，它们也是绝对有价值的。这些数据也可以作为性能测试流程的输入，帮助我们改善这一流程。
用于回答“什么问题”的数据对在上一段提到的许多流程都很有用。此外，它还能帮助我们测试是否正确地把系统设计为能够监控的了。软件开发人员应该采用事后分析流程和运营评审流程输出的数据，与我们监控生成的数据和信息进行对比，帮助我们发现和诊断问题。我们这样做，是为了在代码评审和设计评审流程中，使用这些信息，以便我们能创造出更好的、更加智能的监控方案，在问题发生之前就能发现它们，或者在它们发生时，能够更快地把它们隔离起来。
在理想状况下，如果我们采用了一个强大的、预测性很强的网站设计监控方案，那么我们就能预测故障和危机并避免它们，至少应该能够在故障和危机开始引发客户问题以及影响股东价值时，及时发现它们。在许多成熟的监控解决方案中，监控系统本身不仅要负责最先发现故障，还要报告或记录这个故障。
本文地址：//www.qlpinke.com//article/3908.html
