孤立地来看，这些服务通常提供三到四个九的范围。可用性：
Azure Traffic Manager：99.99％或“四个九”。
SQL Azure：99.99％或“四个九”。
Azure App Service： 99.95％或“三九五”。
但是，在体系结构中结合在一起时，任何一个组件都可能会发生中断，从而导致总体可用性不等于组件服务。
串行化合物可用性
在此示例中，存在三种可能的故障模式： SQL Azure已关闭
应用程序服务已关闭
两者都已关闭
因此，此“系统”的总体可用性必须低于99.95％。我认为这是因为两种服务的SLA是否为：
该服务将在24小时中的23小时内可用。
App Service可能在0100到0200之间
数据库在0500到0600之间
两个组成部分都在其SLA中，但是24个系统中有2个小时无法使用整个系统。
串行和并行可用性
模式主要是：
RegionA中的SQL Server已关闭
RegionB中的SQL Server已关闭
RegionA中的应用服务已关闭
RegionB中的应用服务已关闭
交通管理系统已关闭
上述组合
由于流量管理器是断路器，因此能够检测任一区域的中断并将流量路由到工作区域，但是流量管理器仍然存在单点故障，因此“系统”的总可用性无法高于99.99％。
如何为企业计算并记录上述两个系统的复合可用性，如果企业希望获得比架构能够提供的服务更高的服务级别，则可能需要重新配置？
如果您想注释图表，我已经在Lucid Chart中构建了它们并创建了一个多用途链接，请记住，任何人都可以对其进行编辑，因此您可能希望创建一个要注释的页面。
#1 楼
在阅读了Tensibai的出色答案之后，我意识到我曾经能够为网络分析目的而计算出这个值。我挖出了克里斯·奥格里诺（Chris Oggerino）的《高可用性网络基础知识》的副本，并试图从并非是第一任校长的角度来解决这个问题。每个组件都可以彼此使用：
So
99.95％* 99.95％= 99.9％
并行计算要多一些很复杂，因为我们需要考虑不可用百分比是多少：
计算方法如下：
将两个区域的不可用率相乘。
0.1％* 0.1％= 0.0001％
转换为可用性
100％-0.0001 ％= 99.9999％
将流量管理器的可用性乘以两个区域的可用性。
99.99％* 99.9999％= 99.9899％
结果是整个系统的可用性。
99.9899％是接近99.99％
我最终使用Excel进行计算，这是值：
评论
就是这样，比我的方法更直接（我觉得有必要演示背后的数学:)）
–滕西拜
17年3月30日在21:14
同意，您的答案对数学真的很好。
–Richard Slater
17年3月30日在21:19
SQL Azure是99.99％而不是99.95％
–唐Jeff伟
19年6月11日在15:17
@JefferyTang（可能）是在问题/答案撰写时（我不太记得），实际值并没有改变获取“如何从单个零件SLA计算复合SLA”答案的方法是真正的问题。
–滕西拜
19年6月11日在15:29
#2 楼
我认为这是一个数学问题，而SLA就是确定的可能性。您的第一种情况是App Service（A）和Sql Service（B）同时关闭的概率是它们的概率乘积：P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025
其中一个发生故障的概率是它们的和： br />
P(A)+P(B) = 0.001
因此，总体SLA为
1 - 0,00099975 = 0,99900025，其中99.900025 %为百分比。 /> 应用于您的1h / 24h中断（一天中的4,166666％），这会产生（十进制的缩写）：可以的百分比是
0.9995 * 0.9995 = 0,99900025，以百分比表示：1 - 0.0816 = 0.9184 P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975
这是比2小时的最坏情况要多s，因为这两个机会有可能同时停机。 （对不起，这里有完整的小数，但是对于演示来说，是必需的）。
现在，对于第二种情况，我们将从每个区域的复合概率中获益（对不起，我不考虑SQL的更改为了保持合理性），假设该区域本身没有独立的概率，并且每个区域都是孤立的，因此DB故障只会使该区域失效。
交通管理器的确定概率为
91,84%和每个应用程序+数据库对都有一个确定的概率，来自我们必须应用故障概率乘积来获得两个区域同时下降的概率，所以我们发挥了多少作用？
95,84%，这意味着至少一个区域的总体可用性0,958333333 * 0,958333333 = 0,918402778 br />现在我们有了整个区域的可用性，带有流量管理器的产品为我们提供了该系统的整体可用性：br />
Azure的文档提供了另一个解释来源（链接由Raj Rao提供）
评论
总体可用性似乎很低-实际上，通过添加其他区域和流量管理器，SLA比仅单个区域要低一个数量级。我试图从大脑的背面挖掘过去用于网络的方法。
–Richard Slater
17 Mar 30 '17 at 18:15
！我确定我会生气。
–Richard Slater
17 Mar 30 '17 at 18:29
@RichardSlater数学更正
–滕西拜
17年3月31日在8:02
@BruceBecker可能是的，显然IEEE已经发表了关于该主题的研究，但是我怀疑，鉴于计算这些数字的目的，更多的是要具有具体的“证明”，即您是否需要或不需要高可用性功能添加到系统中-即我们使用这些数字根据公司的风险偏好来制定成本效益决策。建立贝叶斯模型可能并不代表我们时间的最佳利用。
–Richard Slater
18/12/13在12:24
@BruceBecker是的，问题的一部分被捆绑了（同一数据中心关闭，并且两个服务都在其中，这必须很低），其余的我认为我们可以安全地假设应用程序服务和sql服务运行在不同的系统上，并且不太可能由于相同的原因同时失败。进一步学习数学将需要有关Azure架构如何完成的精确文档，因此只能由Microsoft的人员来回答。
–滕西拜
18/12/13在12:47
评论
假设您的应用程序能够应对会话中断，则SPOF的SLA最低？@Tensibai-我认为这不可能，根据我的第一个示例，如果两种服务的SLA都可以在24小时中的23小时内可用，那么App Service可能在0100和0200之间，而数据库在0500和0600，这两个组成部分都在其SLA内，但整个系统在24小时内无法使用2小时。
是的，这是有道理的，但在这种情况下，结果应该是所有否的乘积？
我的意思是应用99.95 x sql 99.95应该是该组的整体可用性
还请记住，通过重试，故障转移或降级而不是完全故障，您可以构建比其组件更可靠的系统。