Correlation between Emergency Support tickets and GitLab Upgrades
Problem Statement
Upgrading GitLab versions can cause our customers' production instances to go "down" or become unavailable, prompting customers to create emergency Support tickets. In certain situations, recovery from backup ("disaster recovery") may be the only way to get their GitLab instance back up and running.
Hypothesis
A significant portion (25%+) of all self-managed Emergency Support tickets are created as a result of problems that occur after upgrading GitLab.
Gathering Data
How?
- Add
upgrade-related-emergency
tag to emergency tickets submitted for problems with a GitLab version upgrade.🏷 - Calculate % of total emergency tickets related to upgrade problems (upgrade-related-emergency / total emergency tickets)
🎉
Proposal
Analyze emergency tickets created over time to quantify how many were submitted because of technical problems that occurred as a result of a GitLab upgrade gone awry.
IF >25% of emergency tickets can be attributed to a change (upgrade) in GitLab versions THEN Support gets quality, distribution, technical writing, product, and/or UX teams involved in a cross-team OKR.
Goals (KRs?)
- reduce the number of emergency tickets with
upgrade-related-emergency
tag (by 25%) - Support team uses
upgrade-related-emergency
tickets to make MR updates and fixes to documentation on upgrading GitLab (>10 docs MRs) - increase customer adoption of newer major/minor versions (?)
- build self-managed QA tests for GitLab version upgrades across major/minor versions using Omnibus, Docker, and Helm installation methods (?)