衡量可用性的第三种方法是监控站点上的服务的可用性。显然，如果你的站点创建了分隔服务的故障隔离道或泳道，那么这种衡量方法就更容易实现。无论你的站点是用哪种方法实现的，衡量服务可用性通常都是通过监控一个模拟用户的操作实现的，而这个模拟用户通常是一个执行某种任务的脚本，如登录、运行报表等。然后用这个模拟用户就可以衡量你的可用性。

衡量可用性的第三种方法是监控站点上的服务的可用性。显然，如果你的站点创建了分隔服务的故障隔离道或泳道，那么这种衡量方法就更容易实现。无论你的站点是用哪种方法实现的，衡量服务可用性通常都是通过监控一个模拟用户的操作实现的，而这个模拟用户通常是一个执行某种任务的脚本，如登录、运行报表等。然后用这个模拟用户就可以衡量你的可用性。


 
例如，如行一次。如果任何一个脚本运行失败了，它就会给一个通讯组列表发通知。当这个服务恢复后，果你想监控5个服务，即登录、报表、付款、发帖和登出，那么你可以创建5个脚本，每5分钟运服务受影响了。测试脚本才会停止发送故陈通知。采用这种方法，你可以通过邮件掌握精确的停机时间以及什么作为示例，我们假设为上述5种服务建立了这种监控方法。我们从上午9点45分开始收到登录服务出问题的邮件，直到上午11点15分才停止。这表明我们的一一个服务停机了一个半小时。一种简单的计算可用性的方法是取停机时间的1/5，因为我们5个服务中的一个出了问题。这样得到的停机时间是18分钟，计算方法如下:服务中断时间= 1.5小时=90分钟受影响的服务数量=1总的服务数量=5
 
90分钟x 1/5= 18分钟
 
这种方法的确有些局限性或不利之处，但对于衡量停机时间对客户的影响来说，它却是相当精确的方法。这种方法的一个主要局限是只能监控那些你为此构建了脚本的服务。如果你没有构建脚本，或者不能准确地模拟真正的用户，那么你的监控就不那么有效了。显然，你需要监控你的应用提供的最重要的服务。虽然要监控所有服务不太现实，但主要服务绝对应该受到监控。另一个局限性是并非所有用户都同样地使用所有服务。注册流程只有新用户才使用，而登录流程是所有已注册客户都会使用的。难道所有的流程都要有相同的权重吗?你可以根据重要性或者用量给每个流程设置一个权重，这样有助于更加精确地计算出每个流程的可用性对客户的影响。这种方法还有一个局限性是，如果你在自己的网络中监控你的应用，可能就体验不到在你的网络之外的客户受到的影响。如果你的服务中断是由你的ISP引起的，那么这个APP开发的局限性就更加突出。即使这种方法具有这么多局限性，但它的确是一一种相当好的以客户为中心的可用性衡量方法。