4 ms·

You mean that being on call all the time and responsible for deciphering why someone else’s service broke and fixing it is a draining occupation? Who could have

You mean that being on call all the time and responsible for deciphering why someone else’s service broke and fixing it is a draining occupation? Who could have predicted that? I feel like I’m personally in an awkward position. I’ve fought both for and against SRE-type teams at one point or another. While every company I have ever worked for has had some good developers, they’ve always had awful DevOps that never seemed to know or accomplish anything. I honestly don’t think any of the DevOps mindset works long-term, just like “full stack” developers doesn’t.

futhey 5y ago
As an outsider, I always imagined Google treated their DevOps people with the same disdain they reserve for their customers and contract employees. Seems like a high-pressure / thankless role in most companies, but Google seems to overzealously prioritize uptime. I'm guessing it's not fun to be responsible for site reliability.
- joshuamorton 5y ago
  > As an outsider, I always imagined Google treated their DevOps people with the same disdain they reserve for their customers and contract employees. This seems like an odd conclusion. SRE as a role was pioneered by Google (like they literally wrote the book on it https://sre.google/sre-book/table-of-contents/ https://sre.google/sre-book/table-of-contents/) and they treat it better than most other companies (on-call is compensated and waking hours only, among other things). There are problems with Google's SRE culture, but "thankless" and "like contract employees" are not valid descriptors.