This page outlines the development team on-call process and guidelines for developing the rotation schedule for handling infrastructure incident escalations.
Due to the impacts and uncertainties caused by the COVID-19 outbreak, to maximize flexibility for all team members while providing complete business coverage, below are temporary measurements to mitigate risks of the dev on-call coverage.
column Gof the spreadsheet via Slack direct message and adding a
Commentto the cell of open slot by explictly tagging the coordinators and assigning to one of the coordinators.
The expectation for the development engineers is to be a technical consultant and collaborate with the teams who requested on-call escalation to troubleshoot together. There is no expectation that the development engineer is solely responsible for a resolution of the escalation.
operational emergenciesraised by the Infrastructure , Security, and Support teams.
@gitlab-com/security/appsecteam mentioned to be notified as part of the Application Security Triage rotation
infradevwhich will be raised to Infra/Dev triage board
Example of qualified issue:
Examples of non-qualified issues:
On-call work comes in four-hour blocks, aligned to UTC:
One engineer must be on-call at all times. This means that each year, we must allocate 2,190 4-hour shifts.
The total number of shifts is divided among the eligible engineers. This is the minimum number of shifts any one engineer is expected to do. As of March 2020 we have around 150 eligible engineers, this means each engineer is expected to do 16 shifts per year, or 4 shifts per quarter.
In general, engineers are free to choose which shifts they take across the year. They are free to choose shifts that are convenient for them, and to arange shifts in blocks if they prefer. A few conditions apply:
Most on-call shifts will take place within an engineer's normal working hours.
Scheduling and claiming specific shifts is done on the Google sheet of schedule. More on that below.
All development backend and fullstack engineers who have been with the company for at least 3 months.
Exceptions: (i.e. exempted from on-call duty)
Engineers normally claim shifts themselves on this Google sheet of schedule. To ensure we get 100% coverage, the schedule is fixed one month in advance. Engineers claim shifts between two and three months in advance. When signing up, fill the cell with your full name as it appears in the team members list, Slack display name, and phone number with country code. This same instruction is posted on the header of schedule spreadsheet too.
At the start of each month, engineering managers look at the schedule for the following month (e.g. on the 1st March, they would be considering the schedule for April, and engineers are claiming slots in May). If any gaps or uncovered shifts are identified, the EMs will assign those shifts to engineers. The assignment should take into account:
In general, engineers who aren't signing up to cover on-call shifts will be the ones who end up being assigned shifts that nobody else wants to cover, so it's best to sign up for shifts early!
There is additional information regarding weekend shifts, which can be found in "Additional Notes for Weekend Shifts" under a sub-folder called Development Escalation Process in the shared Engineering folder on Google Drive.
Given the complexity of administration overhead, one engineering director or manager will be responsible to coordinate the scheduling of one month. The nomination follows the same approach where self-nomination is the way to go. On each month tab in the schedule spreadsheet, directors and managers are encouraged to sign up in the Coordinator column. One director or manager per month.
The coordinator should:
An Epic of execution tracking was created, where each coordinator is expected to register an issue under this Epic for the month-on-duty to capture activities and send notifications. Here is an example.
For those eligible engineers, everyone is encouraged to explore options that work best for their personal situations in lieu of weekend shifts. When on-call you have the following possibilities:
With the above alternatives we want to make sure we comply with local labor laws and not surpass the restricted weekly working hours (ranging from 38 to 60 hours) and offer enough rest time for the engineers who sign up on weekend on-call shifts.
See the Google sheet of schedule. In the future, we could embed a summary of the upcoming week here.
Below is a process that one coordinator used to fill unclaimed spots:
Feel free to participate in any incident triaging call if you would like to have a few rehearsals of how it usually works. Simply watch out for active incidents in #incident-management and join the Situation Room Zoom call (link can be found in the channel) for synchronous troubleshooting.
Situation Room recordings from previous incidents are available in this Google Drive folder (internal).
To get an idea of what's expected of an on-call engineer and how often incidents occur it can be helpful to shadow another shift. To do this simply identify a time-slot that you'd like to shadow in the on-call schedule and contact the primary to let them know you'll be shadowing. Ask them to invite you to the calendar event for this slot. During the shift keep an eye on #dev-escalation for incidents and observe how the primary follows the process if any arise.