4 ms·
It's possible to tolerate on-call if: You have the ability to make changes necessary at the infrastructure engineering stage, not at the ops ad-hoc response st
by mancerayder 4y ago
It's possible to tolerate on-call if:
You have the ability to make changes necessary at the infrastructure engineering stage, not at the ops ad-hoc response stage, to prevent or end problems that cause call-outs.
There are those that that view "DevOps" not as an engineering culture but as "people who fix problems in production" and even "do releases Friday at 10pm" and developers (or "engineers") as "people who make changes, and go to the bar Friday at 6pm." Companies that do this sometimes call themselves places that "move quickly, break often." Places like this, you hope never to work for.
- probablypower 4y agoYou are probably making a good point here, but you're doing so in such a roundabout way that it isn't clear what your point actually is. In the given context, how would you describe a company you would hope to work for?
- mancerayder 4y agoMy point is that on-call is OK if the people that are on-call are empowered to either fully prevent, or permanently fix, conditions that lead to on-call events. I'm talking about software development and infrastructure design, which I thought is the topic here. I've done this for many years. The worst case scenario is that the people that are getting woken up at night don't have any control over the root causes of the wake-ups. If you own and created the environment, and it wakes you up at night, that's one thing. If you're just on-call and responsible for other people's messes, that sucks. Hopefully that's more clear!