Live data from Hacker News

New Google SRE book: Building Secure and Reliable Systems

landing.google.com

1–10 of 227 posts

Re: New Google SRE book: Building Secure and Reliable Systems

#2
I know it can happen to anyone and that every system will eventually go down no matter how many resources are spent or how smart you are. Heck, it might even be financially prudent to not chase those last 9s of uptime.

But r̶e̶l̶e̶a̶s̶i̶n̶g̶ posting this hours after a huge outage that affected most services for over an hour and also less than 12 days after a similar multi-hour outage seems somewhat ironic.

EDIT: guess I hurt someone’s feelings.

Re: New Google SRE book: Building Secure and Reliable Systems

#3
I'm wondering if this has floated to the top of HN because of the recent GCP outages (both a few days ago and from this morning). I'm trying to figure out if this is coincidental or ironic.

NOTE: As a heavy user of GCP we we're affected by the three most recent outages (GCIC20005, GCIC20004, GCIC20003), but I definitely feel for those that were impacted.

Re: New Google SRE book: Building Secure and Reliable Systems

#6

Is there a more digestible version of SRE concepts somewhere? I'm just looking for an easier way to communicate core principles and concepts to my team without asking them to sink into 500 pages?

The books read quite easy. The first book is just stories from google; it doesn’t really prescribe anything- it’s a collection of people talking about what SRE means to them and also how it fits together with “devops”.

The second book (the SRE workbook) is more prescriptive, walks through practical ways of implementing it.

The most base description of SRE principles is simply that:

1) You automate aggressively and develop or use self-service tools as much as possible (over ops work)

2) you define what “availability” really means; institute an allowance of errors based on budget. Highly reliable systems should get much more attention and budget than lower requirement systems. Make an SLO dashboard; alert based on your “error budget” being eaten too quickly.

3) try to avoid allowing your staff to work more than 50% on operations work; that’s your indicator for being overloaded.

Re: New Google SRE book: Building Secure and Reliable Systems

#8
post #2

I know it can happen to anyone and that every system will eventually go down no matter how many resources are spent or how smart you are. Heck, it might even be financially prudent to not chase those last 9s of uptime. But r̶e̶l̶e̶a̶s̶i̶n̶g̶ posting this hours after a huge outage that affected most services for over an hour and also less than 12 days after a similar multi-hour outage seems somewhat ironic. EDIT: gues…

Upvoted since I was going to make the same comment. I have been dealing with some downfall from that issue today.

As a user of their cloud services, my perception of their reliability is pretty low compared to competitors. I still like GCP the best though.

Re: New Google SRE book: Building Secure and Reliable Systems

#9
post #6

Is there a more digestible version of SRE concepts somewhere? I'm just looking for an easier way to communicate core principles and concepts to my team without asking them to sink into 500 pages?

The books read quite easy. The first book is just stories from google; it doesn’t really prescribe anything- it’s a collection of people talking about what SRE means to them and also how it fits together with “devops”. The second book (the SRE workbook) is more prescriptive, walks through practical ways of implementing it. The most base description of SRE principles is simply that: 1) You automate aggressively and de…

Anecdata: some people disbelieve this ≤50% ops time figure. At the moment my SRE team is getting some flak for exceeding 30%, which exceeds the PA's guideline of 20% for the wrong reasons.

Re: New Google SRE book: Building Secure and Reliable Systems

#10
post #2

I know it can happen to anyone and that every system will eventually go down no matter how many resources are spent or how smart you are. Heck, it might even be financially prudent to not chase those last 9s of uptime. But r̶e̶l̶e̶a̶s̶i̶n̶g̶ posting this hours after a huge outage that affected most services for over an hour and also less than 12 days after a similar multi-hour outage seems somewhat ironic. EDIT: gues…

I guess people didn't like that - "it might even be financially prudent to not chase those last 9s of uptime."

It just promotes bad mindset

Post reply on HN