Hacker News Reader

Comment by andreygrehov | Hacker News Reader

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.

View on HN

> 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

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

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".

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.

> 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.

> 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.

Usually the term used is "discretion" I believe.

Reply on news.ycombinator.com