美国公开承认F35C不敌歼20 简直是活靶子(1)-海外视角
There are many ways to contact Support, but the first step for most people should be to search our documentation.
Contact Support
Have questions about billing, purchasing, subscriptions or licenses?
We're here to help! No matter what plan you have purchased, GitLab Support will respond within 8 hours on business days (24x5).
Open a Support Ticket on the GitLab Support Portal and select "Licensing and Renewals Problems".
Can't find what you're looking for?
If you can't find an answer to your question, or you are affected by an outage, then customers who are in a paid tier should start by consulting our statement of support while being mindful of what is outside of the scope of support. Please understand that any support that might be offered beyond the scope defined there is done at the discretion of the agent or engineer and is provided as a courtesy.
Managing your support contacts.
All individuals who will open support tickets must be associated with an organization that holds a valid GitLab subscription. If you are not pre-listed this will result in a rejection message detailing you how to manage your organizations support contacts. Please see our dedicated page on Managing Support Contacts for how to let GitLab Support know who is authorized to contact support.
Find your support level
GitLab Free plan
- GitLab Free plan (GitLab.com or Self-managed) does not include support at any level. Instead, you can open a thread in the GitLab Community Forum. GitLab Community Forum
- If you are facing issues relating to billing, purchasing, subscriptions, or licensing, please open a Support Ticket on the GitLab Support Portal and select "Licensing and Renewals Problems".
GitLab Support Service Levels
Trials Support
Trial licenses do not include support at any level. If part of your evaluation of GitLab includes evaluating support expertise or SLA performance, please consider contacting Sales to discuss options.
Standard Support (Legacy)
Standard Support is included in Legacy GitLab self-managed Starter. It includes 'Next business day support' which means you can expect a reply to your ticket within 24 hours 24x5. (See Support Staffing Hours).
Priority Support
Priority Support is included with all self-managed and GitLab.com Premium and Ultimate purchases. These plans receive Tiered Support response times:
| Support Impact | First Response Time SLA | Hours | How to Submit |
|---|---|---|---|
| Emergency (Your GitLab instance is completely unusable) | 30 minutes | 24x7 | Please engage emergency support. |
| Highly Degraded (Important features unavailable or extremely slow; No acceptable workaround) | 4 hours | 24x5 | Please submit requests through the support web form. |
| Medium Impact | 8 hours | 24x5 | Please submit requests through the support web form. |
| Low Impact | 24 hours | 24x5 | Please submit requests through the support web form. |
Self-managed Premium and Ultimate may also receive:
- Support for Scaled Architecture: A Support Engineer will work with your technical team around any issues encountered after an implementation of a scaled architecture is completed in cooperation with our Customer Success team.
- Upgrade assistance: A Support Engineer will review and provide feedback on your upgrade plan to help ensure there aren't any surprises. Learn how to schedule an upgrade.
How to engage Emergency Support
To engage emergency support you should use the form for the support instance you are working out of:
It is preferable to include any relevant screenshots/logs in the initial ticket submission. However if you already have an open ticket that has since evolved into an emergency, please include the relevant ticket number in the initial email.
- Note: For GitLab.com customers our infrastructure team is on-call 24/7 - please check status.gitlab.com before contacting Support.
Once an emergency has been resolved, GitLab Support will close the emergency ticket. If a follow up is required post emergency, GitLab Support will either continue the conversation via a new regular ticket created on the customer's behalf, or via an existing related ticket. Support Emergencies are defined as "GitLab instance in production is unavailable or completely unusable". The following is non-exhaustive list of situations that are generally considered as emergencies based on that definition, and a list of high priority situations that generally do not qualify as an emergencies according to that definition.
Emergency:
- GitLab instance is "down", unavailable, or completely unresponsive (for GitLab.com outages, an Incident will be declared)
- GitLab always shows 4xx or 5xx errors on every page
- All users in an organization are unable to login to GitLab
- All users in an organization are unable to access their work on GitLab
Non-emergency:
- A single user is unable to login to GitLab.
- GitLab Runner or CI job execution is slower than usual.
- A CI pipeline is failing on one or more projects but not all projects.
- One or more pages are not responding in browser, but most pages load successfully.
- An access token has stopped working or SSH key has expired.
- License/Subscription about to expire.
- GitLab application is usable but running slower than usual.
- Security incident affecting a publicly-accessible and unpatched self-managed GitLab server.
- A Geo secondary is unhealthy or down.
- Elasticsearch integration is not working.
To help Support accurately gauge the severity and urgency of the problem, please provide as many details about how the issue is impacting or disrupting normal business operation when submitting the emergency ticket.
The SLA times listed are the time frames in which you can expect the first response.
Definitions of Support Impact
Severity 4 | Low
Questions or Clarifications around features or documentation or deployments (24 hours) Minimal or no Business Impact. Information, an enhancement, or documentation clarification is requested, but there is no impact on the operation of GitLab. Implementation or production use of GitLab is continuing and work is not impeded. Example: A question about enabling ElasticSearch.
Severity 3 | Normal
Something is preventing normal GitLab operation (8 hours) Some Business Impact. Important GitLab features are unavailable or somewhat slowed, but a workaround is available. GitLab use has a minor loss of operational functionality, regardless of the environment or usage. Example: A known bug impacts the use of GitLab, but a workaround is successfully being used as a temporary solution.
Severity 2 | High
GitLab is Highly Degraded (4 hours) Significant Business Impact. Important GitLab features are unavailable or extremely slowed, with no acceptable workaround. Implementation or production use of GitLab is continuing; however, there is a serious impact on productivity. Example: CI Builds are erroring and not completing successfully, and the software release process is significantly affected.
Severity 1 | Urgent
Your instance of GitLab is unavailable or completely unusable (30 Minutes) A GitLab server or cluster in production is not available, or is otherwise unusable. An emergency ticket can be filed and our On-Call Support Engineer will respond within 30 minutes. Example: GitLab showing 502 errors for all users.
Ticket severity and customer priority
When submitting a ticket to support, you will be asked to select both a severity and a priority. The severity will display definitions aligning with the above section. Priority is lacking any definition - this is because the priority is whatever you and your organization define it as. The customer priority (shorted on the forms as priority) is Support's way of asking the impact or importance the ticket has to your organization and its needs (business, technical, etc.).
Note: The US Government support portal is often setup differently than the Global support portal and might differ in the questions asked via the ticket submission forms.
Service Level Agreements
- GitLab offers 24x5 support (24x7 for Priority Support Emergency tickets) bound by the SLA times listed above.
- The SLA times listed are the time frames in which you can expect the first response.
- GitLab Support will make a best effort to resolve any issues to your satisfaction as quickly as possible. However, the SLA times are not to be considered as an expected time-to-resolution.
Hours of Operation
Definitions of GitLab Global Support Hours
- 24x5 - GitLab Support Engineers are actively responding to tickets Sunday 3pm Pacific Time through Friday 5pm Pacific Time.
- 24x7 - For Emergency Support there is an engineer on-call 24 hours a day, 7 days a week.
Effect on Support Hours if a preferred region for support is chosen
When submitting a new ticket, you are asked to select a 'Preferred Region for Support'. Please select the region that most closely aligns with your working hours. This helps us assign Support Engineers located in your preferred region.
For reference, the business hours for the various regions are as follows:
- Asia Pacific (APAC): 09:00 to 21:00 AEST (Brisbane), Monday to Friday
- Europe, Middle East, Africa (EMEA): 08:00 to 18:00 CET Amsterdam, Monday to Friday
- Americas (AMER): 05:00 to 17:00 PT (US & Canada), Monday to Friday
Phone and video call support
GitLab Support Engineers communicate with you primarily through updates in your open tickets. However, there are times it may be useful and more efficient to conduct a call, video call, or screen-sharing session to progress through your ticket.
To ensure a more successful and timely outcome, please respond to requests for logs or other information and send these in advance where possible. Some calls may be used to discuss and agree on expectations or ownership of actions. The applicable Support Engineer may require additional information, during and after the call, to determine next steps and calls may be used for progression of a ticket rather than leading to resolution during the call.
When an invitation is sent, the the support engineer will:
- Send you a single-use link, through the ticket, to our call scheduling platform
- Update you through the ticket with: (a) an agenda or purpose for the call, (b) a list of any actions that must be taken to prepare for the call, and (c) the maximum time allotted for the call. In most cases, the call should end at the maximum time or when the stated purpose has been achieved
In cases of emergencies, calls may be offered early to assist in efficient troubleshooting.
During a call or screen-sharing session, support engineers will act as trusted advisors. They may request logs, invitations to run commands, or to gather data for troubleshooting. At no time will a Support Engineer request control of your computer or request access to your GitLab installation. Invitations to control your computer or access to your instance will be politely declined.
Unless you request, calls initiated by GitLab Support are not recorded.
Calls scheduled by GitLab Support are hosted on the Zoom platform. If this does not work for you, please inquire about alternative platforms.
Resources
Additional resources for getting help, reporting issues, requesting features, and so forth are listed on our get help page.
Or check our some of our other support pages:
More Help
For additional resources for getting help, reporting issues, requesting features, and so forth are listed on our get help page.