2
您如何计算云服务的复合服务水平协议（SLA）？
通过托管云服务Amazon Web服务，天青，谷歌和其他大多数发布小号 ervice 大号埃维尔一个 greement或SLA，因为他们提供的个人服务。然后，架构师，平台工程师和开发人员负责将它们放在一起，以创建一个架构，为应用程序提供托管。 孤立地考虑，这些服务通常提供的可用性在三到四分之九的范围内： Azure Traffic Manager：99.99％或“四个九”。 SQL Azure：99.99％或“四个九”。 Azure应用服务：99.95％或“三九五”。 但是，当在体系结构中组合在一起时，任何一个组件都可能会发生中断，从而导致总体可用性不等于组件服务。 系列化合物的可用性 在此示例中，存在三种可能的故障模式： SQL Azure已关闭 应用服务已关闭 都下来了 因此，此“系统”的总体可用性必须低于99.95％。我对这种思维的理由是，如果在这两项服务的SLA是： 该服务将在24小时中的23小时内提供 然后： 应用服务可能在0100到0200之间 数据库出在0500和0600之间 这两个组成部分均在其SLA内，但整个系统在24小时内无法使用2小时。 串行和并行可用性 在这种体系结构中，主要有很多故障模式： RegionA中的SQL Server已关闭 RegionB中的SQL Server已关闭 RegionA中的应用服务已关闭 RegionB中的应用服务已关闭 流量管理器已关闭 以上组合 由于流量管理器是断路器，因此能够检测任一区域的中断并将流量路由到工作区域，但是流量管理器仍然存在单点故障，因此“系统”的总可用性无法高于99.99％。 如果企业希望获得比架构所能提供的服务级别更高的服务水平，则如何为企业计算和记录以上两个系统的复合可用性，并可能需要重新配置？ 如果您想注释图表，我已经在Lucid Chart中构建了它们并创建了一个多用途链接，请记住，任何人都可以对其进行编辑，因此您可能希望创建页面的副本以进行注释。