How to Get Help

Getting Help on a Ticket

When working on tickets, collaboration is critical, especially when troubleshooting complex issues, or technical areas of focus that fall outside of your experience level. Asking for help means having a low level of shame, and also shows that you are putting the customer first because you are working towards resolving their problem.

How to Get Help Workflow

If you are stuck on a ticket, the following workflow seeks to help Support Engineers realize and utilize all of the resources available to progress a ticket to resolution. This workflow lists some common resources, you can lean on to get the help you need.

If you’re stuck on a ticket…..

Identify what’s causing you to get stuck. Some examples are:

• I don’t have the right knowledge to progress this ticket.
• The customer’s query is out of scope, but they expect us to resolve this.
• There is a deep technical issue which needs a development expert’s consult.

Then consider these options to help unblock you. And remember that escalating to unblock is an operating principle of Results.

Ask in your SGG

Ask in your group’s Slack channel for help. You might get all the help you need in responses right there, or you might open up the group’s Zoom room for an impromptu pairing session to work on the ticket. And remember:

1. Be sure to provide a link to the ticket
2. Be specific about the help you need
   • For example: “Kubernetes Runner help needed: user is running into X error, logs are saying Y, and we’ve tried Z. What else could it be?”

Bring the ticket before a group of peers

Other Support Engineers are a great resource to help out with tickets. To get help from peers, you can try one or more of the following:

1. Attend crush or help sessions such as those noted below (see the GitLab Support calendar for times):
   • AMER Senior SE Help Sessions
   • APAC/AMER or EMEA/AMER crush sessions
   • APAC or EMEA crush / collaboration sessions
   • Senior Support Office Hours (varying times)
2. Ask for help in one of the broader Support Slack channels.
3. Initiate a Branch Out session
   • This is like a crush session, with the specific intention of helping 1 or 2 groups with FRTs

Expand to Support Pods and other subject matter experts

You can also do one or more of the following:

1. See if there is a Support Pod that covers the area your ticket is in and ask one of the Pod members for help.
2. Ask an expert within Support. You can check the Skills by Subject Support page to see who might have the skills to assist, or reach out to the Support Stable Counterpart for the appropriate product area. Mention those people in the thread and in the ticket to let them know you think they can help.
3. Request help from the relevant GitLab Development Team. Gather what information you have and fill in as much detail as possible for the dev team in the issue. To get more attention, you can post in the relevant group Slack channel with a message and link to the issue. If you don’t get a response within the SLO, contact the listed engineering manager in the project readme. See below for more details. If you have a reproducible issue, then go straight to a bug issue in the appropriate GitLab product tracker.

Bring the ticket to managers

Especially if you feel you’re stalled on a ticket and need assistance identifying next steps:

1. Always feel free to reach out to any available manager (such as your manager, or the Support Manager On-call) in the #spt_managers channel. They will help you to determine next steps.
   • Avoid messages with no identified DRI for responding in #spt_managers as they can be missed or be a victim to the bystander effect.
2. Open a STAR in situations where getting help is urgent and important because:
   • the customer has expressed unhappiness with the service we’re delivering via the ticket
   • the support engineer has noticed a correlation between several of a customers tickets that could use a more cohesive response
   • there is an urgent need for action in a different region (for example, finding a ticket owner or scheduling a call)

How to Use GitLab.com to Formally Request Help from the GitLab Development Team

Starting from 2022-06-13 the Support Team and the Development Team are rolling out a series of projects that will enable support engineers to request help from a GitLab Development group, for more information on this please review the associated proposal. The aim is to provide a formal and accountable workflow process for Support Engineers to request assistance from the various Development Sections for any technical issues which they are currently unable to progress. Please note that this is an iterative process, which aims to roll out the process for each of the 10 development sections at GitLab. If the Development Section that you require assistance from is not listed in the table below then please continue to use the existing methods for contacting the relevant Development Teams, such as Slack.

How to find the correct Development Section and Group to reach out for help

The easiest way to determine the correct place for a Support Request for Help issue is to use the docs pages. One possible workflow is as follows:

1. Locate a documentation page for the feature or topic on which you need help.
2. Scroll down to the bottom of the page and click on either the “Edit this page” link.
3. This will open up the .md source file of that docs page, which contains both the stage and group responsible for it noted on the top.
4. Now go to the Product Categories handbook page and search for the Development Section to which the group identified on the previous step belongs to.
5. Use the table and workflow below to create a Request for Help issue in the project identified above.

Alternatively, if you have set up the Support dotfiles, you can use the gls_request_for_help command to quickly retrieve the “New issue” link with the correct issue template.

NOTE: A video recording of a similar workflow as the one described above can be found in the Support Training repository

List of Development Sections and corresponding links to the Projects for requesting help

Note: Some sections are not yet available. If a section is not listed, consider a confidential issue in the Gitlab project tracker and post in the relevant Slack channel. Please follow support epic #222 for more information.

Please note: GitLab Dedicated is the first iteration for implementing a Request For Help Section for the SaaS section of GitLab development, therefore at the moment the GitLab project structure and workflows may not be consistent with the other development sections in the above table. You can find out more information on GitLab Dedicated internal processes by visiting the Dedicated Team’s ReadMe.

Opening a request for help

1. Review the above table and click the link to open the corresponding GitLab.com Development Section Project that you require help from.
2. Within each GitLab Project there is a ReadMe (displayed on the project page):
   1. Read the Support Engineer User Guidance section and follow the steps outlined.
   2. Read the Development groups and their corresponding templates section and use the Handbook links provided if you are unsure as to which Section Sub Group and corresponding template you should use.
3. Before submitting a new issue search the existing issues to check if a similar request has been made before.
4. If not, then submit a new issue to the project using the template you’ve identified.
   • If the issue is not automatically assigned to the relevant developers for triaging, review the template for instructions on who to assign to.
5. Assign the correct severity label as outlined in the corresponding ‘Project ReadMe.’ Additionally, if necessary, advocate for the customer by including a ‘Customer Impact’ statement in the issue.

Tips on getting timely responses

1. Review the Opening a request for help to ensure all steps were covered.
2. If an issue is moved to another group (through a label change or moving to another project), check the corresponding template for the new group to see who to assign or mention in a comment.
3. When linking to Kibana, also upload a copy of relevant entries, a screenshot of the graph, etc. as logs rotate out after 7 days. If possible, also link to the relevant Sentry entry.

Escalate to unblock a request

If you encounter any problems, such as obtaining a timely response from Development, then please take the following steps:

1. Review the contacts listed in the issue template and check slack or their GitLab status to see if they are on PTO. If they are on PTO, check slack for their backup and ping them via the issue, otherwise ping the primary contact requesting an update via the issue.
2. Feel empowered to ping the corresponding Development Subgroup slack channel along with a link to the issue, requesting an update.
3. Make the corresponding Development Subgroup Engineering Manager aware via the issue. You can identify the relevant Engineering Manager by checking the Development Group Handbook Page from each Projects ReadMe Section which provides a section named Development Groups with their corresponding templates and labels.
4. Consider reaching out to a Support Engineering Manager for further guidance.

Prior to closing a request for help

1. Lastly, prior to closing the issue please review the information within to determine if any of it can be used to update the GitLab documentation, if any of the information is a candidate to be considered for updating the GitLab documentation then add the label documentation::candidate so that the issue can be identifiable for future use. If you have actually updated the GitLab documentation then please add a link to the MR to the issue and add the label documentation::created.

Quick Links and Resources

• Needs Collaboration view in ZenDesk.
• Create a Support pairing session issue.
• Support Workflows to follow relevant troubleshooting workflow.
• Support Documentation links for quick references to helpful GitLab documentation.
• Skills by Subject to find a Support Engineer scoped to the skill set needed for help.
• DevOps Stages to find the right development or product team to reach out to.
• Emergency runbooks with troubleshooting tips, even if not an emergency.
• See which manager is on-call if guidance is needed on something urgent.

General Troubleshooting Resources

Every problem is a little bit different. Sometimes it makes sense to try a different troubleshooting technique. These resources talk about general purpose approaches to troubleshooting:

• Julia Evans’ comics, especially the ones about debugging
• The Pocket Guide to Debugging (PDF)
• General Purpose Troubleshooting Principles