Hacker News Reader

Comment by sarchertech | Hacker News Reader

What do you do about on call responsibilities? The smaller the team the more time spent on call per person.

The article had a whole section about that -- they shared the on-call duties across both teams (but required a high-quality playbook for each team's systems).

Which is something that sounds fine but, IMHO, practically speaking it's not really going to work. Most of the time you're going to end up having to page for the systems your team doesn't own for any non-trivial issue.

When your team owns an application you have no background knowledge in, and it uses a technology that you haven't touched since you attended a training 18 months ago; I would assume that your on-call response for any non-trivial issue would still be to page someone for help.

In this case the solution (cross-coverage) worked for that organization. However I agree that more often than not, it won't work.

I didn't have the word-count to go into this (that could be the topic of an entire book... or at least a chapter of The Practice of Cloud System Administration [https://the-cloud-book.com/]).

That said, my personal rule of thumb is: 6 is the minimum for an oncall roster; 5 if there is another team doing follow-the-sun coverage. YMMV of course.

Tom

But the on-call footprint is also smaller. Ideally up to a point where most of the problems don't require immediate response, so most teams won't need a 24/7 on-call.

I think the issue is that first people introduce 24/7 on-call, then they split into teams and this policy no longer makes sense, but noone has the balls to roll it back because it's optics are bad. But you should.

Reply on news.ycombinator.com