The Support Manager On-call helps coordinate responses to urgent and important situations that arise within the scope of delivering a quality experience to GitLab customers.
The Support Manager On-call is one of the rotations that make up GitLab Support On-call.
As part of GitLab Support on-call, Support Managers serve in a rotation. The support manager on-call is responsible generally for:
Needs Org / FRTview. Ping your region in
#support_team-chatif tickets are building up to remind people to take new tickets. See Meeting our FRT SLA for details of how we meet our FRT SLA.
The Support Engineer on-call is the first responder for customer emergencies. Managers support this work as follows:
Support Escalations are handled by the Support Manager on-call.
Your responsibilities are as follows:
You can use Support Team Skills by Subject to find appropriate engineers to assign.
NOTE: GitLab team members may attempt to draw attention to tickets in regular support Slack channels (
#spt_managers). Any such attempt constitutes an escalation. Redirect the team member by responding to their post with only the
:escalate: emoji, which will send an automated and anonymous reply describing the correct process.
NOTE: There are two other distinct situations, not discussed on this page:
Some steps of escalation management are handled by bots and auto-responders. The text
**BOT** is used below to show these steps.
#support_escalations, with an
@mentionof the current on-call Support Manager's name.
:eyes:emoji to acknowledge you are looking at the escalation.
#support_licensing-subscription. Then return to the thread in
#support_escalationsand comment that all technical ticket-related discussion is happening in the ticket (or in the new thread). This helps ensure all technical discussion stays in one channel/thread.
There are times when an escalation request does not meet the threshold for escalation. In such situations, return to the thread in
#support_escalations and notify the escalation initiator.
An escalation is considered resolved when the correct next-step is identified and underway; it does not require the Zendesk ticket to be Solved or Closed.
When an escalation is resolved:
:green-check-mark:emoji to the escalation notification in
~Escalation::License-Issue: Identifies the core issue at hand resolves around licensing / subscriptions
~Escalation::Response-Time: Useful when the purpose of the escalation is to expedite a response to an issue or case
When GitLab experiences a security incident, the Support Manager on-call is responsible for triaging and responding to customer communications stemming from the security incident. This may include involving the CMOC.
If you will be unable to handle on-call for a few hours on a weekday due to being engaged in a customer call or otherwise, arrange for another manager to handle on-call responsibilities temporarily:
#spt_managersfor any manager to volunteer to cover.
To swap your on-call duty with someone, follow the steps listed under Swapping on-call duty.
At times, you may receive an escalation where the customer is reporting a situation that qualifies for emergency support under our definitions of support impact. In such cases you may elect to trigger an emergency directly, rather than asking the customer to open a new emergency ticket.
You can trigger a PagerDuty notification by using the
Support::Managers::Trigger manual emergency macro in Zendesk.
Alternatively, you can manually trigger a PagerDuty notification through PagerDuty itself.
Login to gitlab.pagerduty.com and select + New Incident from the upper right corner. Then fill out the form as follows:
No other fields need to be filled out, therefore you may then click Create Incident