November 2020
Beginner to intermediate
250 pages
7h 41m
English
Content preview from 97 Things Every SRE Should Know
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.
Chapter 48. Sometimes the Fix Is the Problem
Jake Pittis
If simpler systems fail less and are faster to restore, why do incident reviews focus so much on adding fixes rather than on removing components and code? When we should be reducing bug surface area and increasing operator understandability, we instead lean toward adding validation, sanity checks, traffic shifting, and synchronization—all things that add complexity. Even just fixing bugs can end up adding extra code and complexity.
Complexity is often justified with the benefits to reliability outweighing the risk of future incidents. At the end of the day, some complexity is necessary for business functionality, just as some complexity is necessary for reliability. But how often do we focus on trying to remove excess complexity?
Incident reviews are a perfect opportunity to target and remove detrimental complexity. Sometimes this can be code that increases bug surface area and sometimes it can be something that makes systems harder to understand and leads to slower incident response. In both cases, if we can show that it contributed to the incident and that it’s not necessary for reliability or business functionality, then it should be considered detrimental complexity and be removed.
Incidents give us the space to zoom out and notice detrimental complexity. If a bug leads to an incident, we can ask ourselves whether ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access
More than 5,000 organizations count on O’Reilly
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.Julian F.
I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.Addison B.
I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.Amir M.
I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.