3 ms·

It's really a shame that "SRE" came to mean entry level server janitor at so many companies when it strikes me as a very senior role.

by pram 10y ago

brian-armstrong 10y ago
Isn't there always a fundamental tension like this between people who build and people who maintain?
- donut 10y ago
  This essay talks about the difference between thinkers, doers and janitors. http://multithreaded.stitchfix.com/blog/2016/03/16/engineers-shouldnt-write-etl/ http://multithreaded.stitchfix.com/blog/2016/03/16/engineers... In it the difference is erased and people are reorganized in a, I think, more productive way.
- jimbokun 10y ago
  As a person who builds, I am awfully grateful for the people who maintain, as my stuff would never work without them.
  - brian-armstrong 10y ago
    I think devs should be responsible for maintaining what they build. You get your incentives aligned better that way, and it removes the tension.
    - packetslave 10y ago
      This is actually covered pretty well (imho) in Chapter 32. Many services start out wholly supported by their developers, and are only onboarded to SRE after they reach a certain level of maturity (and/or criticality to the business) Even after SRE takes over operations of a service, developers remain closely involved, and in many cases have their own pager rotation for "something's really broken, SRE has stopped the user-visible bleeding, but we need a code owner to jump in and help solve the root issue."
    - jimbokun 10y ago
      Well, I haven't read the book yet, but the commentary seems to suggest the SRE's role is more to teach the devs how to make their software maintainable, scalable and reliable, and then verify it really meets all of those traits. As a developer, that is a service I greatly value, and greatly respect those who have that knowledge and experience.
- user5994461 10y ago
  Never understood why that should be separate people. Actually, dont understand how it could be separate people either.
  - sh_tinh_hair 10y ago
    That's a relatively new concept. Traditional developers didn't understand much about systems design for scalability, redundancy and much less about operational discipline and systems change management (and in my experience many developers still don't).
jmspring 10y ago
I don't know if it has changed, but one thing I enjoyed about living in Finland in the early 2000s was that a janitor and a director at a company were given the same respect. If was more about contributing to the society. Your comment on SRE -> server janitor is interesting. Especially in the land of DevOps. Companies are looking for ways out, to have people do multiple things and not necessarily acknowledge complexity, experience when things go sideways, etc. Being able to get things to run smoothly, having the background to know when X happens and where to look, being able to plan and intelligently navigate future capacity, etc. is incredibly important. The ops roles that used to exist, places like Google keep them, but a lot of companies do not.
- _d8fd 10y ago
  The only problem with being a server janitor is there being a communication mismatch. I've worked with a sys admin type who was told, before being hired, he'd be a space janitor. He loved the reference, because that's what he wanted to do. If you need a dog crap collector, sell the job as a poop scooper, not a pre-compost collections technician.
dannypgh 10y ago
SREs with the time and ability (and you don't want to hire those who lack the ability) to do so will automate away whatever operations tasks being a "server janitor" entails. Hence the need of management to ensure they have the time, and that bureaucracy doesn't stand in their way. I once had a "software engineering" gig where I found a way to reduce the labor of the tasks being asked of me by a factor of N (where N equaled their number of clients, which was around 10) for very little work (would've paid for itself with one, possibly two, of the six or so tasks they gave to me my first week). I was told not to do it, because those were client-billable hours when being done per client, and not when theybwere being done to help all clients. I stayed their a very small number of days after hearing that. Point is, there are businesses that value operations work more than engineering, and that they should not.

It's really a shame that "SRE" came to mean entry level server janitor at so many companies when it strikes me as a very senior role.

by pram 10y ago

It's really a shame that "SRE" came to mean entry level server janitor at so many companies when it strikes me as a very senior role.

brian-armstrong 10y ago

Isn't there always a fundamental tension like this between people who build and people who maintain?

donut 10y ago
This essay talks about the difference between thinkers, doers and janitors. http://multithreaded.stitchfix.com/blog/2016/03/16/engineers-shouldnt-write-etl/ http://multithreaded.stitchfix.com/blog/2016/03/16/engineers... In it the difference is erased and people are reorganized in a, I think, more productive way.
jimbokun 10y ago
As a person who builds, I am awfully grateful for the people who maintain, as my stuff would never work without them.
- brian-armstrong 10y ago
  I think devs should be responsible for maintaining what they build. You get your incentives aligned better that way, and it removes the tension.
  - packetslave 10y ago
    This is actually covered pretty well (imho) in Chapter 32. Many services start out wholly supported by their developers, and are only onboarded to SRE after they reach a certain level of maturity (and/or criticality to the business) Even after SRE takes over operations of a service, developers remain closely involved, and in many cases have their own pager rotation for "something's really broken, SRE has stopped the user-visible bleeding, but we need a code owner to jump in and help solve the root issue."
  - jimbokun 10y ago
    Well, I haven't read the book yet, but the commentary seems to suggest the SRE's role is more to teach the devs how to make their software maintainable, scalable and reliable, and then verify it really meets all of those traits. As a developer, that is a service I greatly value, and greatly respect those who have that knowledge and experience.
user5994461 10y ago
Never understood why that should be separate people. Actually, dont understand how it could be separate people either.
- sh_tinh_hair 10y ago
  That's a relatively new concept. Traditional developers didn't understand much about systems design for scalability, redundancy and much less about operational discipline and systems change management (and in my experience many developers still don't).

jmspring 10y ago

I don't know if it has changed, but one thing I enjoyed about living in Finland in the early 2000s was that a janitor and a director at a company were given the same respect. If was more about contributing to the society. Your comment on SRE -> server janitor is interesting. Especially in the land of DevOps. Companies are looking for ways out, to have people do multiple things and not necessarily acknowledge complexity, experience when things go sideways, etc. Being able to get things to run smoothly, having the background to know when X happens and where to look, being able to plan and intelligently navigate future capacity, etc. is incredibly important. The ops roles that used to exist, places like Google keep them, but a lot of companies do not.

_d8fd 10y ago
The only problem with being a server janitor is there being a communication mismatch. I've worked with a sys admin type who was told, before being hired, he'd be a space janitor. He loved the reference, because that's what he wanted to do. If you need a dog crap collector, sell the job as a poop scooper, not a pre-compost collections technician.

dannypgh 10y ago

SREs with the time and ability (and you don't want to hire those who lack the ability) to do so will automate away whatever operations tasks being a "server janitor" entails. Hence the need of management to ensure they have the time, and that bureaucracy doesn't stand in their way. I once had a "software engineering" gig where I found a way to reduce the labor of the tasks being asked of me by a factor of N (where N equaled their number of clients, which was around 10) for very little work (would've paid for itself with one, possibly two, of the six or so tasks they gave to me my first week). I was told not to do it, because those were client-billable hours when being done per client, and not when theybwere being done to help all clients. I stayed their a very small number of days after hearing that. Point is, there are businesses that value operations work more than engineering, and that they should not.