Book Image

Real-World SRE

By : Nat Welch
Book Image

Real-World SRE

By: Nat Welch

Overview of this book

Real-World SRE is the go-to survival guide for the software developer in the middle of catastrophic website failure. Site Reliability Engineering (SRE) has emerged on the frontline as businesses strive to maximize uptime. This book is a step-by-step framework to follow when your website is down and the countdown is on to fix it. Nat Welch has battle-hardened experience in reliability engineering at some of the biggest outage-sensitive companies on the internet. Arm yourself with his tried-and-tested methods for monitoring modern web services, setting up alerts, and evaluating your incident response. Real-World SRE goes beyond just reacting to disaster—uncover the tools and strategies needed to safely test and release software, plan for long-term growth, and foresee future bottlenecks. Real-World SRE gives you the capability to set up your own robust plan of action to see you through a company-wide website crisis. The final chapter of Real-World SRE is dedicated to acing SRE interviews, either in getting a first job or a valued promotion.
Table of Contents (13 chapters)

Blameless postmortems

A topic we have touched upon is the key adjective usually attached to postmortems—blameless. Postmortems used improperly can lead to really dangerous and toxic cultures, where people are afraid of outages or feel incapable of doing their jobs because of the fear of failure. Start with a fact—we all fail. As humans, failure is one of our most defining traits. One of the key tenets of SRE is that if you are going to fail, set up your organization so that it is not a big deal and you can quickly recover and learn from the failure. Another tenet is that reliability is a team sport. Everyone needs to feel comfortable raising issues, responding to outages, and working on improving the system. Fostering that level of psychological safety is difficult and constantly needs reinforcement and help.

Note that, in the Root cause section, we did not point out the person who made the change that broke the system, nor the person who wrote code that couldn't handle the user interaction...