3 ms·

I'm somewhat perturbed that the entirety of the "DevOps" section is advice to get an SRE on your team because an SRE's job is to "be online after hours". That'

I'm somewhat perturbed that the entirety of the "DevOps" section is advice to get an SRE on your team because an SRE's job is to "be online after hours". That's an incredibly dismissive and reductive perspective on the expertise and insight that an SRE (or any ops staff) could bring to a project, and it sounds like this person--or maybe their entire team--is doing a really bad job of owning their own junk. I'll make a note to be extra wary of looking into any SRE jobs at Amazon if this is how they treat those positions.

kakwa_ 7y ago
This is indeed an incredibly dismissive view, only seeing the SRE as the poor soul you offload responsibility of things running well in production, despite the fact he is likely to have far less insight on what might go wrong and means to fix things. Being basically in this position (but in a large follow-the-sun team, so I'm fortunate enough to not be paged at night), I can only underline the deep frustration such views can generate. Being paged every 10 minutes, being asked to fix things you have no control over, getting answers like "what? the server is overloaded? it's an infrastructure issue, not a bug in our code" and seeing developers cry when they get a ticket a day, when at the same time each SREs in the team is receiving a dozen, it can lead to some resentment. A saner approach is to have the SRE as the first line to filter bugs/alerts/tickets out, but being able to call a developer if required. The SRE can also be an active team member with more insight on production constrains and pain points and maybe system architecture recommendations for the whole team. Also, in my opinion, developers should be an active part of running things in production, otherwise the whole dev team can lose touch with reality and lose sight on how well or not things are actually running.

kakwa_ 7y ago

This is indeed an incredibly dismissive view, only seeing the SRE as the poor soul you offload responsibility of things running well in production, despite the fact he is likely to have far less insight on what might go wrong and means to fix things. Being basically in this position (but in a large follow-the-sun team, so I'm fortunate enough to not be paged at night), I can only underline the deep frustration such views can generate. Being paged every 10 minutes, being asked to fix things you have no control over, getting answers like "what? the server is overloaded? it's an infrastructure issue, not a bug in our code" and seeing developers cry when they get a ticket a day, when at the same time each SREs in the team is receiving a dozen, it can lead to some resentment. A saner approach is to have the SRE as the first line to filter bugs/alerts/tickets out, but being able to call a developer if required. The SRE can also be an active team member with more insight on production constrains and pain points and maybe system architecture recommendations for the whole team. Also, in my opinion, developers should be an active part of running things in production, otherwise the whole dev team can lose touch with reality and lose sight on how well or not things are actually running.