Site Reliability Engineering

What is site reliability engineering (SRE)?

Heard of site reliability engineering (SRE) but not quite sure how to apply it to your IT environment or if it will work for your business context? You’re in the right place.

Join us as we dive into what SRE is, how it works, how it’s related to DevOps, and the best practice principles, some of which you’re probably already doing in your own environment.

SRE is a set of principles and practices, all designed to support teams in creating scalable and reliable software systems. It takes software engineering best practices, and then applies them to infrastructure and operations, using software as the tool to achieve a robust environment.

If you’re a site reliability engineer, you’ll be tasked with looking after elements of the business such as availability, reliability, performance, efficiency, and incident response. In order to manage these elements of an IT environment, SRE often utilizes automation, intelligent system design, and other software technology that focuses on the resilience and hardiness of IT systems and processes.

Many of the tasks handled by SRE will have been completed in the past by Operations teams. With SRE, they are handed over to technicians or engineers, who use software to solve problems and manage IT systems.

There is a lot of education involved in SRE, as site reliability engineers will need everyone in the business to contribute to good security hygiene.

What are the benefits of SRE?

SRE is a great way to scale IT management and control, as instead of managing thousands of machines manually, you can use software and automation to manage them behind the scenes. You can manage very large systems using code and scripts, ensuring reliability and security before releasing new features.

Another benefit is standardization. As SRE uses automation, IT technicians can get peace of mind that all tasks are being completed in the same way, not being given different responses due to subjective engineers or operations managers. Reliability should improve over time, as all machines and systems are governed by the same automation and best practices.

SRE can often reduce or eliminate departmental silos across the business, allowing everyone to sing from the same proverbial hymn sheet, by implementing the same processes and metrics for all areas of the organization.

What is DevOps vs. SRE?

This is a common question, as SRE and DevOps are both popular methodologies that have gained a lot of attention during the same time period. However, DevOps is a lot broader than site reliability engineering, and it has a more defined scope. DevOps is intended to create business value across a whole company by delivering new features and updates quickly and securely. SRE definitely works well in a DevOps environment, but they are not one and the same.

Like DevOps, SRE will help you to deliver services more rapidly, and to improve service delivery, reducing the time it takes to create applications and keep an IT environment running at peak performance.

However, site reliability engineers tend to have more of a specialized operations background and work on communicating value across the business and streamlining workflows, not simply on technical tasks like CI/CD pipelines, the way a DevOps engineer might. While a DevOps engineer will be focused on the development lifecycle — writing and deploying code, an SRE will balance creating and launching new features with the reliability of the site overall.

What are the main principles and practices of SRE?

SRE originated at Google, but the term has come a long way since then. There is no definitive list of principles that define SRE, but you’ll usually see the following four characteristics of most SRE teams and implementations:

Automation: Eliminating anything that’s repetitive or manual, freeing up time for the business to do more with less resources. If automation can handle these tasks behind the scenes – SRE makes it happen. If a problem is being dealt with by engineers over and over again, then this is an area that needs to be approached using automation.

Necessity: Defining and measuring goals for reliability, and not going further than these goals. This is usually done with Service Level Agreements and Service Level Indicators and Objectives that meet the business context. 100% reliability is not expected when SRE is the business approach. Instead, failure is expected, within pre-agreed limits and risk tolerance.

Intelligent system design: SRE teams will work on reducing risk, whether that’s for security, latency, reliability, or performance. They will design, implement and test different processes focusing on these goals. According to Google, up to 50% of an SRE’s time can be spent on Operations, while the rest will be spent on Development.

Observability: Unlike static monitoring, observability allows technicians to collect valuable information in a dynamic environment. Systems are designed in such a way that information is automatically gathered that alerts to issues, and why they have happened. Instead of technicians being passive and waiting for an alert, logs, metrics, and tracing are used.

Is SRE right for your business?

Most companies will already be implementing some SRE principles, especially if they have taken steps to move from an on-premises environment to a cloud or hybrid one over the past few years. Who doesn’t want to add reliability, automation, scalability, and measurement to the way that they run their IT environment, after all?

If you’re looking to take the SRE approach, and as Google defines it, “treat operations as if it’s a software problem”, you’ll need great tools and technology that allow for best practice implementation.

This means automation for the repetitive and manual tasks that take up so much of technicians’ time, the ability to set clear and actionable Service Level Agreements, and in-depth event logs and reporting capabilities.