CSM Infrastructure Upgrade Coordination

Overview

Customers on self-managed GitLab deployments may need to upgrade to new infrastructure for a number of reasons, including moving to a cloud provider, utilizing technologies such as Kubernetes, or because GitLab growth requires more computational resources. GitLab provides recommended Reference Architectures for different scales.

CSMs are the primary point of contact for customers and are responsible for coordinating with the customer and internal teams so that an infrastructure upgrade plan can be established. CSMs may provide documentation and high-level guidance but the technical implementation should ideally be provided by Professional Services via Dedicated Implementation Services.

Infrastructure upgrade coordination

This is a high-level process for CSMs coordinating an infrastructure upgrade:

1. CSM establishes specific customer requirements for the hardware upgrade e.g. what growth a customer anticipates.
2. Recommended: CSM involves Professional Services and recommends using Dedicated Implementation Services to facilitate the migration to new hardware.
   1. NOTE: For large hardware upgrades (5000+ users) it is highly recommended that Professional Services are involved via Dedicated Implementation Services. This ensures that the customer’s hardware upgrade plan is sufficient and that the migration can be performed with minimal interruption. Migrations of this size often take at least three months to plan and execute.
3. Should a customer choose not to procure Professional Services, a CSM can provide relevant documentation e.g. for Reference architectures but won’t provide a detailed hardware upgrade plan.
   1. Other internal teams (Product, Quality, Support, etc.) may assist if specific questions arise.
4. Once a hardware upgrade plan is created, either via Professional Services or by the customer, the CSM shares the plan with Support. The Support team will review the plan for feedback..
5. During a non-ProServ assisted migration, if the customer encounters problems during the migration itself, then Support will be the primary point of contact via our support process.

Architecture review

When a customer is planning an infrastructure upgrade, they may want to review their proposed architecture with their CSM. Likewise, the CSM should be asking the customer for an architecture diagram and ensuring that they are following one of our reference architectures.

Deviating from reference architecture

If a customer’s proposed architecture deviates from the reference architecture for their intended scale, there is a defined process to ensure the best result for the customer. This involves a review between the CSM and the customer, and a final validation from Support.

1. Ensure that the customer knows about, and has reviewed, the reference architecture appropriate for their user count and/or scalability requirements.
2. Discuss with the customer how they could revise their architecture to match the reference.
3. If the customer asserts that they cannot, or will not, follow the reference, find out why that is. There may be valid, unavoidable reasons such as company policy or budget limitations.
   1. Clarify for the customer that their performance and subsequent support may be affected, so that you are adequately managing expectations before going any further.
4. Advise them to run the GitLab Performance Tool against their instance, and provide the results to you for review alongside their architecture diagram.
5. Provide them with our benchmark GPT results for comparison, and review their results against the benchmark figures.
   1. If their GPT results are equivalent to, or better than, our benchmark results then they will likely see good performance from their proposed architecture.
   2. If their GPT results are below the benchmark results, they may expect to see underperformance of their architecture compared to the reference architecture for their scale.
6. After gathering all of the above information, reach out to the Support team to ask for them to review the details and advise on their ability to support the proposed architecture, and any recommendations they have for improvement. This review should be conducted by a Senior Support Engineer or higher.
7. Advise the customer that if they choose to deviate from a reference architecture there may still be a point in the future when we have need to ask them to adopt a reference architecture to overcome an issue that did not surface during the review.
8. Document all of this information in a location that is easily accessible to the customer and to GitLab team members, such as in the wiki of the customer collaboration project. Provide this location to the Support team as a follow-up, which they can add to the customer notes for their support process.