系统可用性的计算方法
文摘
2024-08-01 14:08
日本
![]()
可用性是评价互联网平台表现最重要的因素之一。硬件故障、网络问题或者应用停止服务就等于平台损失收入。了解和掌握平台可用性的计算方法，会有利于业务和技术主管在衡量研发、测试和运维团队的工作业绩标准上达成一致。而对客户而言，当他们需要平台的服务时，没有比可用性更重要的度量指标了。企业中的每个人都应该把可用性作为个人目标的一部分。技术团队的每个成员都应该知道每个服务中断对可用性的影响。对于服务中断，人们应该互相质问并且共同努力确保这些问题尽可能少发生。作为公司的部分目标，可用性影响着员工的工资、奖金和晋升等等，因此他们有巨大的动力去关心这个指标。在讨论计算可用性的不同方法之前，我们需要确保对可用性的基本定义有共同的认识。用互联网的术语说，可用性是指在一个特定的时间范围内，网站可用的时间长度，即用户可以使用该网站的时间除以总的时间。举个例子，如果测量某个平台一周的可用性，最多可用时间是 7 天 * 24 小时/天 * 60 分钟/小时 = 10080 分钟。如果网站在这一周内有 10010 分钟是可用的，那么可用性就是 10010 / 10080 = 0.9935 。可用性通常是以百分比表示，所以该平台本周的可用性是 99.35% 。
对可用性最简单最直接的度量是硬件设备的正常运行时间。依靠SNMP陷阱，我们可以利用捕捉设备故障时间的监控工具，监控硬件基础设施的可用性，并跟踪记录网站硬件出问题的时间。不管要计算哪个时间范围的可用性，团队都可以通过查看监控日志，确定问题服务器的数量以及这些问题的持续时间。【停机时间=硬件中断的总时间 *（问题服务器的数量 / 服务器总数）】例如某个网络接入交换机失败，主机没有安排冗余双连，导致连接它的 12 个网络服务器有 1.5 小时无法连接，该网站有 120 个网络服务器，因此总的停机时间计算过程如下：确定了停机时间就可以计算可用性。继续上述的例子，假设我们要度量这周的可用性，而这是本周唯一的中断事故，因此我们有 10080 – 9 = 10071分钟的正常运行时间。可用性是正常运行时间与总时间的百分比，也就是 10071/10080 = 99.91% 。如上所述，这是一个非常简单的计算可用性的方法。当然，网络服务器的表现不一定完全代表客户的体验。如果仅仅是因为服务器不可用，这并不意味着该网站对客户不可使用。事实上，如果网站的架构合理，单一硬件的故障可能不会对客户带来任何影响。但是，这并不意味着我们可以忽略度量服务器和其他硬件的可用性。相反，设备可用性会影响到服务的可用性，服务本身的可用性是最重要的指标。可用性的最佳度量将直接关系到股东价值的最大化；反过来又可能对用户体验产生影响，进而影响公司的收入或成本。因此，使用设备或硬件可用性作为衡量系统健康状况的重要指标，还需要更复杂的以客户为中心的度量指标。确定可用性的第二个方法是以客户做为“晴雨表”来评价网站的表现。这种度量的表现形式可以是客服中心接到的用户电话呼入数、电子邮件的数量或者在线论坛的帖子数。通常，拥有完善客服中心的公司，对客户寻求支持的电话和电子邮件会进行实时跟踪。呼叫中心每天都会统计这些数据，密切留意接到了多少电话和电子邮件请求以及多大程度可以满足用户的呼叫服务请求。如果服务请求量突然出现了明显的尖峰，那通常应该是发生了故障。那么如何把呼叫数量变成可用性度量呢？这里有很多方法可以选择，但都是不准确的。一个简单的方法是分别统计正常时间段的呼叫数量和服务中断期间的呼叫数量；这两个数值分别代表着 100% 的可用性和 0% 的可用性。呼叫的总数量减去正常的呼叫数量，从而得到网站服务中断而引发的呼叫数量，再将其转化为网站完全不可用的时间。【停机时间=中断时间 *[（异常呼叫量-正常呼叫量）/（总呼叫量–正常呼叫量）]】举个例子，假设我们通常每小时接到200个客户的电话。当网站彻底瘫痪时，通话量会达到每小时1000个。从上午9点开始，我们观察到每小时有400个通话发生，这种趋势一直持续到中午，然后下降到每小时150个。我们假设该网站在这段时间内出现了一些问题，这个怀疑最后得到了运维人员的证实。我们把从上午9点到中午的时间标记为一次宕机。宕机率计算过程如下：超过正常水平的呼叫量=400-200=200呼叫/小时超过正常水平的百分比=200 / 800 =1 / 4 =25%
虽然这个度量确实更加接近用户的真实体验，但也存在问题和不准确性。首先，问题出现时，客户不太可能马上打电话。大多数客服中心要求客户在电话线上等几分钟甚至更长的时间。许多消费者因为不愿意等而懒得打电话，所以可能只有反应最强烈的客户才会打。例如，在 eBay ，实际上受影响客户中只有大约 1% 至 5% 左右的人会打电话联系。该统计指标扭曲了实际情况，反应最强烈的客户，往往是那些最高级的用户。这个测量指标的另外一个问题是，很多 Web2.0 和 SaaS 公司没有客户支持中心，他们很少有机会与客户直接接触，很难及时了解是否真正发生了问题，以及问题持续的时间和影响。再有一个问题是，用户每天在不同时段呼入的情况变化很大。为了弥补这一因素，必须要有每小时的测量指标来做比较。类似前面讨论过的硬件度量，客户接触率的度量是跟踪可用性的一个很好的指标，但是我们不能完全依赖它来进行可用性的评估。客户温度或者客户脉搏（无论你想怎么称呼），是观察客户群对新的网页布局、功能集成或付款模式如何反应的非常好的方式。这种反馈对确保产品经理专注于客户需求和听取客户意见是非常宝贵的。但是对真实可用性的测量，还需要一些更加复杂的方法。测量可用性的第三种方法是监视网站上服务的可用性。如果网站有故障隔离泳道来保持服务的分离，这种测量会更加容易进行。你可以通过脚本来监控模拟用户执行某些任务的能力，如登录和运行报表等。该模拟用户就成为可用性的度量目标。举个例子，我们想要监控登录、报表、支付、发布和注销五个服务，于是分别创建五个脚本，每五分钟运行一次。如果任何脚本失败，它就会通知预先定义好的联系人。服务恢复后，测试脚本会停止发送故障通知。通过这种方式，我们可以通过电子邮件准确地跟踪停机时间，以及哪些服务受到了影响。上午 9 点 45 分，我们开始收到登录服务出现问题的电子邮件，11 点 15 分停止发送。这样就测量出登录服务出现 1.5 小时的停机时间。因为五个服务中有一个出现问题，所以计算总的停机时间的简单方法是把停机时间除以5，计算过程如下：这个方法有一定的局限性和缺点，却是一个相当精确地测量对客户影响时间的方法。主要局限是该方法只限于有脚本监控的服务。如果不创建脚本或者不能准确地模拟真实的用户，监控就不那么有效了。因此我们不可能监控每个服务，但是应该要覆盖主要的服务。另外一个局限性是，并不是所有的用户都均等使用所有的服务。例如，只有新用户使用注册流程，所有存量用户都使用登录流程。每个业务的权重都不一样。我们可以按每个业务的重要性或者使用量添加权重，以便更准确地计算出每个业务可用性对客户的影响。最后，这种方法还有一个局限性就是如果你从网络内部进行应用监控，监控不一定会受到与客户相同的影响，尤其是当故障是由网络服务提供商造成的。话说回来，尽管这种方法在监控网站可用性时有一定的局限性，但是它确实提供了很好的以客户为中心的可用性测量。第四种确定可用性的测量方法是使用第三方监控服务。这种方法和第三种方法非常相似，但却克服了在内部网络监控的限制，并且还有可能包括更复杂的脚本，以模拟更真实的用户体验。它们主要的概念基本相同：配置要监控的服务，当出现问题时，向第三方服务报警联系人发出警报。目前，市场上有很多厂商提供这种监控服务，包括Gomez 和 Montastic 等。有些服务是免费的，有些则是相当昂贵的，取决于需要监控的应用的复杂性和多样性。例如，一些优质的监控服务，其监控从许多不同的网络上发起，同时有能力从计算机上模拟用户，这几乎是真实的用户体验。使用第三方监控服务的关键是首先要确定监控要求，包括应用或服务的动态性，需要在多少个不同的地理位置上监控，这种监控的难度多大等。有些厂商能够从几乎任何地区的互联网提供全球性的监控服务；一些供应商能提供对动态网页的特殊监控；其他的可以学习什么是正常的行为，在不需要预先设置阈值的情况下，根据统计学的规律提供动态的警报。最后一种监控方法是根据业务流量图计算可用性，也是我们的首选方法。因为它采用对业务更有意义的收入来表达平台可用性。它需要用关键表现指标，如实时收入，来确定可用性对业务的影响。要做到这一点，我们必须为每个与企业经营业绩密切相关的关键指标（KPI）安排好监控。然后，当发生服务中断时，可以把正常的一天与服务中断那天做对比，以确定影响的程度。具体方式是计算业务流量图之间的面积之差，这部分代表着服务中断时间。实线是正常一天的收入变化曲线（这里的收入是 KPI 监控的），虚线是交通中断那天的收入变化曲线。业务中断从大约下午 4 点开始，并持续到 6 点 40 分网站完全恢复。这段时间两条曲线之间的面积占比可以用来作为对可用性的影响。正如你所看到的，可用性的计算并不那么直接了当，可能会比较复杂。本文的目的不是要讨论哪种方法是正确的，而是要给出几种选择，让大家从中选择一种或综合几种为自己的组织找出最佳的整体可用性度量。绝不应该低估在测量可用性方法上取得共识的重要性，因为它对技术团队和个人目标度量密切相关。非常有必要花些时间，制定出最准确的度量，使之成为权威的可用性指标。----------------------------------了解更多AI在软件研发全流程中的革新与实践，请阅读《ChatGPT驱动软件开发》，--扫描下方↓二维码，即可获得！-----------------------------------想要了解更多关于支付的故事，请阅读《一本书读懂支付》---扫描下方↓二维码，即可获得！-----------------------------------
