Okay, now let's get to business and actually set some targets for reliability. Wait, you might be thinking, don't we want our service to be 100% reliable? Not quite, there are many trade-offs you have to consider when setting a reliability target. If you're trying to run your service much more reliably than it needs to be, you're slowing down development velocity for features that will make your customers happier, for a minor increase in reliability. A 100% is the wrong reliability target for basically everything. Except maybe life critical systems like pacemakers and ABS brakes. It becomes much, much more expensive to make reliable systems even more reliable. So there's some point at which the incremental cost of reliability exceeds its value. To choose the right target for your reliability, here's some things to think about. First, you're going to want to have ambitious but achievable targets. These are derived from understanding what your users need from the service and how it currently performs. Then stakeholders across products, development and operations must all agree on those targets. Next, you'll want to measure how the SLI is performing against target and try to be slightly over it. But don't be too reliable or users will start to depend on it. There isn't actually a linear relationship between service availability and user happiness. Once you've passed the happiness test, increasing availability will have diminishing returns. In addition, higher availability costs you more to provide, reducing your ability to make changes and release new features. If your service is significantly more reliable than an individual customer's ISP, they're going to struggle to attribute any failures to you. In our experience, the biggest trigger of outages is pushing changes such as a configuration or new binary. If you want to improve reliability, sooner or later, you're going to need to slow down changes by having things like increased testing, less frequent releases and more manual analysis.