> Even at Google, there will be different teams who will deviate from the "described process" given their business context, setup, or stakeholders.
Seriously. A lot of the book was influenced by Social SRE who had opinions all out of proportion to their own importance and success. At the time, there was some doubt about whether Social's pet theories belonged in the book, considering the varying practices and beliefs of other SRE groups supporting products that people actually use.
This is related to my rule that anybody can title their doc "Best Practices" even if nobody subscribes to them.
I wasn't around Google when the book was written but after having read it and then managing a SRE team at Google my takeaway was: the book was not a documentary on how SRE works day to day. It was a loose collection of aspirational essays and fun historical stories. The reason those stories were so fun is because they are in fact still pretty unusual.
None off the top of my head but for the engineering topics in Part III I think it pays to read them as historical background material, then read the last decade of conference papers, talks, and articles.
Example: the section on backend subsetting in distributed systems is not current. If you wanted the current Google practice you need to read "Reinventing Backend Subsetting at Google"[1], and there are other interesting publications from other organizations.
Seriously. A lot of the book was influenced by Social SRE who had opinions all out of proportion to their own importance and success. At the time, there was some doubt about whether Social's pet theories belonged in the book, considering the varying practices and beliefs of other SRE groups supporting products that people actually use.
This is related to my rule that anybody can title their doc "Best Practices" even if nobody subscribes to them.