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