SRE at google works closely with devs to architect and build systems together. Most of them are on the SWE ladder, are able to bug fix and scale directly. They're not just ops.

The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.

If SRE cannot throttle the release cadence or fix bugs or change architecture in binaries, it's not really SRE.

▲

deadnomore 5 hours ago | parent | next [-]

When I worked at Google SREs only handled legacy products that were maintained but not in active development. SRE was its own vertical separate from SWE and they would only take on maintenance of a new service or product if SWE could prove to them it was stable.

	▲	okdood64 5 hours ago \| parent [-]
		I know Google SREs who do feature development on the infrastructure support they support alongside their devs.

▲

rubiquity 6 hours ago | parent | prev [-]

Nice I started a timer for how quickly a "well actually, SRE at google" would show up and you did not fail to deliver.

> The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.

Sounds like a cultural issue. Google should look into that.

▲

RexySaxMan 5 hours ago | parent | next [-]

Why is your response so pithy? Google invented the term SRE, and I think how they use SRE is pretty relevant to the discussion.

▲

everfrustrated 5 hours ago | parent | next [-]

Oddly the industry mostly rejected googles application of SRE even as they adopted the term. I've only seen Google use it to refer to engineers maintaining / operating someone elses code.

	▲	coryrc 4 hours ago \| parent [-]
		> I've only seen Google use it to refer to engineers maintaining / operating someone elses code. You didn't look around very hard then. I acknowledge that certain areas of the company can consistently use subsets of a role, so you may not have encountered it personally, but your view is definitely wrong about the role in the company as a whole.

▲

aleksiy123 5 hours ago | parent | prev [-]

It’s cause they don’t know what they are talking about.

Easier to shit on people and things with hot take then actually have a grounded and coherent argument or realise that different companies/teams have different constraints, problems and environments they operate as well as different solutions.

▲

ImPostingOnHN 6 hours ago | parent | prev | next [-]

It turns out it's easier to hire people who specialize in scalability, reliability, debugging of distributed complex systems, cost ops, efficiency gains, etc. than it is to instantly ensure every single engineer that works there is an expert in all those things, without anybody on staff who is an expert in them. Much like database skills, IT security skills, etc.

It's still something everyone can theoretically learn, of course, and someone who works in that role is most effective by instilling those disciplines in others as they go, and making everyone successful.

▲

hparadiz 6 hours ago | parent | prev | next [-]

He's right you know.

▲

unethical_ban 5 hours ago | parent | prev [-]

A cultural issue that many organizations face. Same reason most large companies have an infosec department that runs separately from IT.