3 ms·

Not necessarily. If their software is barely used on the weekends, then shipping on Friday has a smaller blast radius in the event of a downtime / bad deploymen

Not necessarily. If their software is barely used on the weekends, then shipping on Friday has a smaller blast radius in the event of a downtime / bad deployment, eg fewer customers are impacted. However, there is a chance their work-life-balance metrics are not great, since the engineers have to deal with the incidents during the weekend. Btw, 102 incidents within a week. Whoa! That's a lot. Wouldn't want to work there. To put it into perspective, here at AWS my team has about 3 incidents within a week.

infinityio 4y ago
> Btw, 102 incidents within a week. Whoa! That's a lot. Wouldn't want to work there. I might be wrong but I'm pretty sure that's every incident they've ever documented, grouped by day, as opposed to the data from last week Their status page seems to suggest ~99.97% uptime (about 3h/year down) recently
- andreygrehov 4y ago
  You are right. The title of the image says "Total incidence counts across all time, grouped by day".
owl57 4y ago
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 right to do (or not do) this "the on-call engineer's right".
- 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.

infinityio 4y ago

> Btw, 102 incidents within a week. Whoa! That's a lot. Wouldn't want to work there. I might be wrong but I'm pretty sure that's every incident they've ever documented, grouped by day, as opposed to the data from last week Their status page seems to suggest ~99.97% uptime (about 3h/year down) recently

andreygrehov 4y ago
You are right. The title of the image says "Total incidence counts across all time, grouped by day".

owl57 4y ago

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 right to do (or not do) this "the on-call engineer's right".

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.