‫[Michael Pogrebinsky] Welcome back!
‫Now that we covered the most important quality attributes
‫and everything that we need to know about them,
‫let's conclude the section with three very important terms
‫that essentially aggregate the promises we make to our users
‫in regards to those quality attributes.
‫Those are SLA, SLOs and SLIs.
‫So let's start with the first term
‫which is service level agreement or SLA in short.
‫The SLA is an agreement between us, the service provider
‫and our clients or users.
‫It's essentially a legal contract
‫that represents the promise we make to our users
‫in terms of quality service
‫such as availability, performance, data durability,
‫the time it takes us to respond
‫to system failures and so on.
‫It also explicitly states the penalties
‫and financial consequences to us
‫if we fail to deliver those promises
‫and bridge the contract.
‫Those penalties can include full or partial refunds,
‫subscription or license extensions,
‫service credits and so on.
‫SLAs almost always exist for external paying users
‫but sometimes also exist for free external users
‫and occasionally even for internal users within our company.
‫Although internal SLAs would unlikely include any penalties.
‫The reason SLA still makes sense for free external users
‫is for example if we're providing a three day free trial
‫of our service to our users,
‫enduring that free trial our system had major issues,
‫then it would make sense for us to compensate those users
‫by giving giving them an extension of the trial
‫or maybe some credits that they can use for the future.
‫However, most companies that provide entirely free services
‫avoid making any strict promises to the public
‫and don't publish any SLA.
‫When it comes to internal customers within our company,
‫those customers maybe other teams
‫that are providing services to external customers.
‫And in order for them to meet their SLA,
‫they need to know ours
‫and rely on us to meet that agreement.
‫Now let's talk about the next term, the SLO
‫which stands for service level objective.
‫SLOs are the individual goals that we set for our system.
‫Each SLO represents a target value
‫or a target range of values that our service needs to meet.
‫For example, we can have
‫an availability service level objective of three nines.
‫A response time SLO of less than a hundred milliseconds
‫at the 90th percentile or an issue resolution time objective
‫of between 24 or 48 hours.
‫All the quality attribute requirements
‫that we gathered at the beginning of the design process
‫will make their way into one or multiple SLOs
‫as well as other objectives
‫that we want to hit with our system
‫and hold ourselves accountable for.
‫If our system has an SLA,
‫then each SLO represent an individual agreement
‫within that SLA about a specific metric in the system.
‫So essentially an SLA aggregates
‫all the service level objectives in a single legal document.
‫But even systems that don't have an SLA still must have SLOs
‫because if we don't have those objectives,
‫our internal or external users don't know what to expect
‫when they rely on our system.
‫Now the third term we're going to cover
‫is the service level indicator or SLI.
‫A service level indicator is a quantitative measure
‫of our compliance with a service level objective.
‫In other words, it's the actual numbers we measure
‫using a monitoring system
‫or that we calculate from our logs.
‫Once we calculate the numbers
‫based on those service level indicators,
‫we can later compare them to the goals we set for ourselves
‫when we define the service level objectives.
‫For example, we can measure the percentage of user requests
‫that receive the successful response
‫and use that as an indicator
‫to measure the availability of our system and compare it
‫to the availability service level objective of three nines
‫that we set for our service.
‫Similarly, we can collect the response times
‫of each request, then bucket them into time windows
‫and calculate the average or the percentile distribution
‫of the response time that our users experienced.
‫Later, we can compare those numbers
‫to the end-to-end latency SLO of a hundred milliseconds
‫at the 90th percentile that we originally set for ourselves.
‫Since the SLOs essentially represent the target values
‫for our most important quality attributes,
‫now we understand why it was so important
‫for our quality attributes to be testable and measurable.
‫Because if they weren't measurable,
‫we wouldn't be able to find any service level indicators
‫to validate that we are indeed meeting our SLOs.
‫And if we can't measure
‫and prove that we are meeting our SLOs,
‫we can't definitively say
‫that we are meeting our service level agreement
‫which is a legal contract.
‫Now, while the service level agreements
‫are crafted by the business and legal teams,
‫the software engineers and architects
‫have a lot more control in defining
‫and setting the service level objectives
‫and the service level indicators associated with those SLOs.
‫So when it comes to the service level objectives,
‫there are a few considerations
‫that we need to take into account.
‫The first consideration
‫is we shouldn't take every service level indicator
‫that we can measure in our system
‫and define an objective associated with this indicator.
‫Instead, we should first think about the metrics
‫that users care about the most
‫and define the service level objectives
‫around those metrics.
‫From that, we find the right service level indicators
‫to track those service level objectives.
‫The second consideration
‫is the fewer service level objective we promise,
‫the better it is for us.
‫With too many SLOs, it's hard for us
‫to prioritize all of them in an equal manner.
‫So when we have just a few SLOs, it is much easier
‫for us to focus our entire software architecture
‫around them to make sure we meet our goals.
‫The third consideration is setting realistic goals
‫with a budget for error.
‫Just because we can provide five-nines of availability
‫doesn't mean that we should commit to that.
‫Instead, we should commit to a much lower availability
‫than we can provide.
‫This allows us to save costs
‫and also leaves us enough room for unexpected issues.
‫And it's especially true
‫when our service level objectives
‫are represented in an external service level agreement.
‫In those cases, sometimes companies
‫define separate external service level objectives
‫which are a lot looser
‫than internal service level objectives
‫that tend to be more aggressive.
‫For example, externally,
‫we can commit to 99.9% of availability
‫but internally, we can commit to 99.99% availability.
‫This way, we can strive for better quality
‫of service internally
‫while committing to a lot less to our clients.
‫This would also avoid any financial penalties to us
‫if we don't reach this high bar
‫that we set for ourselves internally.
‫The final consideration is we need to create a recovery plan
‫to deal with any situation when the service level indicators
‫start showing us that we are not meeting
‫our service level objectives.
‫In other words, we need to decide ahead of time
‫what to do if all of a sudden our system goes down
‫for long periods of time, if our performance degrades
‫or we suddenly get too many reports
‫about issues or bugs in our system
‫in a short period of time.
‫This plan should include automatic alerts
‫to engineers or DevOps, automatic failovers,
‫restarts, rollbacks or auto scaling policies
‫and predefined handbooks
‫on what to do in certain situations
‫so that the person on call doesn't have to improvise
‫when they're alerted about an emergency in our system.
‫In this lecture, we'll learn about
‫three very important terms in designing a real life system.
‫The service level agreement or SLA,
‫the service level objectives or SLOs
‫and the service level indicators or SLIs.
‫We'll learn that the SLA is a legal contract
‫between a service provider and its customers
‫which essentially aggregates
‫the most important service level objectives
‫that we promise to our users,
‫while the service level indicators
‫are used to measure our compliance with those objectives.
‫Finally, we'll learn about four important considerations
‫when defining service level objectives.
‫The first one
‫was defining the most important service level objectives
‫that our users care about
‫and then find the service level indicators
‫based on those objectives.
‫The second and third considerations
‫told us to commit to the bare minimum
‫in terms of the number of objectives
‫and how aggressive they are.
‫And finally, the last consideration
‫was having a recovery plan ahead of time
‫to deal with situations
‫wherein potential breach of our SLOs.
‫I'll see you all in the next lecture.