BizOps for Site Reliability Engineers (SREs)

Being a site reliability engineer (SRE) isn’t easy. The SRE’s job is to secure a flawless user experience. To promote site reliability, SREs bridge dev and ops, ensuring new releases improve the product, rather than breaking it.

Following are some of the key facets of the SRE’s role:

• Set customer-focused metrics. SRE models ultimately place a singular focus on what really matters: the customer experience. This must be integral to the approaches, metrics, and tactics teams employ. In an SRE model, teams manage the customer experience by establishing a number of metrics, including service-level indicators (SLIs) and service-level objectives (SLOs). Teams need to determine what specific monitoring data will be used to inform SLIs. This requires identifying and capturing so-called “golden signals” for SLIs. There are four common categories of golden signals: latency, traffic, errors, and saturation. (See the related tab for more information on these metrics.)
• Establish error budgets. In many ways, the SRE model represents a pragmatic bridge between the “fail-never” mindset of traditional IT operations and the “fail-fast” perspective embodied by DevOps. The concept of “error budgets” is integral in the SRE model. An error budget establishes a clear SLO-based metric for how unreliable a service can be. Through these error budgets, teams establish an acceptable risk. Effectively, this can be viewed as operating within the gap between 100% availability, and a lower metric that is still acceptable from a customer experience standpoint.
• Reduce “toil” through automation. When implementing SRE models, teams should be focusing on harnessing automation to reduce toil—those high-volume, low-complexity tasks that inhibit teams. Toward this end, teams can institute automation across several key areas, including provisioning and deployment, problem resolution, and resilience and performance management.

For more information on harnessing SRE models, be sure to view the white paper, “Unlocking the Value of the SRE Model.”

SRE models ultimately place a singular focus on what really matters: the customer experience. This must be integral to the approaches, metrics, and tactics teams employ. In an SRE model, teams manage the customer experience by establishing the following metrics:

• Service-level indicators (SLIs): SLIs measure of the level of service provided to a customer. Common SLIs include latency, throughput, availability, and error rate. SLIs more closely tied to customer experience might include page load time, streaming buffer time, successful downloads, transaction completion, and so on.
• Service-level objectives (SLOs): SLOs are a target value or range of values for a service level that is measured by an SLI. For example, an SLO might be that page load times must be under three seconds, search request latency remains under 100 ms, or that a service must deliver 99.999% availability.

In establishing these metrics, teams need to determine what specific monitoring data will be used to inform SLIs. This requires identifying and capturing so-called “golden signals” for SLIs. There are four common categories of golden signals: latency, traffic, errors, and saturation. Teams can also establish more business-outcome-based KPIs, such as order processing time, download completion time, and so on.

For more information on harnessing SRE models, be sure to view the white paper, “Unlocking the Value of the SRE Model.”

What’s the difference between SRE and DevOps? First, here are high level definitions of each to get started:

• SRE. SRE, which is short for Site Reliability Engineering or site reliability engineer, refers to the use of software engineering principles to help maintain and manage IT systems. This idea is innovative because, traditionally, there was a large divide at most companies between IT operations staff, whose main role was maintaining software, and software engineers, whose main role was writing software.
• DevOps. DevOps, as the term implies, is about bridging the gap between development and IT operations. The core idea behind DevOps is essentially the same idea that drives SRE: It’s about making overall IT operations more reliable and efficient by allowing software developers and IT operations staff to collaborate more closely.

You could argue that it’s largely a matter of semantics, and that in practice SREs and DevOps engineers fill the same basic roles. The reality is that, at the end of the day, SREs and DevOps engineers address different needs. Understanding those differences is key to ensuring that your IT teams operate as efficiently as possible.

Here are some important differences between SRE and DevOps:

• Role played by developers. SRE uses a developer’s mindset and tooling to solve the problems of IT operations. Thus, in SRE, most things are done from a software engineer’s perspective. In contrast, DevOps is more about combining the skillsets of developers and IT ops engineers, rather than using the former to supplant the latter.
• Culture vs. implementation. Generally speaking, DevOps tends to focus more on cultural goals and priorities than on specific implementational processes. There are no specific tools you need to use or approaches you have to follow in order to “do DevOps.” There is no specific script to follow for doing SRE, either, but SRE overall offers more rigid prescriptions about how to solve problems, and which types of tools to use, than does DevOps.
• Organizational structure. In most cases, DevOps doesn’t replace existing developer and IT operations departments or roles. Companies may hire a few DevOps engineers to help guide DevOps, but they don’t replace all existing IT roles with DevOps engineers. In contrast, the SRE role tends to be seen as a way to replace at least IT operations. (This is a generalized statement and there are certainly exceptions, but overall, SRE involves greater change to organizational structure.)
• Extension to other IT roles. DevOps has spawned a slew of offshoots that extend the DevOps concept between just development and IT operations. Now, it’s common to hear talk about DevSecOps, for example, which applies DevOps to security, or QAOps, which brings QA engineers into the DevOps fold. The SRE concept, meanwhile, hasn’t seen this type of expansive use.

For more information, see our blog post, “SRE vs. DevOps.”