5 ms·

Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

107 points by pkaeding 10y ago

mark212 10y ago
not once does the writer explain what she means by "SRE" -- yet uses it repeatedly. Spend a few words early on to define your term and then go ahead and abbreviate away. That's just writing 101.
- mark212 10y ago
  had to go all the way to her Google+ bio to find out that she's a Senior Site Reliability Engineer, so I'm guessing that SRE in this essay means that.
  - techman9 10y ago
    It's also in the title of the link on HN?
    - mark212 10y ago
      it wasn't originally
- lukasb 10y ago
  if you don't know what an SRE is, you're not the intended audience. probably half of the articles posted to HN are unintelligible to non-practitioners of that particular subfield, don't see why this should be different.
  - closed 10y ago
    I don't know. As a person who is part of a number of intended audiences, I still get frustrated when people (directing things at me) don't define acronyms when they're first used, since 1. it's a hinderence for people who are studying to become the intended audience. 2. sometimes I'm reading two literatures that use the same acronym, so it's momentarily stupifying.
  - PhasmaFelis 10y ago
    That just makes this a problem with HN rather than with the blog. HN's audience is not narrow, and it's annoying to see so many interesting titles leading to incomprehensible articles. It really helps when HN posters either clarify things a bit in the title, or if that's not practical, make a comment when you post the link.
    - moises_silva 10y ago
      Finding a balance is hard. Should you define SQL? DB? HTTP? where do you start and stop defining acronyms.
      - spc476 10y ago
        In my blog entries [1] I use the ACRONYM [2] tag with a TITLE attribute that most browsers will show when you hover over the acronym. I don't understand why it's not used more often though. [1] http://boston.conman.org/ http://boston.conman.org/ [2] I know, ABBR is the new hotness, but I'm still using HTML 4 for my blog and old habits die hard.
- dkarapetyan 10y ago
  It stands for "site reliability engineer" but the term is as meaningless as "full stack engineer".
  - moises_silva 10y ago
    I honestly don't see a problem with it in particular. Not anymore than with other titles in the industry. The title gives you a clue, but it's far from being a very specific way to find out in detail the skills/responsibilities of a given person, and because no one enforces what it means companies will use them for similar but significantly different purposes sometimes (and yeah, sometimes just to be 'cool'). It does not come as surprise to me at all that specially relatively new titles are vague.
- pkaeding 10y ago
  I've modified the title to expand the acronym. Apologies for the confusion; I forgot that not everyone's head is where mine is. (I'm not the author of the article; I just found it interesting and wanted to share.)
  - mark212 10y ago
    oh no apologies necessary. It's becoming increasingly common on HN lately and I can't fathom why people take the time to write a thoughtful piece to advocate a particular view and then immediately lose a massive amount of the audience with unexplained acronyms. Especially when it's so easy to just lay it out once.
- taesis 10y ago
  AcronymFinder.com works pretty well when you encounter an acronym you don't understand. In this case, you'd have to hit the 'Information Technology' section, as will frequently be the case on Hacker News.
- Thaxll 10y ago
  devops / sysadmin / ops / system engineer pick a name.
rb2k_ 10y ago
Here's a similar one we use a lot in all sorts of slide sets at Facebook: http://imgur.com/a/EN0G8 http://imgur.com/a/EN0G8 (Stolen from Pedro's "Notes from Production Engineering" talk: https://www.youtube.com/watch?v=ugkkza3vKbc https://www.youtube.com/watch?v=ugkkza3vKbc , Pyramid shows up around 47:30 min PE = Production Engineer. It's a similar role although not exactly the same as the usual SRE role.) It's a bit of a different view on the same underlying work. Interesting to see how they slightly differ.
dkarapetyan 10y ago
I've come to the conclusion that drawing these distinctions is actually harmful in the long run. Software engineering requires operational understanding. If you hire programmers that do not know how to spin up a VM and codify their deployment processes then hiring SREs is not really going to fix anything.
- dannypgh 10y ago
  I think it's true that you want everyone to be good at everything- you want engineers writing tests for their own code, you can't just hire software engineers in test and make it their problem. The distinction is practically useful because not everyone is an expert on everything, and if you focus your hiring around very narrow markers- e.g. ability to work with algorithms to solve a coding interview- you may not build an organization that has balanced expertise. Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. The software engineer who spent lots of time thinking about operating systems, Linux internals, and how to build reliable systems out of unreliable parts bring value to the organization in the same way that engineers who focused on mastering algorithms bring value. Everyone needs to be strong in everything, but in practice we have different strengths, and getting people with different strengths together seems to be a good idea.
  - user5994461 10y ago
    Algorithm = skill that everyone has, cheap and easy to get. OS + linux internals + reliable systems = 3 non trivial skills, harder to find and more expensive. The combination is definitely rare. > Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. If you break out the skills and hire for them independently. You'll end up with a lot of people with the common skills and barely anyone with the rarer skills and the ability to train them to others. I agree with getting people with different strengths together. It's a NP-complete hiring problem though.
    - alrs 10y ago
      In my early sysadmin years I knew absolutely nothing about algorithms while untangling infrastructure messes spawned by the educated. Most of the good ops people were scratch-and-dent smart people who came to the field without the benefit of any kind of CS education.
contingencies 10y ago
Cute title. For those who missed the reference - https://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs https://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs A business version would be good, something above the pure profit-motive... actualization as a moral, sustainable, environmental, socially engaged organization that gives more than it takes from society. (Note: This is critically different to the SV-dominant self-image band-aid approach of large scale post-profit philanthropy.)
- icebraining 10y ago
  That was the purpose behind the creation of B-Corps, which allows the company to have some public beneficial goals as part of their legal obligations, besides increasing shareholder value.
nikolay 10y ago
SRE is a terrible role name both in its abbreviated and in its fully spelled out version! Just because it originates at Google, it doesn't mean it's cool. I am terrified that it gets more and more popular these days!
- moises_silva 10y ago
  I like it. What do you see terrible with it? why, and what would be in your opinion a better role name?
  - nikolay 10y ago
    "Operations Engineer", for example.
    - closeparen 10y ago
      The term SRE espouses a philosophy that when SRE has done its job perfectly, there is no operations work because the system is reliable on its own. If you're looking for members of that school of thought, you say SRE. If you're comfortable having a "boiler room" and just need to staff it up, the terms sysadmin and devops work just fine depending on the level of coding involved.
      - nikolay 10y ago
        I dig a little bit before commenting (SRE vs DevOps), but SRE as an abbreviation is ugly and reliability is assumed for every subject or role, so, it's redundant.
        closeparen 10y ago
        SRE is about engineering systems to be reliable, which is certainly not a goal taken seriously by default. In a traditional environment the system itself is not reliable and not trying (very hard) to be; rather, the combination of system + pager-carrying operators is reliable. Many more people are paging operators to do DB replica promotions by hand, than are inplementing distributed consensus algorithms and self-healing distributed databases.
shill 10y ago
Also see Dickerson's Hierarchy of Reliability. https://docs.google.com/drawings/d/1kshrK2RLkW-XV8enmWZxeRFRgADj6d4Ru_w5txz_k9I/edit https://docs.google.com/drawings/d/1kshrK2RLkW-XV8enmWZxeRFR...
pavlik_enemy 10y ago
That's the first Google+ link I've seen in like three years.

107 points by pkaeding 10y ago

not once does the writer explain what she means by "SRE" -- yet uses it repeatedly. Spend a few words early on to define your term and then go ahead and abbreviate away. That's just writing 101.

mark212 10y ago
had to go all the way to her Google+ bio to find out that she's a Senior Site Reliability Engineer, so I'm guessing that SRE in this essay means that.
- techman9 10y ago
  It's also in the title of the link on HN?
  - mark212 10y ago
    it wasn't originally
lukasb 10y ago
if you don't know what an SRE is, you're not the intended audience. probably half of the articles posted to HN are unintelligible to non-practitioners of that particular subfield, don't see why this should be different.
- closed 10y ago
  I don't know. As a person who is part of a number of intended audiences, I still get frustrated when people (directing things at me) don't define acronyms when they're first used, since 1. it's a hinderence for people who are studying to become the intended audience. 2. sometimes I'm reading two literatures that use the same acronym, so it's momentarily stupifying.
- PhasmaFelis 10y ago
  That just makes this a problem with HN rather than with the blog. HN's audience is not narrow, and it's annoying to see so many interesting titles leading to incomprehensible articles. It really helps when HN posters either clarify things a bit in the title, or if that's not practical, make a comment when you post the link.
  - moises_silva 10y ago
    Finding a balance is hard. Should you define SQL? DB? HTTP? where do you start and stop defining acronyms.
    - spc476 10y ago
      In my blog entries [1] I use the ACRONYM [2] tag with a TITLE attribute that most browsers will show when you hover over the acronym. I don't understand why it's not used more often though. [1] http://boston.conman.org/ http://boston.conman.org/ [2] I know, ABBR is the new hotness, but I'm still using HTML 4 for my blog and old habits die hard.
dkarapetyan 10y ago
It stands for "site reliability engineer" but the term is as meaningless as "full stack engineer".
- moises_silva 10y ago
  I honestly don't see a problem with it in particular. Not anymore than with other titles in the industry. The title gives you a clue, but it's far from being a very specific way to find out in detail the skills/responsibilities of a given person, and because no one enforces what it means companies will use them for similar but significantly different purposes sometimes (and yeah, sometimes just to be 'cool'). It does not come as surprise to me at all that specially relatively new titles are vague.
pkaeding 10y ago
I've modified the title to expand the acronym. Apologies for the confusion; I forgot that not everyone's head is where mine is. (I'm not the author of the article; I just found it interesting and wanted to share.)
- mark212 10y ago
  oh no apologies necessary. It's becoming increasingly common on HN lately and I can't fathom why people take the time to write a thoughtful piece to advocate a particular view and then immediately lose a massive amount of the audience with unexplained acronyms. Especially when it's so easy to just lay it out once.
taesis 10y ago
AcronymFinder.com works pretty well when you encounter an acronym you don't understand. In this case, you'd have to hit the 'Information Technology' section, as will frequently be the case on Hacker News.
Thaxll 10y ago
devops / sysadmin / ops / system engineer pick a name.

rb2k_ 10y ago

Here's a similar one we use a lot in all sorts of slide sets at Facebook: http://imgur.com/a/EN0G8 http://imgur.com/a/EN0G8 (Stolen from Pedro's "Notes from Production Engineering" talk: https://www.youtube.com/watch?v=ugkkza3vKbc https://www.youtube.com/watch?v=ugkkza3vKbc , Pyramid shows up around 47:30 min PE = Production Engineer. It's a similar role although not exactly the same as the usual SRE role.) It's a bit of a different view on the same underlying work. Interesting to see how they slightly differ.

dkarapetyan 10y ago

I've come to the conclusion that drawing these distinctions is actually harmful in the long run. Software engineering requires operational understanding. If you hire programmers that do not know how to spin up a VM and codify their deployment processes then hiring SREs is not really going to fix anything.

dannypgh 10y ago
I think it's true that you want everyone to be good at everything- you want engineers writing tests for their own code, you can't just hire software engineers in test and make it their problem. The distinction is practically useful because not everyone is an expert on everything, and if you focus your hiring around very narrow markers- e.g. ability to work with algorithms to solve a coding interview- you may not build an organization that has balanced expertise. Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. The software engineer who spent lots of time thinking about operating systems, Linux internals, and how to build reliable systems out of unreliable parts bring value to the organization in the same way that engineers who focused on mastering algorithms bring value. Everyone needs to be strong in everything, but in practice we have different strengths, and getting people with different strengths together seems to be a good idea.
- user5994461 10y ago
  Algorithm = skill that everyone has, cheap and easy to get. OS + linux internals + reliable systems = 3 non trivial skills, harder to find and more expensive. The combination is definitely rare. > Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. If you break out the skills and hire for them independently. You'll end up with a lot of people with the common skills and barely anyone with the rarer skills and the ability to train them to others. I agree with getting people with different strengths together. It's a NP-complete hiring problem though.
  - alrs 10y ago
    In my early sysadmin years I knew absolutely nothing about algorithms while untangling infrastructure messes spawned by the educated. Most of the good ops people were scratch-and-dent smart people who came to the field without the benefit of any kind of CS education.

contingencies 10y ago

Cute title. For those who missed the reference - https://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs https://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs A business version would be good, something above the pure profit-motive... actualization as a moral, sustainable, environmental, socially engaged organization that gives more than it takes from society. (Note: This is critically different to the SV-dominant self-image band-aid approach of large scale post-profit philanthropy.)

icebraining 10y ago
That was the purpose behind the creation of B-Corps, which allows the company to have some public beneficial goals as part of their legal obligations, besides increasing shareholder value.

nikolay 10y ago

SRE is a terrible role name both in its abbreviated and in its fully spelled out version! Just because it originates at Google, it doesn't mean it's cool. I am terrified that it gets more and more popular these days!

moises_silva 10y ago
I like it. What do you see terrible with it? why, and what would be in your opinion a better role name?
- nikolay 10y ago
  "Operations Engineer", for example.
  - closeparen 10y ago
    The term SRE espouses a philosophy that when SRE has done its job perfectly, there is no operations work because the system is reliable on its own. If you're looking for members of that school of thought, you say SRE. If you're comfortable having a "boiler room" and just need to staff it up, the terms sysadmin and devops work just fine depending on the level of coding involved.
    - nikolay 10y ago
      I dig a little bit before commenting (SRE vs DevOps), but SRE as an abbreviation is ugly and reliability is assumed for every subject or role, so, it's redundant.
      - closeparen 10y ago
        SRE is about engineering systems to be reliable, which is certainly not a goal taken seriously by default. In a traditional environment the system itself is not reliable and not trying (very hard) to be; rather, the combination of system + pager-carrying operators is reliable. Many more people are paging operators to do DB replica promotions by hand, than are inplementing distributed consensus algorithms and self-healing distributed databases.

shill 10y ago

Also see Dickerson's Hierarchy of Reliability. https://docs.google.com/drawings/d/1kshrK2RLkW-XV8enmWZxeRFRgADj6d4Ru_w5txz_k9I/edit https://docs.google.com/drawings/d/1kshrK2RLkW-XV8enmWZxeRFR...

pavlik_enemy 10y ago

That's the first Google+ link I've seen in like three years.