Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SRE Fundamentals: SLIs, SLAs and SLOs

cloudplatform.googleblog.com

Post reply on HN
Print view View original

31–40 of 86 posts

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#31

Post by ssdd »

pspeter3 wrote: post #16

This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."

I guess what meant here is that one should never make mistake of assuming that a highly reliable system can be built. As you start to approach near 100% reliable system, you start experiencing failures that are caused by minute disturbances/flaws in underlying dependencies(hardware, physical location) which can't be controlled. This is what they realized while trying to push the limits to build highly reliable system.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#32

Post by iamdave »

jsmthrowaway wrote: post #26
iamdave wrote: post #5

Earlier quoted context omitted.

The joke in that scene always baffled me, because the Marines are born of the Navy and still carry a lot of the Navy's epistemology-why would they be taught something so fundamental so differently? (Yes it's a joke but sometimes I overthink things, heh)

The original joke involved simply the demonym for the servicemember and can be used with any service, and says “they teach sailors/soldiers/airmen to ...” and “well they teach marines/etc ...,” which would probably make you less confused by the joke. I heard that joke growing up involving airmen in both directions of the joke, and it was common until that film. Relatedly, in case you don’t know this, never think you…

Relatedly, in case you don’t know this, never think you can call a marine a sailor based on the lineage you’re discussing here.

As an Army veteran (who doesn't really like announcing himself as such when doesn't add to the discussion), quite well aware. I do-however make light-hearted jokes about Crayons from time-to-time ;) It's a fun sibling rivalry we have, the Army and the Corps.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#33

Post by anonacct37 »

rahimnathwani wrote: post #4
ProAm wrote: post #2

This is an interesting article from a company that has almost nil customer support.

From the movie The Negotiator: A Marine and a sailor are taking a piss. The Marine goes to leave without washing up. The sailor says, 'In the Navy they teach us to wash our hands.' The Marine turns to him and says 'in the Marines they teach us not to piss on our hands'. BTW it's not true that Google has almost nil customer support. There's extensive support for paying customers (for ads, GCP, GSuite etc.). But it's a…

I have a $700 dollar phone I bought from Google with apps made by Google and Gmail search hasn't worked in weeks.

Don't know if I got feature flagged or what. Unaffected by clearing data, clearing cache, or signing out of my account.

Search just returns nonsensical results.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#34

Post by ksmith14 »

pspeter3 wrote: post #16

This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."

The Google SREs mentioned this in their book; the Chubby locking service had uptime that was so high that folks started to neglect making their own services resilient to Chubby failures: https://landing.google.com/sre/book/chapters/service-level-o...

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#35

Post by oblio »

bpchaps wrote: post #7

When reading these articles, never forget that your company is NOT Google! If your company doesn't have a management/infrastructure/communication/skill structure that Google has, then it will be very difficult to implement these fundamentals. In many cases, an SRE is a job to save costs. If your company doesn't get its shit together and doesn't give your SREs the support it needs, then they'll hate their jobs and the…

I have no idea why you’re being downvoted. It’s the same thing as Borg/Kubernetes, MapReduce/Hadoop: some things just don’t apply or aren’t as effective unless you’re operating at a huge scale and with Google’s culture.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#36

Post by jessaustin »

jldugger wrote: post #6
iamdave wrote: post #5

Earlier quoted context omitted.

The joke in that scene always baffled me, because the Marines are born of the Navy and still carry a lot of the Navy's epistemology-why would they be taught something so fundamental so differently? (Yes it's a joke but sometimes I overthink things, heh)

I've also seen it as Harvard and MIT graduates, then someone comes in, washes his hands first, saying "at Yale, they taught us to wash our hands before touching a holy object."

I thought one of the advantages of the "holey" variety was that you don't have to put your hands on anything to piss... ehh, Eli.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#37

Post by mav3rick »

ksmith14 wrote: post #34
pspeter3 wrote: post #16

This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."

The Google SREs mentioned this in their book; the Chubby locking service had uptime that was so high that folks started to neglect making their own services resilient to Chubby failures: https://landing.google.com/sre/book/chapters/service-level-o...

Still that's bad design on the clients' part. E.g. - Just because malloc "never" fails doesn't mean it can't fail :) so better error check for it.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#38

Post by Filligree »

mav3rick wrote: post #37
ksmith14 wrote: post #34

Earlier quoted context omitted.

The Google SREs mentioned this in their book; the Chubby locking service had uptime that was so high that folks started to neglect making their own services resilient to Chubby failures: https://landing.google.com/sre/book/chapters/service-level-o...

Still that's bad design on the clients' part. E.g. - Just because malloc "never" fails doesn't mean it can't fail :) so better error check for it.

Doesn't matter. Engineering around human failure is part of the profession.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#39

Post by kjeetgill »

Filligree wrote: post #38
mav3rick wrote: post #37

Earlier quoted context omitted.

Still that's bad design on the clients' part. E.g. - Just because malloc "never" fails doesn't mean it can't fail :) so better error check for it.

Doesn't matter. Engineering around human failure is part of the profession.

That's a beautiful way to put it. I'd read that book.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#40

Post by robax »

ksmith14 wrote: post #34
pspeter3 wrote: post #16

This is a great article for defining terms. For some reason though, this quote made me laugh out loud: "Excessive availability can become a problem because now it’s the expectation. Don’t make your system overly reliable if you don’t intend to commit to it to being that reliable."

The Google SREs mentioned this in their book; the Chubby locking service had uptime that was so high that folks started to neglect making their own services resilient to Chubby failures: https://landing.google.com/sre/book/chapters/service-level-o...

+1 for this book. As a junior DevOps engineer this book has been super helpful.
Post reply on HN