| I started being on-call a few months ago. For us it works like this: - 1 week in 4 Monday 00:00 to Sunday 23:59, with a fixed pay adjustment (same fixed amount added to our salary every month, not a % increment). - If you get a call, you're on the clock and get paid regular over-time rate. Theoretically this only applies if you get called and are doing something for more than 30 minutes though. - I know most of the on-call managers personally so don't mind picking up the phone for a quick opinion for free, if it's at a reasonable time. - Online within an hour once we've picked up the phone. - Senior on-call manager gets woken up by Ops first and then will decide which parts of the system are affected. After going through known issues and work arounds will then work out which part of the system needs to be looked at and makes the call to the on-call developer that is appropriate (ie. which team). - Duty is primarily to diagnose and provide knowledge to the on-call manager to make a decision so service can come back up again. - Don't do code fixes (J2EE on my team, mix of Java and C++ on others) - we have far too much to go wrong for hacking around like that, but may do config changes and some scripting. The line can get a bit blurred. - In our team we should raise a ticket/Jira for every time we get a call so that it's visible to everyone what happened and see where our pain points are. - During office hours, Production issues are distributed in the team in the same way as bugs, according to domain knowledge and individual capacity. - We tend not to get called out except for when we do installation in to Production. We have a fairly heavy weight process for releases - which we are working on. - I am at least 4 levels of communication away from any customers, including 1st and 2nd line teams. Edit: formatting |