Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

plus.google.com

Post reply on HN
Print view View original

31–40 of 42 posts

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

#31

Post by douche »

jonaf wrote: post #22
dkarapetyan wrote: post #6

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.

While I share your sentiment, don't forget that there is a very large pool of prospective employees who may be beneficial to a company in spite of a more narrow skill set, even if they don't grow their skill set. Take college grads for example. They're relatively inexpensive and have a moderate skill set as they begin their careers. Are they useful to hire? Yes. Do they know anything about operations? No. Is it neces…

You do have to have the willingness and ability to give on-the-job training to cultivate those skills, which is often wanting.

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

#32

Post by moises_silva »

nikolay wrote: post #27
moises_silva wrote: post #23

Earlier quoted context omitted.

I like it. What do you see terrible with it? why, and what would be in your opinion a better role name?

"Operations Engineer", for example.

I'd say that's quite more vague and doesn't quite sound like what an SRE is. You didn't answer my other questions btw.

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

#33

Post by nikolay »

moises_silva wrote: post #32
nikolay wrote: post #27

Earlier quoted context omitted.

"Operations Engineer", for example.

I'd say that's quite more vague and doesn't quite sound like what an SRE is. You didn't answer my other questions btw.

Sorry, I meant "Site Operations Engineer". "Reliability" is an adjective assumed to every subject or role.

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

#34

Post by nikolay »

closeparen wrote: post #30
nikolay wrote: post #27

Earlier quoted context omitted.

"Operations Engineer", for example.

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.

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.

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

#35

Post by spc476 »

moises_silva wrote: post #24
PhasmaFelis wrote: post #8

Earlier quoted context omitted.

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.

Finding a balance is hard. Should you define SQL? DB? HTTP? where do you start and stop defining acronyms.

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/

[2] I know, ABBR is the new hotness, but I'm still using HTML 4 for my blog and old habits die hard.

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

#36

Post by stonogo »

moises_silva wrote: post #23
nikolay wrote: post #20

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!

I like it. What do you see terrible with it? why, and what would be in your opinion a better role name?

The presence of a "reliability engineer" raises the question of what the hell all the other engineers are there for.

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

#37

Post by bostik »

nikolay wrote: post #20

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!

> I am terrified that it gets more and more popular these days!

Personally I believe this is a direct result of the absolutely massive devaluation of the term "DevOps".

The latter has become a synonym for meaningless mishmash of "everything in operations, and nothing in particular". Using the term SRE is a clear signal that we're talking about engineers with good understanding of systems and operations.

Disclaimer: this distinction is mine, and I have come to it after making the mistake of trying to hire "devops engineers". Put those two words together and your applications pipeline gets crammed with unskilled remote hands who cannot even realise they have delusions of grandeur. It's also - apparently - an invitation for every cold-emailing recruiter to spam you to death.

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

#40

Post by cakeface »

stonogo wrote: post #36
moises_silva wrote: post #23

Earlier quoted context omitted.

I like it. What do you see terrible with it? why, and what would be in your opinion a better role name?

The presence of a "reliability engineer" raises the question of what the hell all the other engineers are there for.

They are there to build features. Hopefully those features are something that solves business problems and ultimately drives revenue. Reliability is a requirement for a useful business system but is not a useful thing on its own. Your system needs to solve actual problems with software features to be useful. That is what the rest of the developers are rightly focused on.
Post reply on HN