The problem is that sysadmin has the baggage of twenty years of that dude who deals with exchange and active directory. The rules for interaction with servers under the sysadmin label were terrible and quite frankly, so were and are a lot of the people.
There is a legal requirement (regulatory, but carrying force of law) for some industries to implement ITSM practices (and similar, don't quote me on specifics) . There is a requirement in those practices that Developers not have access to production, and that Operations have access to the code. That's incredibly wrong. It's misguided in the worst possible way - The point is to make sure the two audit each other, but it requires black box auditing, when you actually want whitebox auditing. (Note that allowbox and denybox are not acceptable substitutes here).
SRE is called SRE because of a difference in those practices. DevOps is an inexpert redevelopment of those practices. Sysadmin practices evolved into both, but what's modernly called Sysadmin is descended from the AD and Exchange people, and have bad practices. You can't walk back the evolution of words, you can fix them through evolution as well, but it's as slow or slower than getting there, because the ecological niche is already "filled"
SRE actually aligns pretty neatly with systems administration (and thus, in principle ITSM)
DevOps itself as a concept was born in nebulous circumstances (“dev-ops days” being where the verbiage comes from but the founder of that conference called the job “agile systems administration; and the concepts espoused by the devops movement being almost exclusively borne out of the “10+ deploys a day” talk from Flickr).
Anyway, SRE is not materially different than Sysadmins except in three dimensions:
1. Hire only programmers, none of those operators who click buttons.
2. Treat reliability as if it is its own feature.
3. Solidify the contract between feature folks and people focusing on reliability.
I’d like Ben Treynor-Sloss to weigh in here as he likely knows best, but that’s the most condense version of what I understood
You’re right about the exchange people, but they too suffered title inflation, the exchange folks used to be called IT technicians.
The people automating AD deployments across sites and managing reliability were sysadmins, and they programmed in the most ugliest of languages to achieve that, autounattended.xml and bat files for days.
The tools are better now, but the work that devops/SRE’s do in most companies today is why sysadmins used to do in 2008-
I don't know where you were working, but process/ops problems have always been "automation opportunities" for me in my professional career.
Though the majority of efforts were around making the initial designs robust and with as few moving parts as possible; sometimes automation efforts caused more outages than the dead simple operational problems.
(see also: split-brain with pacemaker/corosync on replicated databases)
In the old days (and still today) lots of "sysadmins" were programmers. Mostly because programmers were the only people that used computers and then some of them happened to administrate those. That's at least my recollection from an academic/university setting. The ones I ran into were awesome programmers.
IMO "software reliability" shouldn't and can't be thought of as its own feature. Reliability is part of parcel of every feature. You can't make bad software reliable and good software doesn't need the "reliability" tacked on. This mindset (similar to thinking of "quality" as an add-on from the "QA team") seems very problematic to me. At the very least it's an unnatural way of getting there, at worst it just doesn't work. Where I would draw the line though is the reliability of the infrastructure, that's not the domain of the software developer, so it's totally OK to delegate that portion and draw a contract (e.g. in your item #3).
Reliability is a "component", just as "Database Access" is a component. You can't think of it as a single feature, but you should have specialists in it.
I don't disagree on any of your points. I just have to point out that part of the reason we're having this argument is the dual treadmill of title inflation and bad practices insisting they're best practices. SRE will not be the title for much longer, and DevOps was a bad title from the beginning and a flash in the pan but it was the title from 2010-2015.
> I just have to point out that part of the reason we're having this argument is the dual treadmill of title inflation and bad practices insisting they're best practices.
Yeah, that's a really good point.
> SRE will not be the title for much longer, and DevOps was a bad title from the beginning and a flash in the pan but it was the title from 2010-2015.
I hope the terms become better defined, not less, though. What do you think the next title will be.
If I knew, I'd have already put it on my LinkedIn. I see "Automation Engineer" around a bit, but I don't think that's quite right. "Cloud Architect" is already taken by a specific kind of title inflation (and a few actually great software engineers who absolutely deserve it). My best guess is around "Orchestration" - "Orchestration Engineer", "Cloud Orchestrator", maybe even "Orchestration Technician" if the vogue becomes "Humility".
I prefer simply "transparent auditing" and "transparent testing" as differentiators here. Opaque is also good but harder to say and to type and will never catch on.
There is a legal requirement (regulatory, but carrying force of law) for some industries to implement ITSM practices (and similar, don't quote me on specifics) . There is a requirement in those practices that Developers not have access to production, and that Operations have access to the code. That's incredibly wrong. It's misguided in the worst possible way - The point is to make sure the two audit each other, but it requires black box auditing, when you actually want whitebox auditing. (Note that allowbox and denybox are not acceptable substitutes here).
SRE is called SRE because of a difference in those practices. DevOps is an inexpert redevelopment of those practices. Sysadmin practices evolved into both, but what's modernly called Sysadmin is descended from the AD and Exchange people, and have bad practices. You can't walk back the evolution of words, you can fix them through evolution as well, but it's as slow or slower than getting there, because the ecological niche is already "filled"