系统中的故障场景建模(2)

　　在下一节中，我们将介绍解决方案的一些特性。我们需要将这些特性整合到解决方案的架构中，并且需要在创建故障模型时考虑这些属性。
　　第二步. 建立运作指标
　　在识别出解决方案的各种场景以及它们所依赖的不同系统/服务后，我们需要明白系统的正常运作模式是什么。只有这样，我们才能够识别出系统是否存在异常的情况，并可以及时采取主动的应对措施。在这一节中，我们将检查系统的资源约束并通过对解决方案的质量特性进行建模，从而概括出正常的运作模型。
　　解决方案特性可以被划分为两个高层次的分类：解决方案的功能特性和解决方案的运作特性。解决方案的功能特性描述的是该方案提供的实实在在的功能。而解决方案的运作特性有时被称为非功能性需求，它只是确定了该系统会如何运作。
　　这些质量特性包括系统的可扩展性范围，系统在正常或错误条件下的响应时间，系统的可用性等。虽然对最终用户是不可见的，但是解决方案的质量需求将决定系统在业务中的长期价值。
　　我们通常将解决方案质量的一个子集归为解决方案服务品质协议(SLAs)。通常的SLAs包括但不限于：响应时间，可用性，系统支持的并发用户数。
　　你的系统需要满足的SLAs通常取决于业务需要和市场需求。有的时候，达成SLA的期望过早，而在后期对依赖系统的分析中会发现，预先达成的SLAs其实是不可行的。
　　在这一节中，我们将考察从SLAs中挑选出最常见的三项。展示我们如何通过着眼于它们的依赖，从而使我们的解决方案可以支持的SLAs更加清晰合理。
　　系统可用性模型
　　对于指定的解决方案来说，可用性往往是SLA列表里排在首位的。当然，所有的软件解决方案都努力的希望达到100%的可用性。但不幸的是，在复杂的解决方案中，系统的功能实现都由一系列其他系统集成而成，这使得要达到100%的可用性极其困难。
　　取决于不同的功能依赖，要计算整个系统的可用性数值非常复杂。然而，我们可以使用以下的公式，来粗略地计算计划中解决方案的可用性。
　　总可用性 = 依赖系统1的可用性*依赖系统2的可用性*依赖系统N的可用性 (译者注：这里原文中可能漏掉了一个省略号，个人感觉应该是如下公式, 总可用性 = 依赖系统1的可用性*依赖系统2的可用性*…*依赖系统N的可用性) 为了能更真实的理解解决方案的功能可用性，并为依赖系统的响应制定计划。可以使用如下图所示的模型来计算基于依赖服务可用性的场景可用性。

场景/服务	订单执行服务	库存服务	客户数据库	商品目录	客户评论服务	系统响应时间
搜索商品				99.50%		99.50%
阅读客户评论					98.00%	98.00%
添加商品到购物车		99.90%		99.50%		99.40%
结账	99.00%	99.90%	99.99%			98.89%

　　我们注意到，上面的例子中，依赖服务各自的可用性将通过应用/服务所属的分组获取到。在大多数的企业场景中，直接从运维团队获取到数据是最精确最理想的方法。
　　系统响应时间模型
　　随着复杂软件解决方案中依赖项数目的增长，系统的响应时间将被串联起来。其中系统响应时间的波动将对整个开发中的解决方案的总体响应时间产生负面影响。
　　最常见的一种容易被忽视的情况是具有父子处理关系的一些场景。当接收到一个包含了很多子项需要被进一步处理的请求时，做出的响应往往有很多的情况。尽管这个问题看起来很琐碎，但是在理解每个调用链的总体响应时间之前，有很多的数据依赖问题需要去解答。
　　为了简便起见，我们将只集中精力于所有参与服务的调用链依赖而不是数据依赖。
　　为了对期望的响应时间建模，我们将重新使用服务依赖项矩阵。这一次，我们不再简单的展示依赖关系，而是清算出每个服务的调用次数。如果再加上各自服务响应时间的指标，表格将如下所示：

原文转自：http://www.ltesting.net