Welcome back. In previous lessons, we talked about error budgets and how they're one of the main tools we have as SREs to prioritize reliability in a service. But how does that happen? It's not magic. As important as error budgets are, it's equally important to have an error budget policy for your team or organization. In this lesson, we'll see why error budget policies are important and talk about various considerations when drafting your policy. But first, a quick refresher. One of the core principles that makes SLOs so useful is that failing to meet them indicates your users are unhappy and therefore that you need to start investing engineering time into your services' reliability instead of building new features. But the SLO threshold is not a bright dividing line. All organizations are different and it is rare to find one that's willing to immediately switch between feature and reliability work in such a binary fashion. We argue that it's in the overall best interests of the business that there's some mechanism to enforce that engineering time is invested in reliability work when an SLO has been missed over a longer period of time, for example, when a trailing 28-day error budget has been completely burned. An organization that fails to do this will be constantly fighting fires and playing the blame game. Remember that reliability is a feature. Ultimately, it's the most important feature to your users. That's why we emphasize the importance of an error budget policy. An error budget policy describes how your business decides to trade off reliability work against other feature work when this SLO indicates a service is not reliable enough. The purpose of such a policy is to guide your organization into meaningful and appropriate action when the reliability of your service is threatened. We will talk about the tradeoffs involved in a little bit. If your business implements and follows an error budget policy, it will be able to respond more quickly and effectively to chronic reliability issues improving organizational alignment, reducing finger-pointing and ultimately resulting in happier users. In effect, it is programming the people in your organization so that they will broadly follow the same course of action when faced with different kinds of SLO misses. It ensures that all parties know what will happen if the service is unreliable and should provide an SRE team with the executive backing they need to redirect engineering effort towards work on improving reliability. Now, where do we store this policy? It's less clear that your error budget policy should be stored as metadata alongside your SLO configuration, but it's no less essential that you have one. Having it documented someplace broad and high level is probably best. The policy will most likely apply to many services across your organization. So, tying it to a single service may not make sense. The nice thing about having a documented policy is that you can have the arguments about its contents before you have a major outage.
