4 ms·

I have deployed a risky change on Saturday to limit blast radius, when I was both the original developer and on call that week. In our team, we call the moral r

• andreygrehov 4y ago
  That's perfectly fine. I would even add that there is no need to call it "the on-call engineer's right", because being on-call is precisely for handling scenarios like this. However, one of the goals of each engineering team should be to minimize incidents and improve the work-life-balance of on-call engineers. Team morale goes down if a service requires attention every other night/weekend. Since the on-call process is usually based on rotation, at some point service outage affects everyone.
  • kevincox 4y ago
    > being on-call is precisely for handling scenarios like this If your teammates are deploying risky changes and purposely doing it when you are outside of office hours I think that is quite disrespectful. For most teams oncalls are for emergencies, they aren't paid for full-time work and they likely have better things to do with their time than come in to work to clean up your change. Unless you are coordinating before time I would avoid doing this.
    • owl57 4y ago
      > If your teammates are deploying risky changes and purposely doing it when you are outside of office hours I think that is quite disrespectful. Exactly. But you get to decide how to spend your own weekend. Depends on the exact escalation instructions, of course. Once upon a time I could be reasonably sure that if anything breaks in production and I'm on call, no one else would get called.
• dsego 4y ago
  Usually the term used is "discretion" I believe.