5 Essentials You Must Be Doing to be an SRE

Site Reliability Engineering (SRE) is more than a job title; it’s a mindset, a philosophy, and a set of practices designed to bridge the gap between development and operations. However, not every team or professional using the SRE title truly embodies what it means to be an SRE. In this blog, we’ll explore five key practices that define true SREs. If you’re not doing these, you might want to rethink calling yourself or your team an SRE.

1. Prioritizing Reliability Over Everything Else

SREs live and breathe reliability. If you’re not actively measuring and maintaining your systems' availability, performance, and durability, then you’re missing the core purpose of SRE.

What You Should Be Doing:
- Define and track Service Level Objectives (SLOs) and Service Level Indicators (SLIs).
- Use error budgets to balance feature development and system stability.
- Implement incident response processes to minimize downtime.

2. Automating Toil Away

Toil—the repetitive, manual tasks that don’t scale—should be the enemy of every SRE. If you’re still spending most of your time firefighting or performing routine tasks, you’re not fully leveraging the power of automation.

What You Should Be Doing:
- Identify and automate repetitive tasks using scripts, tools, or workflows.
- Continuously improve CI/CD pipelines to minimize manual intervention.
- Invest in infrastructure as code (IaC) to manage and scale environments seamlessly.

3. Proactively Monitoring and Observing Systems

An SRE isn’t just reactive—they are proactive. If you’re not deeply involved in monitoring, logging, and observability, you’re not anticipating problems before they occur.

What You Should Be Doing:
- Build robust observability systems with tools like Prometheus, Grafana, and OpenTelemetry.
- Analyze logs and metrics to identify trends and predict failures.
- Perform chaos engineering to test system resilience under stress.

4. Treating Operations as a Software Problem

SREs approach operations with a software engineering mindset. If you’re not writing code to solve operational challenges, you’re more of a traditional operations engineer than an SRE.

What You Should Be Doing:
- Create tools, APIs, and platforms to abstract and simplify operational processes.
- Write scripts or code to optimize system performance and reliability.
- Document and share best practices through playbooks and runbooks.

5. Fostering a Culture of Continuous Improvement

SRE is not a one-and-done activity; it’s a journey. If you’re not continuously learning, improving, and adapting to new challenges, you’re not embodying the true spirit of SRE.

What You Should Be Doing:
- Perform postmortems on incidents and ensure you learn from them.
- Stay up to date on industry trends, tools, and practices.
- Foster collaboration between developers and operations to align goals and priorities.

Conclusion:
Calling yourself an SRE doesn’t make you one—your actions do. Embracing these five essentials is what separates true SREs from those who are merely adopting the title. If you’re falling short in any of these areas, it’s time to reassess your practices and align with the core principles of SRE.

Call to Action:
Ready to elevate your SRE game? Explore our in-depth training programs to master these essentials and more. Visit www.itsmacademy.com and take the next step in your journey.

What do you think? Does this cover the essentials you'd want to include?

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...

What Is A Service Offering?

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group. As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. ...

What is the difference between Process Owner, Process Manager and Process Practitioner?

This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...

Search