If you think back to the first module of this course, hopefully you remember our rule of thumb for setting an SLO target. Our happiness tests says that an SLO should represent the dividing line between happy users and unhappy users. But you can't measure that happiness directly. Your users might tell you they're unhappy via social media, but this isn't easily quantifiable and they aren't likely to consent to you directly tracking their serotonin and dopamine levels. Instead, you must find some way of approximating the happiness of your users with metrics you can directly measure about your service. Not all metrics are good approximations of user happiness. In fact, most aren't. What do you think makes a metric a good measure of user happiness? Remembering the lessons we learned in the first module again, you need to measure the user's experience as closely as possible, which means you must think about your service's reliability from the perspective of those users. It doesn't matter if it's your database being down or your load balancers sending requests to bad backends. From the user's perspective, these conditions all collapse to the website does not load and now I'm sad. Similarly, it doesn't matter which component of your service is overloaded. The users complaint is the website is slow and now I'm sad. If we can find a way of quantifying the website does not load or this website is too slow from our monitoring data, we can use this data to approximate how happy or unhappy our users are in aggregate. These quantifiable metrics become our SLIs. Ideally, you wanted to define SLIs that have a predictable, mostly linear relationship with happiness of your users. The predictability of the relationship is crucial because you'll be making important engineering decisions based on this data. In the next video, we'll look at some common metrics and think about what makes a metric good for use as an SLI.