Are SRE documents important?

SRE is a job rule and mindset and a set of engineering best practices to make web products reliable. SREs operate at the intersection between software development and systems engineering to solve operational problems to design, build and run large-scale distributed systems scalably, reliably and efficiently.

SRE core functions include

• Monitoring and metrics. Measuring how the service is actually behaving.
• Incident management response. Noticing and responding effectively to service failures in order to preserve the SLA
• Capacity planning, scaling distributed systems Project future demand to serve the increase of volume requests.
• Continue Integration and Continue Deployment solutions Provide CI/CD solutions to automate the continuous development of new application versions and push it to production systems effortlessly without manual interventions.
• Performance Design, development and engineering related to scalability, isolation, latency, throughput and efficiency.

SREs support the lifecycle of the systems before services go live, SRE help to design, consulting and making recommendation. Once the service is live, SREs maintain them by measuring performance metrics like availability, latency, response times and error rate. Once the service reach end of life, SREs decommission them in a predictable fashion with clear messaging and documentation

The Importance of Documentation

At the beginning of SRE team's existence, the org tends to grows and it heavily relies on the performance of highly skilled individuals on the team. The team develops important operational processes and principles as team's knowledge that are passed verbally to new team members. If these concepts are not written in and documented, information gets lost and procedures can get fragmented and pieces missing. If this is allowed to continue, the understanding of why these principals are in place gets lost and team loses its capacity to stay performant.

SLIs / SLOs / SLAs - Service Level Objectives

 It is crucial to observe the system's health and which behaviours really matter.

There are three measurements that I'm going to deep dive in and they are 

• Service Level Indicators (SLI)
• Service Level l Objectives (SLO)
• Service Level Agreements (SLA)

SRE - Principal Embracing Risk

Reliability comes at a cost: maximising stability limits how fast new features can be developed and how quickly products can be delivered to user.

SRE seeks to balance the risk of unavailability with the goals to innovate and efficient services with features and service and perofmance

Unreilable systems can quickly erode users' confidence.

The cost has two dimensions

• The cost of redundance machine to allow unforseen maintenance or offline routine
• The opportunity cost is when an organization allocates engineering resources to build reliable systems

SRE team manage service reliability by managing risk. The SRE identify the appropriate level of tolerance for the serivces they run. They strive to make the service reliable enough but not more reliable than it needs to be.

Measuring Service Risk

The first step in measuring risks is to identify an objective metric that represents the property of the system that we aim to optimize. We can assess our current system performance and track improvements or degradations over time by setting a target. A system can be impaired by many events, we will treat all of them as unplanned downtime. The most straightforward way to figure out the acceptable level of unplanned downtime is to capture the desired level of service availability usually expressed in terms of "nines" like 99,9%. However, the uptime concept can have multiple meanings and for most systems, usually the frontend and backend systems, the definition of availability is aligned to the request success rate. Example: A system that successfully serves 1M requests in a day with a daily availability target of 99,99% can serve up to 100 errors and still hits the target. Using the RSR allows to the wide utilization of this objective metric and use it on multiple-layer systems.

SRE - Introduction

Introduction

The sysadmin approach to Service Management

The system administrator approach involves assembling different existing software components and deploying them to work together to produce a service. 

Sysadmins are then tasked to run the service and responding to events and update as they occur. Because sysadmins role requires a different skill set than the product's developer, these they are divide into two teams, "development" and "operations" or "ops".

Site Reliability Engineering approach

The SRE team focuses on hiring software engineers to run products and to create systems to accomplish the work that would otherwise be performed, often manually by Sysadmin. 

SRE is what happens when you ask Software Engineer to design an operations team.

60% of the SRE members are Software engineers and the other 40% are engineer with some software engineer skill set with in addition had a set of technical skills that is useful to SRE but rare for most software engineers. Expertise like UNIX system, networking, database

Common to all SREs is the belief for developing software systems to solve complex problems. Diverse background of the SRE team frequently results in clever, high-quality systems.

The result of our approach for hiring for SRE is that we end up with a team of people who will quickly become bored by performing tasks by hand and to have the skill set to necessary to write software to replace their previously manual work.

SRE team ends up sharing the intellectual background with the rest of the development organization. 

Fundamentally, the SRE team is doing work that has historically been done by an operation team but using engineers with software expertise. 

Site Reliability Engineering - New Journey

 It has just happened. Inside, I knew I would need to evolve into a different kind of engineer, I was shyly overlooking what projects not related to my work were delivered, the importance of how those compared to mine, and how company-impact were systems used by many and not just by myself. I was eager to explore new concepts, techniques, mechanisms, frameworks and politics. The opportunity arose, and I understood it would have changed my life completely and it prompted in front of my eyes that I could restart and begin a new career path. I'm still a vertical Database Admin but I shifted left (or right) into another path. I discovered more interesting systems and concepts in the last two years as an SRE Engineer Manager than in the last years as a DBOps, where I strived to learn but I didn't run any relevant project. In my current job role, I have many opportunities to learn, share, and interface with others and I really want to catch the experience that will draw my future. 

Therefore, I began to build my SRE pillars and I decided to read the Site Reliability Engineering book written by SRE Engineers years ago. These posts are not intended to replace the book but these will be my thoughts on the book's paragraphs and sections. I want to take you, readers, into my journey to explore what would be an SRE.