I'm a freelancer who always winds up as "the ops person", and I'm just waiting for my copy of this book to come from Amazon. I watched a video of a talk about this book---sadly I can't find it on Youtube anymore. A HN comment linked to it last week. It was interesting but I'm hoping the book will have a lot more meat.

A few thoughts:

> Google places a 50% cap on the amount of “ops” work for SREs: Upper bound. Actual amount of ops work is expected to be much lower

I didn't catch the "upper bound" part from the talk. Good to know! I really enjoy being a developer-who-does-ops. I wouldn't want to be a sysadmin, and 50% ops is probably my limit for happiness.

> I don’t really understand how this is an example of circumventing the dev/ops split

I felt the same way from the Youtube talk. I think there must be a lot behind the SRE role that makes it successful or not: culture, policies, who you hire, how you train, etc. Also I feel like the best sysadmins have been encouraging coding and automation for a long time, e.g. Thomas Limoncelli. But I've certainly been on the "dev" side of the dev-vs-sysadmin fight before, and it makes sense to be seeking ways to improve things.

> Error budget. 100% is the wrong reliability target for basically everything

I think I saw just this month that Google Apps uptime is 99.95%? Some major Google service. I remember in the early 2000s everyone cared about "5 9s", and I feel like for most of us that is just not worth the effort.

> Chubby was so reliable that teams were incorrectly assuming that it would never be down

This reminds me of Nygard's point in Release It! that your theoretical best SLA is the product of your dependencies' SLAs, e.g. 0.999 * 0.999 = 0.998. But in the world of microservices, this logic seems likely to make you underestimate your uptime.

Also I think Feynman's remarks about the Challenger accident apply here: if you are building a new product with, say, 5 microservices, you don't know the reliability of any of them yet. It's dubious to estimate low-frequency events based on "it's hasn't happened yet."

Thanks for sharing your notes. I'm envious you've already got a copy. :-)