SRE has been generated in Google Company. It is made of a software engineer’s team, who works with the collaboration between development and operation teams.

The main motive of SRE is to enhance reliability and problem-free function in software. It uses the automation tool to keep the work inflow as well as reduce the toil and remove human errors.

According to 2021 reports, around 22% of organizations have adopted SRE so far. SRE runs with a concept that failure is a software problem, so they run with belief that accepts the failure and work over that to be in reality, because not a single system is perfect.

As SRE has been removed the silos, it works with the collaboration between the development and operation team to enhance the product reliability and to deliver faster services.  Monitoring and logging are keys to SRE roles, as monitoring is to keep track of what’s happening in real-time, whereas, Logging is an archive of what has happened, so you can examine it later.

What are SLA, SLO, and SLI in SRE?

Service Level Agreement

An SLA is an agreement where involves a promise to someone who uses your service, that SLO should meet its availability on a certain level by a certain period and if it fails to make it possible then some kind of penalty will be charged.

In other words, SLA is a Vendor and User agreement and a Customer-centric metric that defines the oblige functionality, performance, and reliability of a product or service and the penalty for non-compliance as well.

 It also helps in establishing clarity and trust between the both company and the customer. If the company couldn’t perform the terms agreed in the SLA then it is liable to pay the loss incurred to its customers.

Those companies provide a free service to users, don’t need an SLA.

If SLO is there in your SLA that is different from your internal SLO, it’s important to measure clear-cut SLO compliance for your monitor.

Service Level Objective (SLO).

Service level objectives (SLO) is the one that states a target level for the reliability of the service, as SLO is the key to making data-driven decisions about reliability. These are numerical reliability and performance targets that should be maintained by a developer or an SRE while building and scaling a product. Any changes in the product or service should fall under these defined target values.

SRE starts with the idea that a prerequisite to success is availability. A system that is unavailable can’t perform its function and will fail by default. The term availability in SRE defines whether a system is competent to fulfill its function at the time. Also to be used as a reporting tool, the historical availability measurement can also explain the probability, your system can perform as expected in the future or not.

It’s not possible to manage a service correctly, without understanding what behaviors really matter for that service and how to measure and evaluate those behaviors.

The key to SLOs is simplicity and clarity. 

SLA’s are only contingent in the case of paying customers, where SLO’s could be useful for both paid and unpaid accounts, as well as internal and external customers.

SLOs let the IT and DevOps teams as well have a goal or metric to measure their performance.

A service might have more than one SLOs, and they apply to both paying and non-paying customers as well as internal clients in the same organization. For e.g, when a customer-facing team uses tools given by another team within the organization, the two teams need to have clearly defined service level objectives, so the customer-facing teams can meet their contractual obligations.

SLO should be effective, it must not be unclear, complicated, or impossible to measure. The document should contain the relevant SLO’s and be spelled out in plain language to provide clarity. It is also important to keep in mind the other issues like delays from the client.

Service Level Indicator (SLI).

Service Level Indicator (SLI) is a measurement of a service’s behavior, defined as the recap of successful inquiry of our system. To check the SLO availability, we look at SLI to get the service availability percentage. If it goes below the stated SLO, then we will have to make the system more available in some way, such as by running a second occasion of the service in a different city and load-balancing between the two.

SLI is a measure of compliance with an SLO, which means there is no SLI without SLO.

Mostly the SLI directly measures a service level of interest, but sometimes only a proxy is available as the desired measure might be tough to get or explain.

Another kind of importance of SLI to SREs is availability or the fraction of the time when a service is usable.

Since SLIs need to cover the entire terrain of an engineering platform, they can be widely classified into:

1. User-interfacing SLIs: All services or applications that the user interacts with within a requests-response. Example – All REST APIs serving web applications, mobile apps, and desktop applications.
2. Data-processing SLIs: All services or processes that crunch data on indirect or direct customer requests. Example – Data streaming services, batch applications, ETL tools, event-sourcing services, etc.

Training Place

I would like to tell you about one of the best places to get trained and certification in DevOps, DevSecOps, and SRE courses is DevOpsSchool. This Platform offers the best trainers who have good experience in DevOps and also they provide a friendly eco-environment where you can learn comfortably and free to ask anything regarding your course and they are always ready to help you out whenever you need, that’s why they provide pdf’s, video, etc. to help you.

They also provide real-time projects to increase your knowledge and to make you tackle the real face of the working environment. It will increase the value of yours as well as your resume. So do check this platform if you guys are looking for any kind of training in any particular course and tools.

Before we start let’s talk about what is SRE. SRE is the one who works with the software engineers with the collaboration between developers and operation teams.

SRE is a practice that combines both software development skills and mindset to IT operations. The main focus of SRE is to enhance the reliability and performance of applications, with automation and continuous integration and delivery.

SRE has changed the traditional way of working as an operation team by incorporating new technologies, ideas, and methods. SRE was originated at Google.

After originated more than 1000 SRE engineers employed at Google. Even though after spread about SRE, other software companies also started adopting SRE engineers gradually. As per the 2021 report, 22% of organizations in a survey of 2,000 respondents have adopted the SRE model.

SRE accepts failure because they know failure is a part of success and not a single system is perfect. SRE and DevOps both work to bridge the gap between development and operations teams to deliver faster services. SRE has removed the “silos” between development and operation teams to function effectively.

SRE also works with the DevOps team to help them in operational works to give reliable service to the customer.

SRE Skillsets

SRE is a role that requires a software developer with operational experience or as a system admin or engineer for an IT operations role that has software development skills as well.

SRE needs some skillsets to have are-

Deep knowledge of version control.

Sound knowledge of operating Systems (like LINUX).

Should be aware of DevOps concepts and best practices.

CI/CD implementation expertise.

Issue troubleshooting experience.

Communication & Collaboration skills.

Good knowledge of Cloud-native applications.

Good understanding of “Distributed computing”

Should know “coding”

Even though with these skills they should know tools sets as well which will be used by the SRE team.

Some toolsets are –

S.no       Problems                                        Tools                           

1              Operating Systems              –               Centos/Ubuntu & VirtualBox & Vagrant

2              Cloud                                   –                 AWS

3              Containers                           –                Docker & Kubernetes – Helm

4              Planning and Designing –             –                Jira & Confluence

5              Source Code Versioning                –            –                   Git using Github

6              Webserver                          –                    Apache HTTP & Nginx

7              Configuration & Deployment Management            –            Ansible

8              Infrastructure Coding                            –           Terraform

9              Services mesh Data planes & Control Planes            –      Envoy & Istio

10           Network configurations and Service Discovery         –        Consul

11           Continuous Integration                  –                   Jenkins

12           Securing credentials                       –          HashiCorp Vault & SSL & Certificates

13           Infrastructure Monitoring                   –            Datadog, Prometheus with Grafana

14           Log Monitoring                  –                   Splunk & ELK stake

15           Performance & RUM Monitoring                   –                 NewRelic

16    Emergency Response & Alerting & Chat & Notification – SMTP, SES, SNS, Pagerduty & Slack    

SRE Roles and responsibilities. 

SRE teams are responsible for how code is deployed, configured, and monitored, as well as the availability, latency, change management, emergency response, and management capacity of services in production.

SRE helps teams to determine what new features can be incorporated and when by using service-level agreements (SLAs) to define the required reliability of the system through service-level indicators (SLI) and service-level objectives (SLO).

SRE takes back the collected data to the development team to fix the issue (means the vulnerabilities which shouldn’t be there while development) and not make it again next time.

Monitoring and logging are keys to SRE roles. In monitoring, they are keeping track of what’s happening in real-time. Logging is an archive of what has happened, so you can examine it later.

Monitoring will give you the ability to anticipate failures and see them coming, so you can proactively solve them.

Logging is like, when you get an unanticipated failure, it makes you get back and see what happened. So you can do RCA (Root cause analysis) and find out how to solve it, not for now but for the future.

So as an SRE expert you are responsible to monitor the product and fixing the issues, bugs, blot wares, etc by the use of automation to eliminate some extent of manual work. 

Automation is an essential part of the SRE. With automation, we can reduce the manual work even though fix the issue on which we have to work again n again. This also helps to reduce the toil.

Maintaining the balance between operations and development work is also one of the roles of SRE.

Training Place

I would like to tell you about one of the best places to get trained and certification in DevOps, DevSecOps, and SRE courses is DevOpsSchool. This Platform offers the best trainers who have good experience in DevOps and also they provide a friendly eco-environment where you can learn comfortably and free to ask anything regarding your course and they are always ready to help you out whenever you need, that’s why they provide pdf’s, video, etc. to help you.

They also provide real-time projects to increase your knowledge and to make you tackle the real face of the working environment. It will increase the value of yours as well as your resume. So do check this platform if you guys are looking for any kind of training in any particular course and tools.

Stephen Thorne, customer reliability engineer at Google, recently spoke at the DevOps Enterprise Summit London on what Site Reliability Engineering (SRE) is and how many organizations are failing to understand its basic premises and benefits . Confounding service level objectives (SLOs) which are focused on early failure detection with service level agreements(SLAs) which often serve as financial compensation for past incidents, not enforcing error budgetsand not dedicating at least 50% effort of SRE teams to improve the systems and tools (instead letting them continue to drown in toil, aka “firefighting” in production) are some keys misunderstandings that Thorne has seen in other organizations.

SLOs are fundamental in detecting issues early, ideally before the effects become visible to customers, added Thorne. A good SLO is aligned with outcomes for the customer (service availability or response time, for example) and thus reflects whether the system (behavior) is meeting user needs. Resource usage (like CPU utilization or network throughput) should be monitored, but not used as an SLO per se. Thorne put it simply as “if the customer is happy, then the SLO is being met”. Typical SLOs at Google include:

• uptime of 99.9% a month (i.e. 43 minutes of downtime a month)
• 99.99% of HTTP requests in a month succeed with a 200 OK
• 50% of HTTP requests returned in under 300ms

SLAs, on the other hand, typically come into play when customers are already dissatisfied with a service, thus failing to proactively improve the system’s reliability. Further, SLAs can lead to the wrong incentives, for example combining an SLA of 2 hours to fix an email issue with an SLA of 1 day to fix a serious production incident might lead to working on one (or more) email problems first although clearly the production issue should be the priority.

Just defining SLOs is not enough, Thorne warned. Error budget policies enable meeting SLOs by setting clear rules for action (not monetary compensation) before a system gets close to an SLO’s threshold. This also minimizes confrontation between ops and dev when systems are failing to meet user needs. “The error budget is the gap between perfect reliability and our SLO” said Thorne. For Google, a typical error budget policy is to disallow launching new features once an application has exhausted its error budget (for example, already over the 43 minutes downtime budget for this month), or dedicating a sprint to corrective actions stemming from previous post-mortem analysis.

Thorne stressed, however, that what works for Google won’t work for every organization: “SRE needs SLOs with consequences that balance an acceptable level of failure with the necessary cost and speed of delivery”. Exact SLOs and policies must be adequate for the organization – not a copy/paste from Google – and focus on continuously improving customers’ experience, not on setting lofty goals or hard punishments that could be counterproductive. Thorne gave the example of one organization struggling to reduce the processing time of a recommendations system. Turned out that users would only see those recommendations when they came back to the site, on average 6 hours later. An adequate SLO was to process all recommendations within 6h, which meant they could save the cost of 3 halftime engineers previously working on the perceived “issue” of slow response time.

Empowering SRE teams to balance workload between every day (often unplanned) ops work and planned work to reduce toil (aka “firefighting”) is the third key to SRE, said Thorne. At Google, this means at least 50% of SRE effort is spent on project work: early consulting on new systems’ architecture to identify resiliency anti-patterns (and avoid more toil later on), improving monitoring, automating repetitive tasks, or coordinating the implementation of postmortem corrective actions.

Thorne further referenced some clear anti-patterns to implementing SRE such as simply rebranding the ops team to SRE team or hiring for SRE engineers without first putting in place the SRE principles and mechanisms (SLOs, error budget policies and balancing workload) for success.

These are 5 key steps to get on the right path to SRE, according to Thorne:

1. define contextual, customer-focused SLOs
2. define sensible error budget policies
3. hire (internally or externally) SREs and empower them via leadership support
4. allow SREs to finetune SLOs and enforce error budget policies
5. assign responsibility for mission-critical systems’ reliability to SRE teams, other systems under the responsibility of the corresponding development team

Google developed and expanded the site reliability engineering discipline internally for some years, before condensing their lessons learned into the SRE book. Thorne mentioned an accompanying SRE workbook will be coming out later this month.