Before going to discuss the different Service Level Terminology. Lets have look at what is SRE in a very short term.
SRE is discipline that happens when a software engineer is put to solve operations problems.
Service Level Terminology:
In this world, we know that billions of people use different services on daily basis. It may be paid or can be unpaid service, maybe any. Even if the services are paid or free, all people/customers have a high expectation from the service i.e the highly reliable, available, and high throughput as well and many other aspects.
Then how exactly you people know that your service is reliable or not, weather it full fills the users expectations.How you can measure the reliabilty of your service.
How do you know that your Service is “Reliable” ?
So, the answer is to solve the above problem SRE provides Some Service Level Terminologies. So In this blog will discuss each terminology one by one in detail. There are 3 different terminologies as follows.
Which is why it’s important for companies to understand and maintain SLAs, SLOs, and SLIs—three initialisms that represent the promises we make to our users, the internal objectives that help us keep those promises, and the trackable measurements that tell us how we’re doing.
SLA:
An SLA (service level agreement) is an agreement between provider and client (i.e vendor and customer)about measurable metrics like uptime, scalability, reliability, responsiveness, and responsibilities.
Basically in this agreement we mention all the promises that we made to our client, not only promisess but consequences as well if you fail to live up to those promises.These agreements are typically drawn up by a company’s new business and legal teams.Typically, consequences include financial penalties, service credits, or license extensions.
Who needs SLA: Generally an SLA is an agreement between a vendor and a paying customer. For free services there is no need of SLA.
Why SLA is difficult: These agreements are generally written by people who aren’t in the tech trenches themselves often make promises that are difficult for teams to measure, don’t always align with current and ever-evolving business priorities, and don’t account for nuance.
SLO:
An SLO (service level objective) is an agreement within an SLA about a specific metric like uptime or response time. So, if the SLA is the formal agreement between you and your customer, SLOs are the individual promises you’re making to that customer.
SLOs are what goals developers need to hit and measure themselves against.
Who needs SLO: Where SLAs are only relevant in the case of paying customers, SLOs can be useful for both paid and unpaid accounts, as well as internal and external customers.
SLI:
An SLI (service level indicator) a carefully defined quantitative measure of some aspect of the level of service that is provided. e.g (latency, error rate).
An SLI (service level indicator) measures compliance with an SLO (service level objective). So, for example, if your SLA specifies that your systems will be available 99.95% of the time, your SLO is likely 99.95% uptime and your SLI is the actual measurement of your uptime.
SLIs form the basis of Service Level Objectives (SLOs), which in turn form the basis of service level agreements (SLAs); an SLI is thus also called an SLA metric.
So, There can be many different service level indicators. So are you going to consider measuring all those indicators?
Ans: No
So which indicators are you going to consider? Choose those indicators which represent the happy user towards the unhappy user. So we can say that a Good indicator represents the relationship between user happiness and unhappiness.
Who needs SLI: Any company measuring their performance against SLOs needs SLIs in order to make those measurements. You can’t really have SLOs without SLIs.
Note: If you want to learn more about SRE related stuff like TOIL, you can refer to this
References:
https://sre.google/sre-book/service-level-objectives/
