Want to up-level your reliability program? Let's start by identifying your opportunities for growth.
How much time are engineering teams spending on incidents?
Are you trying to set your engineering team free to do their best work? Read our new case study to learn how Blameless can help you do that.

The Importance of Reliability Engineering

Emily Arnott
|
8.6.2020

If you’ve spent any time in tech circles lately, there are three letters you’ve surely heard: SRE. Site Reliability Engineering is the defining movement in tech today. Giants like Google and Amazon market their ability to provide reliable service and startups are now investing in reliability as an early priority.

But what makes reliability engineering so important? In this blog, we’ll look at three big benefits of investing in reliability and explain how you can get started on your journey to reliability excellence.

Reliability engineering provides business value

A reliable service is more valuable to a customer than one with inconsistent performance. It seems so obvious that you may think it goes without saying, but this reminder is crucial. Picture a typical user of your service. They are happy and engaged as they use your unique features, but don’t ignore the underlying assumption: your service works. Regardless of how your features stack up to competitors, users will always choose a functional option over a function-rich one. No feature is more important than reliability.

Regardless of how your features stack up to competitors, users will always choose a functional option over a function-rich one. No feature is more important than reliability.

The consequences of unreliable software are also more costly than the proactive investment in reliability. Consider how dependent you are on technology. On a given day, you rely on an alarm to wake you up, an app to report the weather, and a calendar that reminds you of your schedule. You might hail a ride from Uber or use Google Maps to avoid traffic on the freeway. Maybe you get lunch delivered from Grubhub. When you arrive home, your Amazon package is right where you expect it. We trust in these services.. When they go down, we feel angry.

These are the standards your service is judged by in the era of reliability. When the most popular software boasts uptime percentages of five nines, users begin to expect a level of consistency where downtime is a non-concern. The value generated by investing in reliability isn’t just in the additional uptime of your service, but in keeping your customers happy with your brand, increasing users, and lowering the potential for churn.

Reliability engineering empowers development

You may think of reliability engineering as an overhead cost to development, an additional layer of work that must be accounted for. It’s true that time and energy must be dedicated to reliability, but you’ll find that adopting SRE best practices can actually empower and accelerate development.

SLOs and error budgets

SLOs and error budgeting work as a system to ensure downtime, latency, and other indicators of unreliability are kept within acceptable bounds. When these acceptable metrics are exceeded, SLO policies can refocus development efforts to stabilize and repair. On the other hand, when SLOs are within acceptable ranges and error budget is available, development can safely accelerate. Proposed changes that may affect reliability can be measured against the SLO, allowing you to build new features with confidence.

SLOs can also empower effective development by highlighting areas of greatest business impact. When determining your SLIs (the indicators your SLOs measure) you’ll discover insights on what areas of your service matter most to users. When you understand exactly what your users expect, you understand how your service is positioned and how to develop towards customer happiness.

Incident retrospectives

Despite proactive measures, incidents are inevitable. However, with SRE principles, what would otherwise be considered a setback can become another investment in development. An incident retrospective is a document collaboratively constructed in response to an incident and reviewed by those involved afterwards. This may seem at first like additional work in a situation where time is already limited, but the time it saves more than makes up for it. By analyzing patterns in incidents, developers learn where to spend proactive efforts in reliability. It also encourages developers to look at ways to avoid common classes of bugs and incentivizes writing more performant code.

Despite proactive measures, incidents are inevitable. However, with SRE principles, what would otherwise be considered a setback can become another investment in development.

Automation and consistency

SRE principles also accelerate development through their focus on automation and consistency. By making the investment to codify DevOps processes in runbooks, where steps and checks are clearly outlined, common tasks can be made faster or even automatic. SRE encourages consistency in how incidents are classified and what responses each severity level demands. This consistency encourages fast and confident incident responses via streamlined collaboration.

Reliability engineering fosters an empathetic culture of learning

SRE isn’t just a set of practices and policies—it’s a mentality on how to develop software in a culture free of blame. By embracing this new mindset, your team’s morale and camaraderie will improve, allowing everyone to work at their full potential in a psychologically safe environment.

SRE teaches us that failure is inevitable. No matter how many precautions you take, incidents happen. While giving you the tools to respond effectively to these incidents, SRE also challenges us to celebrate these failures. When something new goes wrong, it means there’s a chance to learn about your systems. This attitude creates an environment of continuous learning

When analyzing these inevitable incidents, it’s important to maintain an attitude of blamelessness. Instead of wasting time pointing fingers and finding fault, work together to find the systematic issues behind the incident. By avoiding a culture of blame and shame, engineers are less afraid to proactively raise issues. Team members will trust each other more, assuming good faith in their teammates’ choices. This spirit of blameless collaboration will transform the most challenging incidents into opportunities for growing stronger together.

At the heart of these lessons is the idea of putting the human first: either when considering the impact of reliability on users, or the developers keeping things afloat. Success depends on understanding how your users and developers feel and truly empathizing with them when making decisions. SRE gives you the tools to connect these empathetic insights with actionable data.

SRE isn’t just a set of practices and policies—it’s a mentality on how to develop software in a culture free of blame. By embracing this new mindset, your team’s morale and camaraderie will improve, allowing everyone to work at their full potential in a psychologically safe environment.

Starting your reliability engineering journey

In the era of reliability, there’s no better time than now to start on your SRE journey!


For learning the practical details of SRE, check out Google’s landmark textbook or the accompanying Coursera course. Blameless offers an essentials guide if you’re more pressed for time. You can find more great resources on all aspects of SRE in our list of top SRE resources.

If you’re interested in tooling to support your SRE solution, check out our buyers’ guide for reliability. You can also see how Blameless helps empower your SRE practices, join us for a demo!

Resources
Book a blameless demo
To view the calendar in full page view, click here.