Site Reliability Engineering

How Google Runs Production Systems

De: Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

Narrado por: Liz Porter

Newly adapted for audiobook listeners.

The overwhelming majority of a software system’s lifespan is spent in use, not in design or implementation. So, why does conventional wisdom insist that software engineers focus primarily on the design and development of large scale computing systems?

In this collection of essays and articles, key members of Google’s Site Reliability Team explain how and why their commitment to the entire lifecycle has enabled the company to successfully build, deploy, monitor, and maintain some of the largest software systems in the world. You’ll learn the principles and practices that enable Google engineers to make systems more scalable, reliable, and efficient - lessons directly applicable to your organization.

This book is divided into four sections:

• Introduction - Learn what site reliability engineering is and why it differs from conventional IT industry practices
• Principles - Examine the patterns, behaviors, and areas of concern that influence the work of a site reliability engineer (SRE)
• Practices - Understand the theory and practice of an SRE’s day to day work: building and operating large distributed computing systems
• Management - Explore Google's best practices for training, communication, and meetings that your organization can use

Download the accompanying reference guide.©2016 Google, Inc. (P)2021 Upfront Books

Excellent perspective and methodology overview for operating complex technical environments

Obviously, the book is a classic. It works well in audio format, although the narrator has a bit of an attitude in her inflection that is easier to take in small dose, such as a chapter or a drive at a time. All in all, great content.

A great resource and a decent book.

The important thing to note first is that this is a book about SRE practices at Google, not about SRE in general. As long as you approach it with the right expectations, you should be fine. It contains a lot of valuable insights into various aspects of building software products, such as toil, monitoring, deployments, releases, and more. However, the book is very uneven, and the usefulness and generality of the chapters differ a lot. Some chapters are very specific to Google and can only serve as inspiration, while others are general and can be easily applied to other companies. It can be helpful to anyone involved in building software products to develop an understanding of reliability, but don't expect to gain much directly applicable knowledge from it.

Treasure trove of knowledge but way too long

This book is a must for anyone running a SRE team. Google has done IT departments around the world a favor by sharing how its SRE teams are formed and run. However the book is very long and could easily be broken into three different books focusing on the SRE culture, technology and management. The beginning chapters of the book are the easiest to appreciate and apply at work, while the later parts like distributed computing will be different to comprehend unless you have worked with the technology.

Great book, bad narrator

The book content is really high quality but the narrator is absolutely nauseating. I would strongly recommend reading the text instead if at all possible.

Google propaganda

I didn't like it.
Google has a lot of special Google-sauce to make their mono-repo work for them. And sorta assumes everyone has the special Google-sauce.
Therefore, I don't consider most of the organizational advice applicable without modification.

An SRE is really just an Ops person that can program and is encouraged to solve their problems with code and automation.

They first make on-call seem daunting, then says it's a privilege new hires has to earn.

They spend a whole chapter on cron jobs. And make it seem like something magic Google invented....

The narrator is really robotic, maybe the voice of Google translate? It also sounds weirdly nervous at times.