What is SRE? Site Reliability Engineering, explained

SRE stands for Site Reliability Engineering: the practice of applying software engineering to the work of running systems in production — keeping them available, fast and recoverable, and treating that as an engineering problem rather than an operations chore. The term comes from Google, which set up its first SRE team in 2003; the approach is now standard at most companies whose revenue depends on software that stays up.

This article explains what SRE means in practice, how it differs from DevOps, how SRE teams are usually organised, and — because this is what Agile Analytics does — how to measure whether it is working.

Definitions of SRE vary; the practices do not. An SRE team, whatever it is called, does five things:

• Sets reliability targets as Service Level Objectives (SLOs) — an explicit, measured statement of how reliable a service needs to be, such as 99.9% of requests succeeding within 500 ms. Below that target, reliability work wins; above it, features do.
• Manages the gap with error budgets — the amount of unreliability an SLO permits. A team that has burned its budget stops shipping features and fixes reliability; one with budget left can take risks. This is the mechanism that ends the argument between "ship faster" and "break less".
• Eliminates toil — manual, repetitive operational work that scales with the size of the service. SRE treats toil as a bug to be automated away, and caps the share of time an engineer spends on it.
• Runs blameless post-mortems — every significant incident gets a written analysis that asks what in the system allowed it, never who did it.
• Owns monitoring and incident response — alerting on symptoms users feel rather than on causes, and measuring how long detection, diagnosis and recovery take.

If a team calls itself SRE and does none of these, it is an operations team with a new name. If it does all of them and calls itself platform engineering, it is doing SRE.

The two are often presented as rivals; they are not. DevOps is a culture and a set of delivery practices for getting changes into production quickly and safely. SRE is a discipline for keeping production reliable once the changes are there — and it gives DevOps the one thing it lacks, a numeric definition of "safe": the SLO. The practical difference shows up at 2 a.m., when something breaks and someone has to decide whether to stop shipping this week. SRE vs DevOps: who owns reliability when it breaks works through that in detail.

Google describes several ways to place SREs in an organisation, and most companies move through them in order as they grow:

• Kitchen sink — one small team covers everything; where most companies start.
• Infrastructure — SREs own the shared platform that product teams build on.
• Embedded — SREs sit inside product teams for a period and leave the practices behind.
• Consulting — a central team advises many product teams without owning their systems.

Whichever model you use, the measurements below are what tell you whether it is working — and they are what a career in SRE is built on.

Measuring SRE is essential to understand how your infrastructure is performing and identify areas for improvement. It can help you answer questions like:

• How reliable is my website or application?

• How quickly can my team respond to incidents?

• Are we meeting our service level objectives (SLOs)?

• How much downtime are we experiencing, and how can we reduce it?

Imagine your website is experiencing slow page load times. Measuring SRE can help you identify the root cause of the problem, such as a slow database query or a misconfigured server. Once you've identified the issue, you can work on fixing it and improving your website's performance.

One of the key aspects of SRE is measuring two critical metrics: Service Level Objectives (SLOs) and Mean Time To Recovery (MTTR).

To measure SLOs, first, you need to define them. An SLO is a specific, measurable target for the performance or reliability of a system. For example, an SLO could be defined as the percentage of requests that should be served successfully in under 500 milliseconds. Once you have defined your SLO, you need to track it over time to see how well your system is meeting that target.

Find out how to define SLOs in our article. Agile Analytics helps you easily define, measure and track your SLOs.

To measure MTTR, you need to track the time it takes to recover from incidents or outages. This includes the time it takes to detect the issue, diagnose the root cause, and implement a fix. MTTR is an important metric because it directly impacts the availability and reliability of your system.

MTTR is one of the DORA Metrics (DevOps Research and Assessment) used to evaluate the performance and success of DevOps teams. With Agile Analytics, you can easily track and measure all of the DORA Metrics, including MTTR.

Here is an example of how SLOs and MTTR can be measured in a software development project:

Let's say you are working on an e-commerce website that has an SLO of 99.9% availability, which means that the website should be available to users 99.9% of the time. To measure this, you could use a monitoring tool that tracks website uptime and downtime. If the website is down for any reason, such as a server failure, you should start tracking MTTR. You would calculate MTTR by measuring the time from when the outage started to when it was fully resolved and the website was back up and running.

In this example, if the website goes down for an hour, your MTTR would be one hour. You could use this data to analyze the root cause of the outage and implement changes to reduce the likelihood of similar incidents happening in the future. You could also use the data to track your progress in meeting your SLO and make adjustments as needed to improve your system's reliability.

In today's digital age, where almost every business relies on technology to function, SRE is critical. By measuring it, you can ensure that your infrastructure is reliable, scalable, and performs well, which ultimately leads to better customer satisfaction and revenue. Don't leave it to chance – take control of your SRE and measure it with the help of Agile Analytics. Try our app for free for 60 days and discover how you can improve your team's performance and software quality. Don't miss this opportunity to optimize your development process and deliver better products to your customers.