Read this article if you’re planning to adopt SRE culture in your project/organization. Learn how to train your team and follow the best practices.
Join the DZone community and get the full member experience. The site reliability engineering (SRE) concept originated at Google and is closely related to the principles of DevOps. It is an approach to IT operations. SRE teams use the software to manage systems, solve problems, and automate operations tasks. SRE teams take the tasks that IT operations teams have done, often manually, and instead give them to engineers or ops teams who use tools and automation to solve problems and manage production systems. It is a valuable practice while creating scalable and highly reliable software systems. SRE teams help organizations manage massive infrastructure through code, which is more scalable and sustainable for system admins managing hundreds of thousands of machines. SRE acts like a bridge between software engineering and IT operations and fills the gap between them. Pretty much everywhere, SRE comes into play when it comes to preparing for failures in production systems. It ensures that the organization’s systems are scalable, reliable, predictable, and automated. SRE also sets Service Level Indicators (SLIs), Service Level Objectives (SLOs), Service Level Agreement (SLA) that defines the real numbers on performance, the objectives your team must hit to meet that agreement, and how reliable the systems need to be for the end-users. The primary goal of SRE is to improve performance and operational efficiency. So, an SRE is not just „an ops person who codes.“ Instead, the SRE is another member of the development team with a different set of skills, particularly around deployment, configuration management, monitoring, metrics, etc. An SRE is not solely responsible for these areas, just as an engineer developing a nice look and feel for an application must know how data is fetched from a data store. The entire team works together to deliver a product that can be easily updated, managed, and monitored. The need for a site reliability engineer naturally comes about when a team is implementing DevOps but realizes they are asking too much of the developers and need a specialist for what the ops team used to handle. Before we dig deeper into SREs and how SREs work with the development team, we need to understand how site reliability engineering functions within the DevOps paradigm. At its core, site reliability engineering is an implementation of the DevOps paradigm. Just as continuous integration and continuous delivery are applications of DevOps principles to software release, SRE is an application of these same principles to software reliability. There are a wide variety of ways to define DevOps. Still, the traditional model is where the development (“devs”) and operations (“ops”) teams are separated, leading to the team that writes code not being responsible for how it works when customers start using it. The development team would “throw the code over the wall” to the operations team to install and support.
