Hacker News Reader

Comment by n42 | Hacker News Reader

this acronym is ubiquitous in the industry of this site and anyone who follows his blog. it's not unreasonable. I'm shocked someone commenting on Hacker News doesn't know it.

View on HN

I’m in the industry. Have been for years. I still have no clue what an SRE is. Like what do they do? Debug broken services? Unless you worked with people in that SRE role it’s not clear how you’re supposed to know what they do.

This article could have helped me with that but it didn’t fully. It sounded more like a rant that will totally make sense maybe to 50% of infra or devops people.

Maybe it’s me though. I actually still don’t know what a true product manager is supposed to do lol.

sre means different things to different people, it’s an overloaded term like devops. but I feel like he spent a lot of this article defining what it meant for this team - all that about embedding a dedicated person is their definition of sre

I assume it's like "Enterprise architect" only maybe less so. For EA I've heard that no two companies ever mean the same thing by the term (I barely even know how we define it, and that's the team I'm on), where SRE I think is supposedly copied from people's half-understanding of what Google says it does.

EA is design, SRE is ops/support.

This is wrong. SRE is an engineering org, NOT an ops or support org.

While it's common practice for SRE teams to share some of the operational burden, it's for the purpose to find risks and vulnerabilities and then engineer solutions to those. I have never seen SRE do support.

SREs should know how to build and run reliable and maintainable systems. Architecture and design are the best tools for that.

Not at the 3 SF financial enterprises I’ve worked at it in the last decade.

Not alike as in the same job, alike as in the same level of well-definedness.

in most places SRE is title-inflation for DevOps, but in a less cynical interpretation it's the idea of 1) having reliable enough base-layer systems that product engineers don't need to care about servers or debug networks or in the most extreme cases log in to production machines themselves 2) putting engineers who have strong systems engineering, software engineering, and debugging skills in the same seats as the most critical product teams to carry the pager and fine tune and optimize those services without reporting to the product teams' leadership whose goals might be in conflict with engineering reliable systems.

This really only happens well at Google AFAICT.

the "new SRE" team Will mentioned was a bunch of ex-Google Infra folks who brought a holy book [https://sre.google/sre-book/table-of-contents/] with them and asked us to institute these practices whole-cloth. some of them had already been phased out of google by then but how could we have known

Just because it's been phased out at Google doesn't mean it's not worthwhile. There's a lot to be learned and a lot of value to be gained out of building GFS before Colossus (Though that example is getting out of date - I would no longer recommend that anyone try to build a GFS-Patterned distributed filesystem, but for several years after the party I attended to celebrate the final death of GFS I would still recommend that new-unicorns looking to build their own distributed filesystem layer go for the GFS Architecture first).

There's a lot of techniques and tools that are no longer in favor at Google not because they're not the best available SRE tools, but because that's how far Google has fallen from grace.

This can help understand the many approaches out there, many of which are terrible and the rest are generally suitable only to some cases and not others:

https://web.devopstopologies.com/

Note it shows anti types and useful types.

Every org is different and I like to point out this article [1] to illustrate it. SRE is really what your company wants it to be. If you have full-cycle devs, then you're likely doing more platform work. If your devs lack the deploy and operate part of the cycle, then that's likely where the SREs will pickup the rest.

[1]: https://netflixtechblog.com/full-cycle-developers-at-netflix...

Site Reliability/Infrastructure/Production Engineer typically have three focusses:

Managing and scaling "software infrastructure" (Kubernetes, cloud services, databases/caches, job/message brokers, etc). SREs tend to have expertise in these systems that generalist SWEs do not.

Incident response. Many production incidents are not caused by a bug in application code, but due to some cascading failure of some piece of the software infrastructure, often due to unexpected load, performance regressions or network/hardware outages. Because SREs have a broader picture of how the various pieces of infra fit together, they're best suited to start root cause analysis and determine whether it's an infra/code issue or some combination of the two.

Devops/developer productivity. Many SREs work on build/release systems, internal tools and enforcing best practices.

Reply on news.ycombinator.com