Let’s break down our incident response into three basic steps: Seems pretty easy, right? Well, it’s a bit more complicated than that: The correction can be made either by the respondents themselves, or passed along for development. This response determines how to correct the incident. The team then kicks off its incident response procedure. Let’s add incident response to our model:Īn incident occurs, which affects the service. Of course, when an incident occurs, you want to restore the service back to its normal reliability. Incidents can be anything that reduces the reliability of the service for users. The service is impacted by intended changes (e.g, deploys), or by unintended changes (e.g. In this post, we’ll construct a basic reliability model and show you how to create one for your own organization.įirst, let’s look at the most basic model of your service:īasic indeed! But from the service’s perspective, there isn’t anything else happening. A model also acts as a guide for what the supporting communication infrastructure should look like. Building a model of SRE specific to your organization is a good way to keep a clear picture in your head.

Understanding all the new connections formed by SRE practices can be daunting. This forms connections between different teams and roles. SRE breaks down silos and helps learning flow through every stage of the software lifecycle. Originally published on Failure is Inevitable.Īs you adopt SRE practices, you’ll find that there are optimization opportunities across every part of your development and operations cycle.

Django slack bot