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

11–20 of 86 posts

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#11

Post by zzzcpan »

So, how do you choose that service level objective? How do you know which solutions to implement to not make things "overly reliable"? Isn't that more important question? As doing this without some sort of methodology will almost always result in useless solutions and overpaying to cloud and other hosting providers. Like implementing rather expensive failover within the datacenter, while ignoring how unreliable datacenters are and how cheaply you can implement failover between datacenters via DNS.

I like the idea of modelling availability/reliability for this. Even if you don't have the right numbers and do it on a napkin, not in code, it still can highlight solutions with best cost/benefit ratios.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#13

Post by zzzcpan »

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…

> how reliable things like Gmail are

Except when they aren't and even have to get data back from backup tapes.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#14

Post by strmpnk »

These distinctions started making more sense when I realize they map to OKRs which is generally how Google is said to track individual and team performance.

In general, it's good to be precise about how you measure and when something is a hard or soft boundary. Otherwise, firefighting gets out of control. It's hard to determine when to stop something and put out a fire if you can't prioritize issues based on the boundaries you've set for your system.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#15

Post by Rapzid »

bpchaps wrote: post #10
closeparen wrote: post #9

Earlier quoted context omitted.

I have to disagree. The typical and intuitive ways of reasoning about outages and outage risk - screaming at the engineers until they fix it, desperately passing the buck, finding someone to fire in the aftermath - are not a good fit for any context. Every company can benefit from a more principled mental model of system reliability.

If your company's management doesn't even know what an SRE is, then you're stuck in the same exact place, where the SREs are the one being screamed at instead. Some companies just rename "devops" to "SRE".

I think the renaming is fine as long as it also comes with the responsibility of driving the tracking and improving of site reliability :)

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#16

Post by pspeter3 »

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."

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#18

Post by sdhgaiojfsa »

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."

This is a semi-variant of Hyrum's law.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#19

Post by smueller1234 »

astockwell wrote: post #12
ProAm wrote: post #2

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

IIRC they define their customers as other internal teams, separate from external customers, who (I'm guessing) are handled by external product teams.

That's generally correct. Though a lot of SLOs of SRE teams are influenced by external commitments as well. But I suppose that's pretty obvious considering there's SRE teams supporting cloud products.

Re: SRE Fundamentals: SLIs, SLAs and SLOs

#20

Post by bpchaps »

Rapzid wrote: post #15
bpchaps wrote: post #10

Earlier quoted context omitted.

If your company's management doesn't even know what an SRE is, then you're stuck in the same exact place, where the SREs are the one being screamed at instead. Some companies just rename "devops" to "SRE".

I think the renaming is fine as long as it also comes with the responsibility of driving the tracking and improving of site reliability :)

I just renamed my microwave to "refrigerator", but all of my food caught on fire and started leaking operational debt! :(
Post reply on HN