Geo and Disaster Recovery
The Geo Team
Geo is a Premium feature, built to help speed up the development of distributed teams by providing one or more read-only mirrors of a primary GitLab instance. This mirror (a Geo secondary node) reduces the time to clone or fetch large repositories and projects, or can be part of a Disaster Recovery solution.
Team members
Stable counterparts
Goals and Priorities
Our priorities are aligned with the product direction. You can read more about this on the Geo Product Vision page.
Alongside the items listed in our Product Vision, we need to constantly assess issues that our customers bring to our attention. These could take the form of bug reports or feature requests. Geo users are often our largest customers and some rely on Geo as a critical part of their workflow.
We also work constantly to keep housekeeping chores to a manageable level. Where possible, we address these issues as part of a related project. Where this is not possible, we use time around our projects to make this happen.
Objectives and Key Results (OKRs)
Every quarter the engineering team sets objectives and key results. OKRs are managed in GitLab as of FY24-Q1. The following are links to issues lists for Geo’s OKRs.
Geo’s Relationship to Disaster Recovery
Disaster Recovery (DR) is a set of policies, tools and procedures put in place to be able to recover from a disaster.
Geo provides data redundancy. The customer will have a redundant copy of data in a separate location. If anything were to happen to their primary instance, a secondary instance still retains a copy of the data.
However, data redundancy is only one part of a complete DR strategy.
High Availability (HA) is also a step towards Disaster Recovery. At the moment Geo does not provide true HA because if the primary instance is not available, certain actions are not possible.
How to ask for support from Geo
The first line of support will always be the support engineer assigned to the issue raised by the customer. However, at times more expertise is required to resolve the customer concern and a Geo engineer needs to be involved. This section outlines the process and expectations when requesting support from the team for Geo-related customer support issues.
Before requesting support
Before submitting a request for support, please review Geo’s documentation, the Disaster Recovery docs, the Backup and Restore docs, the Geo Handbook pages, or search through previous customer issues in the Geo Customers Project. The answer to your questions might be found there. Please reach out in the Geo Support Pod Channel #spd_pod_geo
first before submitting a RFH.
Asking a general question
If you have a general question for which you can’t find your answer, then feel free to ask your question in the #g_geo channel on Slack. Please keep in mind that engineers will do their best to support you and answer your question from the top of their heads. If they need to do more research and/or address more complicated scenarios, you will need to create a support issue (see next section).
Create a support request issue
We like to use issues when customers need help from the Geo Team. This helps us to prioritize work and make sure that we don’t lose history and maintain context when the Slack retention policy activates. We ask requestors to create an issue in the Geo Customers Project.
Please make sure to use and fill the Geo support request issue template for Geo related questions and Backup and Restore support request issue template. As the requestor you only need to fill the Customer Info and Support Question sections.
Other than the Collaboration template, RFHs must be opened by Support Engineers once a support ticket has been opened.
At minimum Zendesk links and logs are especially important. The issue will not enter our normal triage process if they are missing. If no update has been made on an issue for 2 weeks, they will be auto closed by the EM/PM/Assignee.
We also have a process for triaging RFH issues, please see process
If you like, you may assign a priority label to your request. A geo team member or the PM will review this priority assignment during the triage of the issue. Please use the table below as a reference of priority levels and expected response times.
Priority | Typically used for | Expected first response time |
---|---|---|
P4 | General questions that can’t be answered on slack by Geo engineers of the top of their heads and will require a bit more investigation. | 2-3 days |
P3 | Customer problems that are not time sensitive (i.e. they have an easy work around) or scheduling time to engage with the customer in the future for them to achieve their goals. | 1 day |
P2 | Customer problems that are somewhat time sensitive and are blocking decisions or progress to be made on the customer side. | 1/2 day |
P1 | Fires and emergencies that the customer is experiencing | 1-2 hours |
* Response times are based on weekdays (excluding holidays) within regular business hours in the time zones that team members are located.
* Outages and other urgent matters should be channeled through GitLab’s incident management processes.
Common Links
Documentation
Issue Lists
Missing type labels
The following links lead to Geo team lists of issues to help with identifying missing subtype labels. After opening each link, select the desired milestone filter.
- Issues missing the type label
- Features issues missing subtype label
- Maintainance issues missing subtype label
- Bug issues missing subtype label
Other Resources
- Issues relating to Geo are mostly to be found on the gitlab-ee issue tracker
- Chat channel; please use the
#g_geo
chat channel for questions that don’t seem appropriate to use the issue tracker for. - Geo YouTube Playlist
- Product Support Requests
- Geo on staging.gitlab.com
Planning and Process
Our planning and build process is recorded on the process page.
Demos
The demos are recorded and should be stored in Google Drive under “GitLab Recorded Videos –> Geo Demos”. If you recorded the demo, please make sure the recording ends up in that folder.
Geo Terminology
See the Geo Glossary.
Dashboards
Geo and Disaster Recovery - Planning
Geo and Disaster Recovery - Retrospectives
Geo on staging.gitlab.com
Geo scheduled pipelines
6f6d0996
)