Hacker News Reader

Comment by visviva | Hacker News Reader

SRE = site reliability engineering (as best as I can tell), for anyone else wondering.

How you can write an entire article with an acronym in the title and not define it anywhere is beyond me.

Will's a great communicator, and quite personable: I know this because I've worked with him for a few years. I don't think it's bravado, SRE is a common industry term.

So are all sorts of terms, but in the sciences at least the rule is still that you introduce the full term and its acronym the first time it is used, before switching to the acronym for the rest of the paper. Sure, everyone doing electrochemistry knows what EIS means, but you still write "electrochemical impedance spectroscopy (EIS)" before you go on.

You can adjust the strictness for audience and intent perhaps, but it's still sloppy not to.

And on your blog you can choose to use common abbreviations like OS, BIOS, and GPS without spelling them out.

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.

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.

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.

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.

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

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

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.

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.

Sre is a really common term

Me neither, I have no clue what this means either, I guess the author is in a very very small circle.

SRE/Production Engineering are common terms in the tech industry... How do you come to the conclusion that the author is the one with a "very very small circle"?

I've been an engineer and manager in a software company in europe and have only heard about what an SRE is. Now "software engineer" is a common term, but not this SRE thing.

Perhaps it's only common within silicon valley circles, that being said, the fact that the author didn't define the acronym didn't help either.

Honestly it'd be like explaining what sysadmin means nowadays. It's so common I am surprised there are sectors of the industry that don't use the term yet! But it makes sense that a person who's been blogging about SRE-work for years doesn't feel the need to define SRE. It's been around as a role since the early 2000s.

Edit: It's probably been around longer that SDET!

As a person whose job title is SRE, it’s definitely far less known than sysadmin is (where many non-tech people I talk to know the title) and is still a less known title than DevOps is. Even if the title was created 20 years ago, I don’t think SRE really started spreading as a term until the last few years.

That the title wouldn’t be well known in Europe, or fully known in the US isn’t surprising to me. I’d probably expect someone who works in the start up world to know it, and would expect anyone working at the FANG compensation level to know it, but I don’t think it’s super common among the vast middle of companies.

(And for reference, I had know idea what SDET meant until I looked it up right now, although I certainly have worked with Software Development Engineers in Test. Probably an even more obscure term?)

> That the title wouldn’t be well known in Europe, or fully known in the US isn’t surprising to me. I’d probably expect someone who works in the start up world to know it, and would expect anyone working at the FANG compensation level to know it, but I don’t think it’s super common among the vast middle of companies.

I guess that's fair.

> (And for reference, I had know idea what SDET meant until I looked it up right now, although I certainly have worked with Software Development Engineers in Test. Probably an even more obscure term?)

I'm not sure - I work as an SDET and have found work as an SDET in Oxford and London England, remote in other European countries, and am now interviewing for several companies in the Bay Area. It seems pretty universal to me! But again, maybe that's just down to the bubble one is in. FWIW, it just means a software developer who focuses on testing as opposed to frontend or backend, so managing test infrastructure, reporting, writing frameworks for devs to use for testing, etc etc...

I'm curious, have you heard of any of these: Data Engineer, Machine Learning Engineer (MLE), Staff Software Engineer.

I'm surprised you've never come across the term SRE/Production Engineer before (Assuming you meant to say "have only __just__ heard about what an SRE is"). I live in New Zealand and I'm pretty sure I knew what an SRE was before I even joined a big tech company (Not a SV one btw).

I’ve worked in tech in NZ for 7 years or so, never actually met someone who calls themselves an SRE. Obviously I know the term, but IME we don’t use that title here

Reply on news.ycombinator.com