Note: This page is meant to go with the GitLab Learn version. The original version is in the support-training repository.
This training module provides Support Engineers with the basics of answering GitLab.com (SaaS) product related tickets, for both new and existing Support team members who are looking to start working on SaaS tickets.
Goals
At the end of this module, you should be able to:
General Timeline and Expectations
Consider using the Time Tracking functionality so that the estimated length for the module can be refined.
-Done with Stage 1
username-auditor
and username+auditor@gitlab.com
, confirm it via email, and then enable 2FA on it. Example access request.
awesome_user7
awesomeuser@gitlab.com
awesome_user7-auditor
awesomeuser+auditor@gitlab.com
Regardless of whether you receive admin access later, you should set up chatops access.
gitlab-com/support
? ID:Note: Stage 2 and 3 are reversible. For those who want a more "structured" introduction to procedural tickets, start here. If you're already familiar with GitLab and are used to troubleshooting Self-managed, consider doing Stage 3 first.
See also Stage 4 for a place to record pairing sessions.
Keep in mind that only GitLab team members are admins, and that accounts are bound by our Terms of Use as covered in the overview.
Bottom Line: Never share information that a user would not have access to even if it's about another user within their organization. You can still suggest possible solutions based on the description of the problem (and even what you find out about the account), but definitive information cannot be shared.
Many common tickets are triaged to other places.
One of the main differences of working with GitLab.com is that we receive many requests from free users because we are the administrators of GitLab.com. One of the most common cases is not receiving confirmation, password, or other system notifications from GitLab.
Remember: When triaging tickets and you're unsure if a user is asking about a Self-managed instance or GitLab.com, use chatops to check if the user exists. The API searches for primary email and secondary emails starting 13.7 as described in this issue.
Keep in mind:
administration
section.Simplified component overview
section.
gitlab.rb
), and secrets (which only infra has access to).rails
and sidekiq
logs. HAproxy
and CloudFlare logs are only available to infra team. Ask in the #production Slack channel if necessary.correlation_id
. You may not find anything and the search is not reliable, but take a screenshot of your search and results and add it as a comment to this issue anyway.The best way to troubleshoot as always is to try to reproduce it.
gitlab-gold
, gitlab-silver
, and gitlab-bronze
.
Because GitLab is the steward of GitLab.com, we sometimes need to troubleshoot some of our integrations. We have workflows for some cases. You don't need to read these in detail now, but keep in mind that these are available:
rails
log.Security's focus is instance wide security breaches and vulnerabilities. They do however take care of other account related cases (covered in previous stage).
Keeping up to date and asking questions:
If you are doing this module as part of onboarding, feel free to remove the pairing section.
Have 5 pairing sessions specifically geared towards answering GitLab.com tickets or issues.
If you are doing Stage 5 (admin access), do 2 more focusing on tickets or issues that require admin access.
Aside from the ones covered in Stage 2, the most common user requests have to do with disabling 2FA and name squatting. However, most of these workflows apply in other cases as well.
Depending on your prior experience and readiness, open the module listed below. Your manager may decide to have you pick this up later once you have more familiarity with GitLab.
Please also submit MRs for any improvements that you can think of! The file is located in an issue template in the 'support-training` repository.