Note
We use Pagerslack as the primary combined with a spreadsheet(internal only) as a backup for weekday escalations. Weekend escalations rely on the spreadsheet solely.
This page outlines the development team on-call process and guidelines for developing the rotation schedule for handling infrastructure incident escalations.
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 emergencies raised by the Infrastructure , Security, and Support teams.master branch failing.security and the @gitlab-com/security/appsec team mentioned to be notified as part of the Application Security Triage rotationinfradev which will be raised to Infra/Dev triage boardmaster pipelines are broken.NOTE: On-call engineer do not need to announce the beginning and end of their shift in #dev-escalation unless there is an active incident happening (check the chat history of the channel to know if there is an active incident). This is because many engineers have very noisy notifications enabled for that channel, and such announcements are essentially false positives which make them check the channel unnecessarily.
Weekdays will now leverage an automated system relying upon the Pagerslack.
/devoncall incident-issue-url into #dev-escalationIn the event that no BE engineers respond to the bot, Pagerslack will then notify the Engineering Managers. They will need to find someone available and notify this in the escalation thread. As an EM:
Weekend/Holiday oncall will continue to use the oncall spreadsheet (internal only) outlined above.
Holidays will be included in the oncall spreadsheet, those holidays include: Family & Friends days, Christmas Day, New Year's Eve, New Year's Day, and any major holidays that affect multiple timezones.
There are restrictions of eligibility in certain localities, which can be found in the weekend column of the Development-Team-BE spreadsheet (internal only). This spreadsheet is refreshed by the end of each month automactically via the Employment Automation.
/devoncall incident-issue-url into #dev-escalationNOTE: these people generally do not carry pagers and are only likely available during business times. Please respect the individual intake processes, this helps each team track their work.
Use the product sections handbook page to determine whom to contact.
OPERATIONAL EMERGENCY ISSUES ONLY
Important: Sign-ups of weekends/holidays are required as a backup while using Pagerslack as the primary escalation tool.
On-call work comes in four-hour blocks, aligned to UTC:
One engineer must be on-call at all times on weekends and company holidays. This means that each year, we must allocate 756 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 January 2021 we have around 157 eligible engineers, this means each engineer is expected to do 8 shifts per year, or 2 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:
Scheduling and claiming specific shifts is done on the oncall spreadsheet.
The on-call spreadsheet(internal only) can be found by searching Google Drive for Infra/Dev Escalation On-Call Schedule.
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)
The eligibility is maintained in this team members list(internal only) and the spreadsheet is refreshed automatically by our automation script.
Engineers should claim shifts themselves on the oncall spreadsheet. 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 (internal only), GitLab display name, and phone number with country code. This same instruction is posted on the header of schedule spreadsheet too.
At the middle of each month, engineering managers look at the schedule for the following month (e.g. on the 15st 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"(internal only) under a sub-folder called Development Escalation Process in the shared Engineering folder on Google Drive.
These summary items should be in written format in the following locations:
This shall be completed at the end of shifts to hand over smoothly.
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 will:
On-call schedule shifts calendar
and if any developer added their email into the spreadsheet, they will be added as guests in the on-call calendar event. Ensure that you have subscribed to the calendar before syncing.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.
Refer to this coordinator issue template for instructions or the steps below. The same template is used for monthly oncall planning and execution issues.
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.
If you prefer to work on a preferred weekend day please proactively sign up for shifts to avoid auto-assignment. Team members who have signed up for the fewest shifts are auto-assigned open shifts first.
See the oncall spreadsheet(internal only). In the future, we could embed a summary of the upcoming week here.
When responding to an Incident, utilize the below procedure as guidelines to follow to assist both yourself and the members requesting your assistance
:eyes: reaction - this signals to the bot that you are looking into the problem#incident-management Slack Channel#incident-<ISSUE NUMBER>/devoncall incident-issue-url to trigger the escalation process.top to show the top 25 members that are next in the escalation queueposition to see your position in the queue. The higher the number, the less probabilities to get pinged.Please report any problems by creating an issue in the pagerslack project.
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. There is a nice blog post about the shadowing experience.
Situation Room recordings from previous incidents are available in internal Google Drive folder.
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.
To make the First Responder process effective, the engineer on-call must configure their notifications to give them the best chance of noticing and responding to an incident.
These are the recommended settings. Your mileage may vary.
