tf-lite量化尾量化_量化可用性

tf-lite量化尾量化

负责Web应用程序的工程师喜欢跟踪的主要指标之一是“可用性”。 让我们研究一下可用于量化可用性的不同方法，以及每种方法的优点和缺点。 如果需要，这将为构建自定义方法提供良好的基准。

为了说明不同的方法，让我们假设一个场景，该场景模拟了正在开发和维护电子商务Web应用程序的工程团队的一些实际结果。 我们的目标是为该电子商务系统的“可用性”得出有意义的度量。 我们将在结帐过程中为应用程序的用户使用以下失败：

• 特殊字符失败：名称中包含常规ASCII字符的用户正在顺利签出。 名称中包含非ASCII字母的用户在填写联系方式时会遇到验证错误，并且无法完成结帐。
• 地理位置故障：结帐流程适用于从欧洲或亚洲进入商店的任何人。 但是，由于CDN服务该地区的用户中断，因此来自北美的用户面临错误。
• 浏览器故障：由于Javascript错误阻止了此操作，因此IE 11上的所有用户不再能够完成结帐。 其他浏览器似乎没有受到影响。

按时间测量

从历史上看，可用性一直是衡量系统可运行时间的一部分，与保持系统可运行所花费的额外时间相比。 根据定义，这是：

可用性（％）=正常运行时间÷（正常运行时间+停机时间）

常见讨论围绕此确切百分比（例如：99.9％，99.95％等）进行。 尽管此方法的优点是一种看似简单的方法，但该方法有许多缺点，因此无法实用。 将Web应用程序划分为许多复合服务时，很少有整个应用程序对其所有用户都关闭。 发现每个用户都享受成功的结果也是同样罕见的情况。 中位数情况是服务部分运行的情况，可以很好地为很大一部分用户提供服务，而其他用户则惨遭失败。

当我们对可用性进行这种理解时，由于没有停机时间，因此将导致该服务的可用性为100％。 但是，没有办法将经历三个示例故障的用户包括在内。 因此，仅使用时间来表征Web应用程序的可用性不是一种合理的方法。

我们如何才能以更符合我们业务目标的方式更好地衡量服务可用性？ 如果是电子商务站点，则业务目标是出售商品并赚钱。 也许我们可以尝试衡量假设的可用性问题对业务的货币影响？ 让我们找出下一步。

以货币计量

缺乏使用购物车的能力意味着，除了用户体验之外，企业的收入也会受到影响。 假设购物车的平均大小为$ 40，则该表现在转换为：

失败	结帐失败的次数	金钱损失
SPL字符	3	$ 120
地理	21	$ 840
浏览器	38	$ 1,520

然而，实际上，能够将确切的收入数字固定到用户交互是非常罕见的。 如果要进一步深入到结帐流程，则可以使用诸如转换率，可用性试探法和其他因素之类的措施来扭曲画面。 我们是否可以确定遇到错误的IE11用户实际上没有进行购买？ 也许他们使用了其他浏览器并完成了购买？ 也许他们从来没有打算买任何东西？

您越远离应用程序中处理收入的部分，将收入与经历的故障关联起来就越复杂。 例如，“无法加载实时聊天窗口小部件”如何对应于收入损失？ 当使用内部生产力应用程序时，收入甚至都不是一个因素，这种方法将是完全不合适的。

衡量是金钱的代理

我们已经看到了按时间或收入来表征可用性的一些缺点。 是否有办法将这些相互作用的影响归一化为除这两个因素之外的其他因素？ 根据您所从事的业务，可以使用以下几种方法：

• API调用失败次数。
  • 给出应用程序运行状况的合并度量。
• 遇到故障的用户数。
  • 客观衡量谁正在经历失败
• 用户互动失败的次数。
  • 通过监视用户交互产生的所有请求和Javascript调用

这是查看将这些理解应用于这些失败的一种方法：

失败	受影响的使用者人数
SPL字符	2
地理	10
浏览器	9

翻译自: https://www.javacodegeeks.com/2019/02/quantifying-availability.html

tf-lite量化尾量化