4 ms·

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 u

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"

dijit 4y ago
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-
- GauntletWizard 4y ago
  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.
  - dijit 4y ago
    > 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.
    - GauntletWizard 4y ago
      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".
- YZF 4y ago
  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).
names_are_hard 4y ago
> Note that allowbox and denybox are not acceptable substitutes here Hmm...opaquebox and transparentbox? clearbox?
- GauntletWizard 4y ago
  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.

dijit 4y ago

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-

GauntletWizard 4y ago
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.
- dijit 4y ago
  > 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.
  - GauntletWizard 4y ago
    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".
YZF 4y ago
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).

names_are_hard 4y ago

> Note that allowbox and denybox are not acceptable substitutes here Hmm...opaquebox and transparentbox? clearbox?

GauntletWizard 4y ago
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.