如何从绩效监控中获得业务价值？
从历史上看，绩效监控一直是产品和业务所有者不重视的领域。 监视解决方案公开的诸如延迟，吞吐量或资源利用率之类的术语可能令人困惑或完全恐惧。
这导致性能方面很难与积压的其他任务竞争。 将下一个令人敬畏的功能与性能优化任务进行比较时，前者几乎总是被优先考虑。
您会本能地感觉到性能会以某种方式影响最终用户体验您的IT解决方案的方式。 您还相信更快的速度可能会转化为$$$。 但是，如果在性能改进和$$$之间没有明确的关联，则可能很难证明对性能的投资是合理的。
如果有一种方法可以衡量性能提升的投资回报率，该怎么办？ 如果您可以根据对业务指标的影响来衡量和设置绩效目标该怎么办？ 如果您能接受以下三页的内容，我将为您提供如何链接两者的指南。
了解性能领域
在开始计算美元之前，让我们开始了解可以改进的性能的不同方面。 在理解了延迟，吞吐量，可用性和容量这两个术语的含义之后，我将指导您通过思想框架为每个类别设置业务目标。
潜伏
延迟是系统输入和（所需）结果之间的延迟。 例如，对于Web应用程序，延迟是指从最终用户按下“提交”按钮到浏览器中显示“您的订单已成功处理”消息所花费的时间。
引入延迟监视时，应避免两个常见的陷阱
- 提防平均值/中位数。 监视的等待时间未根据钟形曲线正态分布进行分配。 相反，它匹配长尾巴分布。 较长的尾部分布意味着大多数事务的等待时间很短，但是越来越少的事务将确实表现很差。 通过显示延迟分布而不是平均值，可以放大长尾巴，并查看90％，99％和99.9％的延迟百分位数的表现。
- 远离监视整个系统的延迟。 而是监视每个业务操作的延迟。 这使您能够了解特定业务服务的行为方式。
当您能够监视单个服务时，您将得到类似于以下示例的信息，其中暴露了特定服务的延迟。 可以立即看出，延迟遵循长尾分布：
如果您是性能监控领域的新手，则这可能是您应该开始监控和熟悉的方面。 易于监视和理解，它为了解最终用户如何根据响应感知您的应用程序奠定了第一个构建块。
通量
系统的吞吐量是按每个时间单位完成的操作来衡量的。 例如，每分钟支付100张发票或每秒编码10,000分钟的Full HD视频。 因此，似乎可以很容易地监视吞吐量，就像计数每个时间段的用户交互一样，如以下示例所示：
在现实世界中监视吞吐量时，您最终会发现它并不像定义所规定的那么琐碎。 典型的应用程序不执行单个操作，而是以可变的频率执行非常不同的活动。 这将监视吞吐量从看似简单的工作变成了相当复杂的任务。
如果您不是监视领域的新手，我建议您先跳过对吞吐量的监视，并在解决其他方面时回到本主题。
可用性
吞吐量和等待时间都是用于监视操作系统的良好指标。 但是，每当整个系统或系统中的某个特定功能不可用时，就无法使用这些指标，因为在跟踪用户重定向到错误页面的速度方面没有真正的价值。
为了跟踪此类情况，系统或特定功能的可用性受到监视。 监视可用性的示例包括诸如“今天，在100％的时间内都可以使用产品推荐”或“从凌晨2点到凌晨5点连续三个小时添加到购物车中遇到可用性问题”这样的语句。 要可视化，请查看以下示例：
当企业主实际上可以为停机时间问题分配一美元的价值时，可用性是一种罕见的情况，因此很可能是要涵盖的第一个监视方面之一。 但是，这里要避免的一个错误是仅监视系统范围的可用性，而不是跟踪特定业务功能的可用性。
容量
容量要求对可以满足延迟，吞吐量和可用性目标的环境施加了其他约束。 这些要求可以用计算资源或冷硬现金来表达。 这是如何描述此类要求的示例：
- 系统必须部署在内存少于512 MB的Android设备上
- 该系统必须可在Amazon EC2上部署。 所需的最大实例大小不得超过配置c3.xlarge（8 G，4核）
- 来自Amazon EC2的用于运行系统的每月发票不得超过$ 12,000
因此，在满足其他性能要求时必须考虑容量。 借助无限的计算能力，可以实现任何种类的性能目标，但是在现实世界中，预算和其他限制因素往往会限制人们可以使用的资源。
但是，容量规划中的常见陷阱与上述情况完全相反。 正如本分析所揭示的那样，90％的系统超出了2倍的超额配置。 因此，除了担心容量不足之外，您还应关注现有资源的利用率，并在合理的情况下缩减架构规模以降低成本。
在实践中运用知识
在熟悉了性能监控的四个不同方面之后，您现在已经准备好将特定方面与特定业务指标链接起来。 首先，让我们将四个不同的方面分为两类：
- 您可以将延迟和可用性视为最终用户体验的关键部分。
- 另一方面， 吞吐量和容量会影响运营成本。 提高吞吐量和减少容量要求都是降低站点运行成本的好方法。
通过以上内容，我们可以开始在业务目标和不同的绩效监控方面之间建立链接。
可用性
服务的可用性是最容易解决的问题，因此让我们从这一点开始。 当您的整个系统不可用时，某些区域（例如电子商务或内容站点）可能已经知道中断对业务的影响。 通过先前的中断，您应该已经有可用的数据，因此，当用户无法购买任何商品或广告收入降至零时，您可能知道每分钟损失多少美元。
但是，在许多情况下，系统中执行的活动与美元并没有很明显的联系。 间接链接仍然存在–但是，必须直接通过特定于域名的中介步骤，才能直接转换为美元。 如果没有会计软件，则可以通过测量帐户*闲置的时间来计算损失。 在医学或911服务等极端情况下，中间步骤甚至可以衡量人的生命数量。
通常无法跟踪的是在某些情况下特定服务的不可用或特定服务的不可用。 当所述电子商务站点可用但用户无法将商品添加到购物车时，其影响实际上等同于全面中断。 没有美元能如愿以偿。
在特定情况下，衡量或与业务影响联系起来可能会比较棘手。 如果所述电子商务网站的“相关产品”推荐算法停止对特定产品类别有效，该怎么办？ 影响可能是错过了加售，这应该反映在平均订单量中。
因此，如果您不跟踪整个系统的可用性或缺少有关特定服务无法运行的信息，请继续并开始监视可用性问题，以更好地了解问题的严重性。
潜伏
从历史上看，延迟一直很难与业务影响联系在一起。 可用的研究描述了各个应用程序，似乎并不直接适用于您的业务。 例如考虑以下权利要求：
- 增加1秒搜索时间， 搜索次数在Bing下降了1.5％ 。
- 亚马逊的A / B测试表明，加载页面所花费的每100ms的时间使亚马逊 的 销售量 减少了 1％ 。
- 根据Akamai的说法，遇到崩溃，冻结或渲染时间缓慢 的在线购物者中有75％ 不再从该网站上购物 。
除了确认直觉是“越快越好”，上述知识似乎没有什么好处。 但是，如果您进行更深入的研究，以上内容实际上包含了一些成分，这些成分使您可以更具体地回答问题。
关键在于将特定操作的执行与用户行为联系起来。 如果这看起来过于理论化，那么让我们从SaaS业务注册转换率看以下示例：
在上面的图表中，SaaS业务已按照特定用户的表现跟踪了用户体验。 然后，通过经历的平均延迟对数据进行分类，并用图表上的蓝线表示。 还测量了这些用户的转换率，并用红线将其绘制在图表上。
然后暴露的是，性能与有效衡量任何SaaS业务的关键指标之一之间的明确关联。 您可以立即看到
- 经历平均三秒钟延迟的6％的用户转换。
- 当平均等待时间降至4秒时，转换率急剧下降至3.5％。
使用上面的数据，您可以在绩效改善活动中添加一个清晰的数字。 现在，您不仅可以在性能改进后希望事情有所改善，还可以测量改进前后的数据，并获得清晰可衡量的ROI。
让我们尝试使用上面示例中的数据来衡量ROI。 我们的目标是缩短目前平均等待时间为5秒的一半用户的加载时间，并将其减少到三秒。 目前，我们在5秒的存储桶中有400位用户，其中只有12位获得了转化。 改进之后，我们预计其中200个用户将迁移到3秒存储桶中，这将为这200个用户带来6％的转化。 这意味着在相同的400个用户中，您现在将获得18次转化。
将转换的增加与此类用户的预期寿命值联系起来，现在很容易看到您必须从特定的性能改进中获得多少。
容量
容量是下一个方面。 如果您还记得，我们声称容量会影响您的成本，因此，让我们看看监视容量如何可以帮助您控制成本。
为此，让我们再次使用示例。 第一个将讨论过度配置部分。 让我们考虑一个部署在十个具有2个CPU和8G内存的Amazon EC2 m4.large机器上的电子商务站点。
现在，使用Amazon EC2定价信息，我们可以应用基本数学来计算实例的当前成本：
- 大型实例在美国东部可用区中的每小时成本为每小时12美分。
- 假设所有10台计算机的嗡嗡声都是24×7，我们可以看到，在30天之内，EC2实例账单将导致上述机器的月账单为864美元 。
我们还假设监视那些机器上的系统指标可以发现实际内存使用量永远不会超过3.5G。 这意味着在内存方面，实例超额提供了两倍以上的资源，并且在t2.medium实例上运行的应用程序将提供与以前相同的吞吐量和延迟。 比较价格，我们现在可以应用类似的数学公式来揭示：
- 在美国东部可用区中型实例的每小时成本为每小时5.2美分。
- 再次，假设使用量为24×7，则此类实例的每月账单将为374美元 。
通过这个非常简单的练习，我们找到了一种方法，通过消除未充分利用的容量，如何将EC2实例的基础结构成本降低2倍以上。
为了直观地看到收益，请查看以下示例，该示例源于我们自身基础结构变更的最新变更。 该更改导致在使用相同数量的实例小时数的同时，Amazon账单中的成本大幅降低：
相反的例子很难解决。 例如，如果所述实例每天超过30分钟的CPU饱和度超过95％，则可能是容量不足，并且对延迟和吞吐量指标都造成了损失。 在这种情况下，您需要在增加基础架构成本和优化源代码之间做出选择。
在实践中应用上述技术时，要跟踪的关键指标是整个基础架构成本与客户带来的收入的比率。 业务部门可以设置一个明确的阈值，不应超过该阈值，例如“在基础架构上可以花费不超过30％的客户收入”。 与上述示例类似，监视所有资源可为您提供一种跟踪这些成本中心并防止成本攀升至利润率的方法。
通量
与业务目标关联的最后一个方面是吞吐量。 与容量相似，我们将吞吐量视为一种削减成本的机制。 为了理解可以将吞吐量视为降低成本的说法，让我们再次看一下容量部分中使用的示例。
电子商务站点在10个等效节点上实现了负载平衡。 所有这些节点都执行了类似的操作-响应产品搜索，将商品添加到购物车，推荐相关商品并签出购物车。
由于业务的成功，很可能引入了负载平衡–由于站点的普及，在单个节点上部署解决方案不再可行。 为了做出响应，IT选择横向扩展站点。 这样，每个节点只需要服务流量的1/10。
让我们假设该站点每天接待500,000位访问者。 为了简单起见，让我们还假设负载在时间上是均匀平衡的。 这意味着每个节点每天需要服务50,000个用户，或者每小时需要服务约2000个用户。 我们还假设系统指标向我们表明，资源（CPU，内存等）的使用接近最佳容量。
如果现在市场营销声称下个月他们希望使用量翻番，该怎么办？ 现在，您每月将面对1,000,000个用户，而不是500,000个用户。 从商业角度来讲，这是一个好消息，这意味着需要就如何处理额外的流量做出决定。
第一个解决方案是显而易见的–有了可伸缩的体系结构，您可以通过增加容量和为流量提供服务的节点数量加倍来响应需求。 但是，如果成本水平过高，则另一个响应可能是提高吞吐量并重新设计站点，以便每个节点每小时可以处理4,000个用户，而不是当前的2,000个用户。
哪种解决方案适用是一个情况决定，但要具备相应的知识，您将准备使用最佳解决方案进行响应。
带走
如果您是企业或产品所有者，那么监控世界不必属于IT的黑暗角落。 上面的章节说明，通过性能监视可以为您带来实际的用户体验。 此外，跟踪诸如容量和吞吐量之类的指标将使您获得更高的透明度并控制成本结构。
如果您受此帖子启发，现在正试图找出从哪里开始以及使用什么工具开始工作，请将对不同监视解决方案的分析添加为书签，以便您熟悉域中的不同供应商。 为我们的技术感到自豪，我推荐我们自己的Plumbr首先用于性能和可用性监视 。
如果您来自IT部门，则以上指南为您提供了一个框架，可以为性能优化任务证明ROI的合理性。 如果您希望性能提高达到积压的顶部，则必须将其与商业利益相关联。 使用本文中描述的方法，您可以开始在性能方面取得进步。
翻译自: https://www.javacodegeeks.com/2016/05/derive-business-value-performance-monitoring.html