Uptime is the amount of time that a service is available and operational. Different services are isolated. and we want to know what is the SLA of that solution.
Let’s consider the multiplication law of probability.

The negation of a probability is easy to compute: Using simple mathematical manipulations, we can find the probability we are looking for: $latex \begin{array}{lcl}P(\text{A or B is up}) &=& 1 - P(\text{A and B are down})\\ &=& 1 - P(\text{A is down}) \cdot P(\text{B is down}) \\&=& 1 - (1 - P(\text{A is up})) \cdot (1 - P(\text{B is up}))\end{array}$, $latex \begin{array}{lcl}P(\text{Primary or Secondary is up}) &=& 1 - (1 - P(\text{Primary is up})) \cdot (1 - P(\text{Secondary is up}))\\&=& 1 - (1 - \%99.9) \cdot (1 - \%99.9)\\&=& 1 - \%0.1 \cdot \%0.1\\&=& 1 - \%0.0001\\&=&\%99.9999\end{array}$. LRS) has an SLA of %99.9. $latex P(\text{service is up}) = availability = \dfrac {\text{total time service is up} }{\text{total time measured} }$.
This is often is a surprising result for customers we speak to. There is a bias in the previous computation. But how much is 30 minutes worth of business during peak hours? How do I announce us to the entire galaxy? Having different SLAs for different processes can bring nuance on the offering. It’s compromise for engineering who would like it to be as low as possible so they can ensure they can hit it (e.g. See Azure Architecture Center for reliable design best practices. Although we are going to use Azure in all examples, most of the guidance apply to any public cloud solution.

Some events could take both services down. Let’s start with a simple example:  a Web App (SLA of %99.95) with a SQL DB (SLA of %99.99). They invest a lot to avoid it from happening. Ask Question Asked 1 year, 7 months ago. Local Redundant Storage (i.e. What are the pros and cons of removing exterior dentil molding? They provide uptime measures for the past 30 days for VMs, storage, CDN, Web site & Databases. Azure has a comprehensive list of SLA documented here. Uptime SLA is an optional feature to enable a financially backed, higher SLA for a cluster. A good example is an e-Commerce solution having different SLAs: Those three SLAs refer to business process the end user can easily identify. Those business processes are understood by the consumer. Uptime is generally the most important metric for a website, online service or web based provider and is expressed as a percentage such as '99.9%'. For actual measured average uptimes, a good reference is Cloud Harmony. It combines SLAs of services used for the solution. That part is important and it isn’t. Uptime is generally the most important metric for a website, online service or web based provider and is expressed as a percentage such as '99.9%'. Here we will discuss an approach to establish a theoretical SLA baseline based on the SLAs of sub components. It also mean that during 30 days, the service should be down around 43 minutes. Azure SLA Board. Let’s consider our solution with a Web App and a SQL DB. That is, if A & B are independent then: $latex P(\text{A and B}) = P(A) \cdot P(B)$, $latex \begin{array}{lcl} P(\text{Web App and SQL DB are up}) &=& P(\text{Web App is up}) \cdot P(\text{SQL DB is up})\\ &=& \%99.95 \cdot \%99.99\\ &=& \%99.94 \end{array}$. Let’s consider a simple scenario first:  storage RA-GRS. For scenarios where the user is authenticated, the Azure AD B2C doesn’t need to be up. We could consider scenarios where the DB isn’t involved in previous examples. This is the SLA that at least one region’s storage is up. We assumed that both service failures were independent events. What would be the combined SLA ? But they aren’t %100 isolated in the sense they still share some failure modes. .

Measures should definitely complement it once they become available. Uptime routinely scores %100, even across regions.

Azure Kubernetes Service (AKS) Uptime SLA. site design / logo © 2020 Stack Exchange Inc; user contributions licensed under cc by-sa. Active 1 year, 3 months ago. (Haversine formula). To subscribe to this RSS feed, copy and paste this URL into your RSS reader. We definitely encourage you to measure the availability of your solution.

Each service may fail independently at different times, so you have to calculate the composite SLA by multiplying the individual SLA numbers. Azure Storage is a good example:  the reading vs writing scenarios do not have the same SLA for RA-GRS. This is easier than done in most cases, especially for existing applications. For instance, it is useful to orient the design at the architecture stage. Let’s consider a solution where Azure AD B2C authenticate end-users.