Introduction to SRE
Origin
In 2003, Benjamin Treynor, the creator of the term SRE, placed accountable of running a production team consisting of seven engineers. this production team aimed to form positive that Google websites were out there, reliable, and as serviceable as doable. Since Benjamin was a coder, he designed and managed the team within the approach he would have if he worked as a web site reliability engineer himself. He did this by giving the team the task of paying their time on operations tasks so that they might have a far better understanding of package in production. That team eventually became Google’s contemporary SRE team.
Google is the first to embrace the culture of SRE, but what works for Google may not work for all other organization, means the adaptation of SRE in an organization depends on different factors such as Organization size, Technology used, culture or other factors
Taken from Article, Site Reliability Engineering Best Practises and Tools
As Benjamin puts it, one in every of the tributary factors for the idea behind SRE was the division between the product development and operations team. Each of those groups has differing goals. On the one hand, the event team aims to launch new options and see. However, users adopt them. On the opposite hand, the operations team makes positive that the service doesn’t break. Once every team has its manner of doing things, it becomes tough to attain business goals.
SRE became the paradigm to manage Google‘s large-scale systems also as facilitate the continual introduction of recent options.
Site Reliability Engineering
SRE involves making a bridge between development and operations. SRE’s approach to the present is to use a package engineering mentality to system administration topics.
Site reliability engineering (SRE) may be a discipline that includes aspects of software package engineering and applies them to infrastructure and operations issues. the most goals are to form ascendible and extremely reliable software package systems.
An SRE team is answerable for the provision, latency, performance, efficiency, modification management, monitoring, emergency response, and capacity planning of their service(s)
Important Aspects of SRE
Site reliability engineers collaborate with alternative engineers, product owners, and customers to return up with targets and measures. You recognize once action ought to be taken once you’ve set a system’s period and accessibility. This is often done through service-level indicators (SLIs) and service level objectives (SLOs).
An engineer ought to have a holistic understanding of the systems also because of the connections between the systems.
Site reliability engineers have the task of guaranteeing the first discovery of issues to cut back the cost of failure.
Since the goal of SRE is to resolve issues between groups, the expectation is that each the SRE groups and also the development groups have a holistic read of libraries, front end, back end, storage, and alternative parts. And shared possession means anybody team can’t enviously own single parts.
Difference between SRE and DevOps
Both SRE and DevOps are methodologies addressing organizations’ desires for production operation management. However, the variations between the 2 doctrines are quite significant: whereas DevOps raise issues and dispatch them to Dev to unravel, the SRE approach is to seek out issues and solve a number of them themselves whereas DevOps groups would typically opt for the additional conservative approach.
SREs are a lot of assured in their ability to keep up a stable production setting and push for speedy changes and computer code updates. Not like the DevOps team, SREs additionally thrive on a stable production setting. However, one among the SRE team’s goals is to boost performance and operational potency.
The main distinction between DevOps and SRE lies. Whereas DevOps is all concerning the “What” must be done, SRE talks concerning “How” this could be done. It’s concerning increasing the theoretical half to AN economical advancement, with the correct work strategies, tools so on. It’s conjointly concerning sharing the responsibility between everybody and obtaining everybody in synchronizing with constant goal and vision.
Principle of SRE
The basic principle of SRE is that doing operations well could be a software issue. SRE ought to thus use software engineering approaches to resolve that issue.
The second principle is to possess a written Service Level Objective (SLO) for every service and to monitor performance against it. A Service Level Agreement (SLA) may be a contract between a service supplier and a client. SLOs suggests that measuring the performance of a service supplier. SLOs are composed of Service Level Indicators (SLI). AN SLI is simply one thing that you monitor— it’s a graph on your dashboard. But, after you attach a threshold to AN SLI ANd generate an alert, this could be tied to your SLO. The SLO may be a threshold for away a lot of inaccessibility are tolerated. Is your objective to possess your service offered ninety-nine per cent of the time? If thus, this implies that you tolerate ten minutes and five seconds of inaccessibility per week.
The third principle is discovered, the tougher it’s to repair. SRE addresses this issue. “SREs are specifically charged with up undesirably late problems discovery, yielding benefits for the corporate as an entire.
SLA and SLO
Each service ought to have some service level objective (SLO), that is a soft SLA that has no penalty, and no lawyers are going to be concerned if it’s incomprehensible.
The SLO of service can rely on what would be the impact if it becomes unapproachable. SLO ought to be outlined by business as they must have a concept of what’s the worth of reputation or cash of downtime.
When you analyze service risk, you wish somehow to assess the performance of the system and track enhancements – and also the focus is typically on unplanned downtime.
Availability = Uptime / (Uptime + Downtime)
or
Availability = successful requests / (successful request + failed requests)
Unplanned downtime time is captured by the required level of service availability typically expressed in terms of the quantity of “nines” we’d prefer to provide: 99.9%, 99.99%, or 99.999% availability.
The SLO could be a range that defines, however, huge some of the requests your permission to fail. It implies that’s you set your SLO at 99.9%, your error budget is 0.01%.
The error budget provides an objective metric that determines however unreliable the service is allowed to be inside one quarter. This metric removes the politics from negotiations between the SREs and therefore, the product developers once deciding what quantity risk to permit.
Conclusion
Site Reliability Engineering (SRE) is that practice which applies on both software development skills and mindset to IT operations. The goal of SRE is to improve the reliability of high-scale systems, and this is done through automation and continuous integration and delivery. Site reliability engineering involves the use of software engineering techniques that includes algorithms, data structures, performance, and programming languages to achieve web applications that are highly reliable
Also Read DevOps and SRE on Google Cloud Platform Benefits and Tools
