招标代理服务收费管理

运营任何重要的IT服务都是一项复杂的工作。 建立一支优秀的运营团队时，需要牢记多个方面。 这些方面之一是服务级别质量的透明性。 为了避免造成混乱和指责，每个良好的运营团队都已同意一定的质量水平，所服务必须匹配。

使用不同的指标衡量质量，并与预期进行比较。 当测量值偏离期望值时，您将有强烈的信号需要采取行动。 为了使您有所了解，用于表示运营质量的指标通常采用类似于以下示例的形式：

• 发票生成器必须能够在99％的时间内每小时生成10,000张发票
• 网上商店中的最终用户互动必须在99.9％的时间内完成且没有错误
• 产品搜索必须在1,500ms以下的99％时间内响应，而在5,000ms以下99.95％的时间内响应。

上面的三个示例以三种不同的方式表达了对服务质量的期望。 每个术语都对特定指标提出了期望：第一个指标关注吞吐量，第二个指标表示可接受的错误率，第三个指标是对延迟的要求。

但是，在某些情况下，很难或不可能直接测量所需指标。 在这种情况下， 代理指标用作代表不存在直接措施的现象的间接措施。

在这篇文章中，我将使用我们自己的操作中的实际情况，并将以此为例来解释IT操作中代理指标的概念。

代理指标的实际应用：一个例子

为了理解该示例，让我们从所遇到问题的一些背景开始。 问题源于Plumbr如何接受和处理从我们的代理商那里收到的监控数据。 此处理的简化过程如下所示：

我们的数据处理管道分为多个微服务，分别在不同阶段接受，处理和存储数据。 每个微服务都是一个独立的批处理流程，只负责一项职责。

当前的问题与监视处理管道有关。 我们需要监视能够多快地使到达服务器的数据可用于从存储中查询。

该流程的要求表示为“必须在1分钟内处理到达Data Receiver的99％的交易。 99.9％的交易必须在5分钟内处理完毕。”

需求很简单，因此可以用作我们是否满足需求的指标。 事实证明，构建微服务的方式无法直接测量整个处理流的延迟。

问题出在批量处理数据上，使得在当前解决方案中无法跟踪监视数据的各个数据包。 因此，我们需要一个不同的指标来确保我们的数据处理管道不会停滞并且无法按照预期的要求进行交付。

通过分析过去几个月中必须解决的事件，我们发现可以对管道进行不同的监视，并使用代理指标 来捕获存在处理延迟的信号 。

再次查看处理管道，您会注意到两个队列将不同的微服务解耦：

我们发现，当队列＃1或＃2变得太长时，我们可以监视队列的长度以捕获信号。 例如，每当数据处理器服务无法跟上数据到达队列1的步伐时，队列1的长度就会开始增长，这表明存在瓶颈。

在队列长度上引入监视已经涵盖了90％的情况，即我们的处理落后。 但是，正如您可能已经注意到的那样，这不会在最后一个队列之后出现瓶颈时向我们发出信号，因此作为最后一道防线，我们还引入了对最终存储中存储的数据量的监控。 Data Depositor微服务不是问题的根源。

因此，我们最终使用了以下代理指标，而不是原始的端到端延迟要求：

• 队列长度在99％的时间内不能超过50,000，在99.95％的时间内不能超过500,000。
• 最终存储必须在99.95％的时间中随时存储250,000至1,000,000个事件

对这些简单指标的监视最终在不满足延迟要求的情况下，在98％以上的情况下正确地向我们发出信号。

我们还最终发现，这方面的问题最常发生在某些客户突然开始向我们发送意外的大量数据时。 因此，基于这些信号，我们能够自动产生专门的服务来处理来自此类客户的数据。 这样可以隔离影响，这意味着流量的突然增加不会导致其他客户数据处理的延迟。 它还引入了额外的处理能力来消化有问题的客户的数据，从而为特定客户更快地解决了（临时）处理延迟。

带走

上面的示例描述了您可能不会很快遇到的特定用例。 但是代理指标的概念更为通用，可以在多种情况下部署。 例如，您可能面临与客户端延迟有关的要求，但可能只能在服务器上测量延迟。 监视服务器端延迟现在可以用作代理指示器，以揭示服务器端组件是性能问题根源的情况。

不要误会我的意思-每当可以测量直接指标时，您都应该始终喜欢这种方法，并避免使用代理指标作为信号或质量测量的来源。 但是，在无法直接监视实际指标的情况下，理解和使用代理指标是保持工具带的宝贵概念。

翻译自: https://www.javacodegeeks.com/2017/06/use-proxy-indicators-service-management.html

招标代理服务收费管理