Skip to content
Snippets Groups Projects
Commit 5acb8dd8 authored by Jason Colyer's avatar Jason Colyer
Browse files

Support Readiness migration

parent 8847800b
No related branches found
No related tags found
1 merge request!73Support Readiness migration
Pipeline #863071082 passed
Showing
with 1757 additions and 0 deletions
......@@ -166,6 +166,9 @@
[support]
/content/handbook/support/ @lyle @tcooney
[support-readiness]
/content/handbook/support/readiness @lyle @jcolyer
[TeamOps]
/content/teamops/ @streas @lfarrer @cynthia
/content/handbook/teamops/ @streas @lfarrer @cynthia
......
---
title: Support Team
description: Everything you wanted to know about the GitLab Support team
canonical_path: "/handbook/support/"
---
TBD
---
title: Readiness Team
description: Everything you wanted to know about the Readiness sub-department
canonical_path: "/handbook/support/readiness/"
---
## Purpose
The purpose of Support Readiness is to:
- foster and support an environment where individuals and the larger support team are continuously improving.
- ensure the team has ready access to information about activities that will affect the customer experience.
- create operational efficiency and reduce error rates by building tooling that mechanizes or automates engineer workflows.
- evaluate and measure our customer service quality and develop plans to execute globally consistend service delivery.
## Support Readiness Links
- [Readiness Subgroup](https://gitlab.com/gitlab-com/support/readiness)
- [Operations Team](./operations)
---
title: Operations Team
description: Support Operations team is responsible for supporting the day-to-day operations and software systems used by GitLab’s global Technical Support team
canonical_path: "/handbook/support/readiness/operations"
---
The Support Readiness - Operations (i.e. Support Ops) team is responsible for
supporting the day-to-day operations and software systems used by GitLab’s
global Technical Support team, primarily our Zendesk instance, and integrations
with internal business processes and tools. The Support Operations Team is
exclusively responsible for handling Zendesk Support and Explore related
queries.
You can locate us in GitLab issues or via the
[`#support_operations`](https://gitlab.slack.com/archives/C018ZGZAMPD)
channel in slack.
## Mission
To help the Technical Support Team spontaneously and make their day to day
workflow simple and easier so the efficiency and result values of Technical
Support Team increases.
## Vision
To provide the “Best in Class” support to our support team specifically and
GitLab to increase the overall value of GitLab as a team, organization and
product.
## Meet the team
| Name | Role |
|-------------------------------------------------------|---------------------------------------|
| [Lyle Kozloff](https://gitlab.com/lyle) | Director of Support, Global Readiness |
| [Jason Colyer](https://gitlab.com/jcolyer) | Support Operations Manager |
| [Nabeel Bilgrami](https://gitlab.com/nabeel.bilgrami) | Support Operations Specialist |
| [Alyssa Villa](https://gitlab.com/avilla4) | Support Operations Specialist |
| [Dylan Tragjasi](https://gitlab.com/dtragjasi) | Support Operations Specialist |
| [Sarah Cole](https://gitlab.com/Secole) | Support Operations Specialist |
## Hiring Plan
Currently, Support Operations is using a ratios for our hiring plan. The ratios
used are:
- 40 Support Engineers to every 1 Support Operations Specialist
- 10 Support Operations Specialists to every 1 Support Operations Manager
---
title: Division of Responsibilities
description: A breakdown of the division of responsibilities for the Support Ops team
canonical_path: "/handbook/support/readiness/operations/division_of_responsibilities/"
---
To help ensure the team doesn't get overwhelmed and has the ability to focus on
specialization and learning, we divide out the responsibilities among our team.
The current division of responsibilities is:
| Category | Area | Primary DRI | Secondary DRI |
|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|------------------|
| Access Requests | [Internal License Requests](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/?state=opened&label_name%5B%5D=Internal-License) | Everyone | Everyone |
| | [Zendesk Global Provisioning](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/) | @jcolyer | @lyle |
| | [Zendesk US Federal Provisioning](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/) | @jcolyer | @lyle |
| Account Deletions | [Form](https://gitlab.com/gitlab-com/support/support-ops/forms/account-deletion) | @jcolyer | @dtragjasi |
| | [Issues](https://gitlab.com/gitlab-com/gdpr-request/-/issues) | @jcolyer | @avilla4 |
| | [Processor](https://gitlab.com/gitlab-com/support/support-ops/other-software/account-deletion-processor) | @jcolyer | @avilla4 |
| | [Questions](https://gitlab.slack.com/archives/C04357HVCJD) | @jcolyer | @secole |
| Audits | [1Password](https://gitlab.com/gitlab-com/support/support-ops/support-ops-tools/audits/-/issues) | @jcolyer | @lyle |
| | [Calendly](https://gitlab.com/gitlab-com/support/support-ops/support-ops-tools/audits/-/issues) | @avilla4 | @jcolyer |
| | [GitLab.com](https://gitlab.com/gitlab-com/support/support-ops/support-ops-tools/audits/-/issues) | @jcolyer | @lyle |
| | [Pagerduty](https://gitlab.com/gitlab-com/support/support-ops/support-ops-tools/audits/-/issues) | @dtragjasi | @jcolyer |
| | [Zendesk Global](https://gitlab.com/gitlab-com/support/support-ops/support-ops-tools/audits/-/issues) | @nabeel.bilgrami | @jcolyer |
| | [Zendesk US Federal](https://gitlab.com/gitlab-com/support/support-ops/support-ops-tools/audits/-/issues) | @secole | @jcolyer |
| Calendly | [Management](https://gitlab.com/gitlab-com/support/support-ops/other-software/calendly) | @avilla4 | @dtragjasi |
| | Procurement | @jcolyer | @lyle |
| | [Provisioning](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/) | @jcolyer | @lyle |
| Forms | [Customer Ticket Generator](https://gitlab.com/gitlab-com/support/support-ops/forms/customer-ticket-generator) | @nabeel.bilgrami | @avilla4 |
| | [Free User Offer Form](https://gitlab.com/gitlab-com/support/support-ops/forms/free-user-offer-form) | @jcolyer | @dtragjasi |
| | [L&R Internal Requests Form (Global)](https://gitlab.com/gitlab-com/support/internal-requests-form) | @jcolyer | @dtragjasi |
| | [L&R Internal Requests Form (US Federal)](https://gitlab.com/gitlab-com/support/support-ops/forms/us-federal-internal-request-form) | @jcolyer | @dtragjasi |
| | [US Federal Customer Feedback](https://gitlab.com/gitlab-com/support/support-ops/forms/us-federal-customer-feedback) | @secole | @jcolyer |
| | [Usage Ping Requests](https://gitlab.com/support/usage-ping-request) | @jcolyer | @lyle |
| Other Software | [Customer Feedback Processor US Federal](https://gitlab.com/gitlab-com/support/support-ops/other-software/customer-feedback-processor-us-federal) | @jcolyer | @secole |
| | [Free user offer processor](https://gitlab.com/gitlab-com/support/support-ops/other-software/free-user-offer-processor) | @jcolyer | @dtragjasi |
| | [L&R Internal Request Processor (Global)](https://gitlab.com/gitlab-com/support/support-ops/other-software/lnr-ir-processor) | @jcolyer | @secole |
| | [L&R Internal Request Processor (US Federal)](https://gitlab.com/gitlab-com/support/support-ops/other-software/lnr-ir-processor-us-federal) | @jcolyer | @secole |
| | [1-1-issue-generator](https://gitlab.com/gitlab-com/support/toolbox/1-1-issue-generator/) | @nabeel.bilgrami | @jcolyer |
| | [support/team page](https://gitlab.com/gitlab-com/support/team) | Everyone | Everyone |
| Pagerduty | [Management](https://gitlab.com/gitlab-com/support/support-ops/other-software/pagerduty) | @avilla4 | @jcolyer |
| | [Provisioning](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/) | @jcolyer | @lyle |
| Slack | [SGG Slackbot](https://gitlab.com/gitlab-com/support/support-ops/other-software/sgg-slackbot) | @avilla4 | @jcolyer |
| | [Workflows](https://gitlab.com/gitlab-com/support/support-ops/other-software/slack-workflows) | @jcolyer | @nabeel.bilgrami |
| Status.io | [Provisioning]((https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/)) | @jcolyer | @lyle |
| Support Ops Project | [Issues](https://gitlab.com/gitlab-com/support/support-ops/support-ops-project/) | Everyone | Everyone |
| Ticket work | | Everyone | Everyone |
| Zapier | Support Ops Zap management | @jcolyer | @secole |
| Zendesk Global | [Agents](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/agents) | @avilla4 | @dtragjasi |
| | [Articles](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/articles) | @dtragjasi | @jcolyer |
| | [Automations](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/automations) | @nabeel.bilgrami | @avilla4 |
| | [Contacts](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/contacts) | @jcolyer | @nabeel.bilgrami |
| | [Forms and Fields](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/ticket-forms-and-fields) | @jcolyer | @nabeel.bilgrami |
| | [Explore](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/explore) | @nabeel.bilgrami | @avilla4 |
| | [Macros](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/macros) | Everyone | Everyone |
| | [Organizations](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/organizations) | @dtragjasi | @avilla4 |
| | [Priority Prospects](https://gitlab.com/gitlab-com/support/support-ops/support-ops-project/-/issues/new) | @jcolyer | @secole |
| | Procurement | @jcolyer | @lyle |
| | [Salesforce Cases](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/salesforce-cases) | @jcolyer | @nabeel.bilgrami |
| | [SLAs](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/sla-policies) | @jcolyer | @lyle |
| | [Ticket Processor](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/ticket-processor) | @jcolyer | @nabeel.bilgrami |
| | [Ticket Round Robin](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/ticket-round-robin) | @nabeel.bilgrami | @dtragjasi |
| | [Triggers](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/triggers) | @nabeel.bilgrami | @avilla4 |
| | [Views](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/views) | @avilla4 | @nabeel.bilgrami |
| | [Wizard](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/wizard) | @jcolyer | @dtragjasi |
| | [Zendesk Apps](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/zendesk-apps) | @dtragjasi | @jcolyer |
| | [Zendesk Theme](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/zendesk-theme) | @dtragjasi | @jcolyer |
| | [Zendesk-Salesforce Sync](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/zd-sfdc-sync-global) | @jcolyer | @secole |
| Zendesk US Federal | [Agents](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/agents) | @secole | @jcolyer |
| | [Automations](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/automations) | @secole | @jcolyer |
| | [Macros](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/macros) | @secole | @jcolyer |
| | Procurement | @jcolyer | @lyle |
| | [Salesforce Cases](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/salesforce-cases) | @jcolyer | @secole |
| | [Ticket forms and Fields](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/ticket-forms-and-fields) | @secole | @jcolyer |
| | [Ticket Round Robin](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/ticket-round-robin) | @jcolyer | @secole |
| | [Triggers](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/triggers) | @secole | @jcolyer |
| | [Views](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/views) | @secole | @jcolyer |
| | [Zendesk Apps](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/zendesk-apps) | @secole | @jcolyer |
| | [Zendesk Theme](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/zendesk-theme) | @secole | @jcolyer |
| | [Zendesk-Salesforce Sync](https://gitlab.com/gitlab-com/support/support-ops/zendesk-us-federal/zd-sfdc-sync-us-federal) | @jcolyer | @secole |
---
title: Documentation
description: Support Operations documentation page
canonical_path: "/handbook/support/readiness/operations/docs/"
---
---
title: Calendly Documentation
description: Support Operations documentation page for Calendly
canonical_path: "/handbook/support/readiness/operations/docs/calendly/"
---
## What is Calendly
Calendly is an online appointment scheduling tool the GitLab Support team uses
for scheduling customer calls.
## User management
User management in Calendly is primarily done via the
[Admin Management page](https://calendly.com/app/organization/users). To access
this page after logging in, you would click `My Account` in the top-right of the
page and then select `Admin Management`.
Within this page, you can invite new users, change roles, and remove members.
**Note**: While this is a baseline entitlement for GitLab Support, it is not a
baseline entitlement for the rest of GitLab. As such, non-support users
requesting access to this must submit an access request and it must be reviewed
and approved by a Support Operations Manager.
#### Adding a user
To add a new user, you simply invite them to Calendly via the
[Admin Management page](https://calendly.com/app/organization/users). On that
page, you will click `+ New User` in the top-right of the page. From there, you
will input the email(s) of the user(s) you wish to invite. After inputing the
email(s), click the blue `Next` button. From here, you would select the event
types to add to the user's profile. As we don't do this by default, simply click
the blue `Finish` button. After doing so, the user(s) will be invited to join
the Calendly under our paid subscription.
#### Changing roles
To change a role of a user, locate the user on the
[Admin Management page](https://calendly.com/app/organization/users) and click
the checkbox by their name. After doing so, go to the top of the page and click
the `Change Role` button. Doing so will open a new box with a dropdown
containing a list of all roles. Simply select the new role to use and then click
the blue `Apply` button.
#### Removing a user
To remove a user, locate the user on the
[Admin Management page](https://calendly.com/app/organization/users) and click
the checkbox by their name. After doing so, go to the top of the page and click
the `Remove members` button. Doing so will open a new box two options to select:
- Remove members
- Remove members and delete their accounts
You should only ever use the first option (`Remove members`). After ensuring
that option is checked, click the blue `Remove` button.
## Team management
Managing teams in Calendly is done via the team page in question. For Support
Ops, this is normally the
[GitLab Support Calendly team page](https://calendly.com/event_types/team/44431).
On this page, you can do several things, such as creating managing event types
and adding/removing members.
#### Adding a member
To add a member to a team, click the gear icon to the right of the
`+ New Event Type`. Doing so will open a sub-menu with several options. The one
you will want is `Edit Team`. Clicking this will open the
[team settings editor page](https://calendly.com/teams/44431/edit).
From here, you will go to the `Team Members` section and click in the box that
says `Type to add team member`. From here, start typing the new member's name.
Once the Calendly box shows the user in question, click on their name. Doing
so will add them to the list of team members. Unless the user is going to manage
Calendly, leave the `can manage team` box unchecked. Once you are done there,
click the blue `Save` button at the bottom of the page.
#### Removing a member
To remove a member from a team, click the gear icon to the right of the
`+ New Event Type`. Doing so will open a sub-menu with several options. The one
you will want is `Edit Team`. Clicking this will open the
[team settings editor page](https://calendly.com/teams/44431/edit).
From here, locate the member in question and click the blue `Remove` link below
their name. Once you are done there, click the blue `Save` button at the bottom
of the page.
## Creating an event type
To create a new event type for a team, first navigate to the team page. For
Support Ops, this is normally the
[GitLab Support Calendly team page](https://calendly.com/event_types/team/44431).
From there, click the `+ New Event Type` button on the right side of the page.
On the next page, you will need to determine what kind of event type the meeting
is for:
- Round Robin: cycles between all available
- Collective: scheduling for when all selected are available (basically group
scheduling that takes everyone's availability into effect)
- Group: allows for inviting multiple people to the same meeting
The exact type to use is going to be based on what you are aiming to do.
Normally, we use Round Robin as our default event type.
Once you have decided the event type to use, click the blue button below said
event type. As we use Round Robin as our default, the remaining instructions
will focus on that event type.
The next page will ask for you event details. Here, you will give the event type
a name and a description. You can also specific an event link if you wish to
customize it (it will default to kebab-case). You also are given the option to
pick an event color (we tend to stick to purple to match GitLab).
After you are done with the event details, click the blue `Next` button to
proceed.
On the next page, you will enter the details of when people can book this event.
This can be a bit complicated, so see
[Managing event types](#managing-event-types) for more details there.
After you are done with that, click the blue `Next` button to proceed.
The next page will have you select the team members to use for the event type
and the default location (ie where the meeting is hosted). Click the check boxes
by the names of who you want in the distribution. For the location, you should
always select `Zoom`.
The top of this asks for how the distribution should be done. By default, we
select `Optimize for availability` so that it benefits the customer first and
foremost.
After you are done with that, click the blue `Next` button to proceed.
At this point, your event type is live and ready to be used. There are many more
options you can use for the event type itself, so make sure to review
[Managing event types](#managing-event-types) for more details.
## Managing event types
To manage an event type, locate the event type in question and click on the gear
icon in the top-right of the box. After doing so, click the `Edit` option in the
sub-menu. Doing so will open the event type editor. From here, there are a lot
of options that can be edited.
#### What event is this
Here you can edit the event's name, description, link, and color.
#### When can people book this event
If you had to pick one section to deem the most complicated part of event types,
this would be it. Here you determine:
- when the event can be booked
- who is available at the various times
- how far one can schedule into the future
- duration of the event_types
- buffer time before and after the event
The exact values to use are going to vary depending on the event and the
preferences of those involved in said event. While most of these values are
straight-forward, the "when the event can be booked" bit is complex and can take
a bit to get the hang of.
Due to the complexity of this section, I highly recommend watching the above
linked video. This section often needs to be tweaked and can be daunting if you
are not familiar with doing so.
#### Team members and locations
Here you will determine who is involved in the event type and the default
location the will use. Any team member who could be selected for a meeting
should have the checkbox by their name checked. The default location should
always be Zoom.
While you can set priority for event booking, we do not by default.
#### Invitee Questions
Here you can customize the questions asked when a user tries to create an
event. What exactly goes here will vary based on use case, but some good
questions to have in there might be:
- What is the ticket ID?
- If your organization in unbable to use Zoom, what platform would you like us
to try to use?
As it will vary based on the event itself, your judgement will be the best guide
on what to put here.
#### Notifications and Cancellation Policy
Here you can edit the notifications and cancellation policy. By default, we do
not customize this option. It should default to
`Calendar Invitations, No Reminders`.
#### Confirmation Page
At this time we do not use this option. You should not change anything here and
it should default to `Calednly confirmation page, no active links`.
#### Collect Payments
At this time we do not use this option. You should not have anything here and
it should state `no payment method`.
---
title: Change Criticalities
description: Support Operations documentation page for change criticalities
canonical_path: "/handbook/support/readiness/operations/docs/change_criticalities"
---
## Overview
Mirroring
[infrastructure's change management criticalities](/handbook/engineering/infrastructure/change-management/#change-criticalities)
Support Ops defines changes on a C1 - C4 scale that helps determine appropriate
planning horizons.
Criticalities are taken into effect when deciding on which deployment an
issue/MR will make it into.
## Determining Criticality
When you first begin working an issue or MR, you should determine the change
criticality of the task at hand. Once you have determined that, add the
appropriate label to the issue:
| Criticality | Label |
|---------------|--------------------------|
| Criticality 1 | ~"support-ops-change::1" |
| Criticality 2 | ~"support-ops-change::2" |
| Criticality 3 | ~"support-ops-change::3" |
| Criticality 4 | ~"support-ops-change::4" |
Some issue and MR templates will automatically do this for you, but you should
still review the task at hand to determine if the default value was accurate.
For guidance on determining the change criticality, see
[below](#criticality-level-definitions).
Always use your best judgment on determining the criticality level. When in
doubt, reach out to a Support Operations Manager for assistance.
## Criticality level definitions
#### Criticality 1
These are changes with high impact or high risk that may significantly modify
Support Engineer or Customer experience. If a change is going to cause downtime
to the environment, it is always categorized a C1.
Some examples of Criticality 1 requests are:
- Changing the functionality of a widely used Zendesk View
- Altering Zendesk in a way to support a significant process change
- Changes to any SLA policy in use
#### Criticality 2
These are changes that aren't expected to significantly impact Support Engineer
or Customer experiences, but which still carry some risk of impact if something
unexpected happens.
Some examples of Criticality 2 requests are:
- Updating the theme on the Support Portal
- Adding a new ticket form
- Changing any triggers/automations relating to SSAT or Support KPIs
#### Criticality 3
These are changes with either no or very-low risk of negative impact, but where
there is still some inherent complexity, or it is not fully automated and
hands-off.
Some examples of Criticality 3 requests are:
- Adding a new form field on a Support form
- Bulk removing expired Zendesk organizations
- Adding a new Zendesk app that will make things more convenient for Support
Engineers
- Removing or deactivating active macros
#### Criticality 4
These are changes that are exceedingly low risk and commonly executed, or which
are fully automated. Often these will be changes that are mainly being recorded
for visibility rather than as a substantial control measure.
Some examples of Criticality 4 requests are:
- Adding or removing users from a ZD organization
- Creating or updating macros
---
title: Change Management
description: Support Operations documentation page for change management
canonical_path: "/handbook/support/readiness/operations/docs/change_management"
---
This page is a work in progress. Check back soon for updates.
## Standard change management
TBD
#### Service level agreements information
The following process is _required_ for all Zendesk SLA changes that impact any
customer facing ticket.
1. An issue should be created in
[support-team-meta](https://gitlab.com/gitlab-com/support/support-team-meta/)
using the
[Requested Change Template](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/new?issuable_template=Requested%20Change).
1. The support team discusses the desire to change, citing reason and potential
impact.
1. The Support Ops Manager, @jcolyer, is pinged in the issue once the
discussion is over and a decision has been reached, with approval from at
least ONE Senior Support Manager.
1. The Support Ops Manager will make an issue in the
[legal tracker](https://gitlab.com/gitlab-com/legal-and-compliance/-/issues)
requesting the change.
1. Once legal has approved, the Support Ops Manager will announce the plan to
make the SLA change to the support team via both slack (#support_team-chat)
and the SWIR. It should be scheduled for the next Saturday, during
non-business hours.
- If legal does not approve, the Support Ops Manager will update the
original issue and close it out.
1. The Support Ops Manager will implement the change. Following the
implementation, the Support Ops Manager will announce the change has been
made via both slack (#support_team-chat) and the SWIR.
1. The Support Ops Manager will update relevant documentation with the change.
1. The Support Ops Manager will update the original issue and close it out.
## Immediate deployments
Some items we work on will warrant immediate deployments. In situations like
these, merging things into the master branch should result in a deployment.
For anything that does not follow this behavior, please see the
[special situations](#special-situations).
## Special situations
#### Support team page change management
All changes to the support team page would follow the nature of
[Immediate deployments](#immediate-deployments).
#### Zendesk agents change management
For any changes relating to Support team, the
[sync](/handbook/support/readiness/operations/docs/zendesk/agents#support-team)
will handle them, and thus the
[Standard change management](#standard-change-management) can be used.
For all other cases, you will have to manually make the changes in Zendesk
itself.
#### Zendesk emails change management
As we currently do not do syncs on Zendesk emails, you will have to make the
changes in Zendesk itself.
#### Zendesk group change management
As we currently do not do syncs on Zendesk groups, you will have to make the
changes in Zendesk itself.
#### Zendesk macros change management
Due the nearly non-existent impact macros have, these follow the nature of
[Immediate deployments](#immediate-deployments)
#### Zendesk organizations change management
For changes to the Support Team organization notes can follow
[Immediate deployments](#immediate-deployments).
Changes not controlled by the
[Zendesk-Salesforce Sync](/handbook/support/readiness/operations/docs/zendesk/zendesk_salesforce_sync)
are not synced and would need to be done manually in Zendesk itself.
#### Zendesk role change management
As we currently do not do syncs on Zendesk roles, you will have to make the
changes in Zendesk itself.
#### Zendesk schedules change management
As we currently do not do syncs on Zendesk schedules, you will have to make the
changes in Zendesk itself.
#### Zendesk settings change management
As we currently do not do syncs on Zendesk settings, you will have to make the
changes in Zendesk itself.
#### Zendesk theme change management
Due to the nature of Zendesk themes, simply committing changes to the master
branch will have no effect. As such, changes to the theme must be done via
[Zendesk Guide](/handbook/support/readiness/operations/docs/zendesk/guide).
#### Zendesk webhook change management
As we currently do not do syncs on Zendesk webhoooks, you will have to make the
changes in Zendesk itself.
---
title: 1-1 issue generator
description: Support Operations documentation page for the 1-1 issue generator
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/1-1_issue_generator"
---
## What is the 1-1 issue generator
The 1-1 issue generator is a project created in house to assist in the creation
of GitLab issues for use in 1 on 1 meetings. This uses a customizable formatting
and various APIs to gather details and present it in a way that is useful to
both manager and report.
The source code for it is located
[here](https://gitlab.com/gitlab-com/support/toolbox/1-1-issue-generator).
## How does the 1-1 issue generator work
This all works utilizing ruby scripting and GitLab CI/CD. The CI/CD component
of this is straight forward, in that it has 4 stages and they run the ruby
scripts within the project.
### Test stage
This stage runs the `./bin/test` file within the repo. That file tests for the
following:
- Is the YAML file able to be parsed?
- Do comment YAML files contain the ticket_review boolean?
- Do comment YAML files contain the comments array?
- Are the template files readable by an ERB renderer?
If any of the above answers are no, then the test stage will fail, preventing
the CI/CD from running further. This is used to prevent merging bad files into
the repo.
#### Gather stage
This stage runs the `./bin/gather` file within the repo. That file runs the
`gather` function within the `Generator::Client` class.
The `Generator::Client.gather` function obtains various data points spanning
from:
- Zendesk Global
- Zendesk US Federal
- Pagerduty
- GitLab.com
It combines all this data into an artifact file.
#### Report stage
This stage runs the `./bin/daily_report` file within the repo. That file takes
the artifact made in the [Gather stage](#gather-stage) and commits it to the
[Daily reports repo](https://gitlab.com/gitlab-com/support/1-1s/daily-reports).
#### Create stage
**Note**: While previous stages ran for multiple people, some jobs in this stage
will only run for a single person at a time.
This stage will run one of three different jobs:
- weekly_report: This creates 1-1 issues for weekly use
- monthly_report: This creates an issue covering a month's worth of data
- quarterly_report: This creates an issue covering the current quarter's worth
of data
All of the jobs that run will call to a file in the repo that will link to
various functions relating to the job itself. While there is some variance in
how the three run, overall they all gather data from the
[Daily reports repo](https://gitlab.com/gitlab-com/support/1-1s/daily-reports)
and then pass it into an ERB template file. This is then compiled into a
gitlab.com issue via the GitLab API.
## When does 1-1 issue generator run
By using GitLab CI/CD schedules, we have the following set to run at various
intervals:
| Name | What it does | When it runs |
|-------------------|----------------------------------------|-------------------|
| Gather metrics | Runs the [Gather stage](#gather-stage) | Daily at 0100 UTC |
| Create 1-1 Issues | Runs the [Create stage](#create-stage) | Daily at 0300 UTC |
## Change management
As these are maintained via sync repositories, our standard change management
process applies to all 1-1 issue generator changes. See
[standard change management](/handbook/support/readiness/operations/docs/change_management#standard-change-management)
for more information.
#### Labels to use
For all issues and MRs involving 1-1 issue generator, the label
`Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
As this is an internal tool with no direct impact, all issues/MRs related to
1-1 issue generator will be classified as
[criticality 4](/handbook/support/readiness/operations/docs/change_criticalities#criticality-4)
---
title: GitLab Documentation
description: Support Operations documentation page for GitLab
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/"
---
---
title: Account deletions
description: Support Operations documentation page for the account deletion form and processor
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/account_deletions"
---
## What is the account deletion form?
The account deletion form is a simple HTMl form generated via GitLab Pages that
is used for account deletion and data privacy requests.
The source code for it is located
[here](https://gitlab.com/gitlab-com/support/support-ops/forms/account-deletion).
## What is the account deletion processor?
The account deletion processor is a set of scripts that handle requests sent
from the account deletion form.
The source code for it is located
[here](https://gitlab.com/gitlab-com/support/support-ops/other-software/account-deletion-processor).
## What are the triage policies?
Utilizing the
[GitLab Triage Gem](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), the
triage policies are a group of conditions and actions that are enacted upon
issues within the
[Account Deletion and Other Requests project](https://gitlab.com/gitlab-com/gdpr-request).
The source code for it is located
[here](https://gitlab.com/gitlab-com/gdpr-request/-/blob/master/.triage-policies.yml)
## How does it all work?
The account deletion form, when submitted, sends an AJAX request to trigger a
pipeline on ops.gitlab.net. This then runs the code of the account deletion
processor.
The account deletion processor will then analyze the response to determine the
validity of the request itself. The end result of this analyzing is an issue
being created via service desk.
The triage policies of the project where the issue is made then act on the issue
depending on the various conditions used within.
## Change management
As these are maintained via sync repositories, our standard change management
process applies to all account deletion form or processor changes. See
[standard change management](/handbook/support/readiness/operations/docs/change_management#standard-change-management)
for more information.
#### Labels to use
For all issues and MRs involving account deletion form changes, the label
`Support-Ops-Category::Forms` should be used.
For all issues and MRs involving account deletion processor or triage policy
changes, the label `Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
As this tool is vital to properly handling account deletion and data privacy
requests, all issues/MRs related to any of the components of account deletion
will be classified as either
[criticality 1](/handbook/support/readiness/operations/docs/change_criticalities#criticality-1)
or
[criticality 2](/handbook/support/readiness/operations/docs/change_criticalities#criticality-2)
---
title: ADWR
description: Support Operations documentation page for account deletion weekly reports
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/adwr"
---
## What is the ADWR
ADWR (Account Deletion Weekly Report) is a project within gitlab.com that
generates weekly reports concerning account deletion requests.
The source code for it is located
[here](https://gitlab.com/gitlab-com/support/toolbox/adwr).
## How does the ADWR work
ADWR works by utilizing GitLab CI/CD and ruby scripts. It runs in two stages:
- gather
- create
### gather stage
This stage runs the `./bin/gather` script, which includes the ADWR lib files and
calls the function `ADWR::Gather.run!`. This function makes an API request to
gitlab.com to grab all the issues within the
[Account Deletion and Other Requests project](https://gitlab.com/gitlab-com/gdpr-request)
that are in an open state. It then compiles these issues into a JSON file, which
is stored as an artifact.
### create stage
This stage runs the `./bin/create` script, which includes the ADWR lib files and
calls the function `ADWR::Create.run!`. This function uses the artifact made in
the [gather stage](#gather-stage) to generate a report (which is an
[ADWR issue](https://gitlab.com/gitlab-com/support/internal-requests/-/issues?scope=all&state=opened&label_name[]=ADWR)).
The body of the created issues comes from parsing the issues from the artifact
made in the [gather stage](#gather-stage), skipping those without an assignee.
This report will contain a table with the following information:
- the issue title
- the assignee's gitlab.com username
- the assignee's manager's gitlab.com username
- labels the issue in question has.
## When does the ADWR run
Currently, ADWR runs every Sunday at 0000 UTC.
## Change management
As these are maintained via sync repositories, our standard change management
process applies to all ADWR changes. See
[standard change management](/handbook/support/readiness/operations/docs/change_management#standard-change-management)
for more information.
#### Labels to use
For all issues and MRs involving ADWR, the label
`Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
As this is an internal tool with no direct impact, all issues/MRs related to
ADWR will be classified as
[criticality 4](/handbook/support/readiness/operations/docs/change_criticalities#criticality-4)
---
title: Contact Management Projects
description: Support Operations documentation page for contact managemrnt projects
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/contact_management_projects"
---
## What is a contact management project?
Contact management projects are projects on GitLab.com that allows a customer to
manage their support contacts on Zendesk Global.
## How does it work
When commits are made on the project in question, a webhook triggers with
specific variables to trigger a pipline on ops.gitlab.net that is using the code
from the
[contacts project](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/contacts).
The code itself parses the YAML file for the project that triggered the pipeline
to determine what organization contact changes are required on Zendesk Global.
It will then perform a sync with the needed changes.
## How do we set this up
These are setup via several stages that all work together to reflect a complete
contact management project.
#### Intro stage
In this stage, a customer has requested to have a contact management project
setup via a Support Ops ticket. Before we can begin the setup, we need to
confirm with the requester which user(s) will be the ones able to edit the
contacts.yaml file. To do this, use the macro
`Support::Support Ops::Contact management intro`.
Once the requester has confirmed the user(s) who will be maintaining the
contacts.yaml file, you need to ensure the users provided are associated to the
organization currently. If they are not, you should associate them to the
organization first.
After doing so, you will need to get a list of the organization's current
contacts for use in the setup stage.
After doing so, you are good to move to the next stage.
**Jason Pro-tip**
I would recommend exporting them as a CSV file via
[Advanced search](https://gitlab.zendesk.com/agent/apps/advanced-search). When
doing so, make sure the only columns that display are the user's name and email.
With the CSV file downloaded, you could then run the following code via terminal
to change the CSV format into the YAML format you will need later:
```bash
awk -F',' '{if ($1!="Query"&&$1!=""&&$1!="\"name\"") {print "- name: "$1"\n email: "$2}}' csv_file
```
This will work the majority of the time and make it a bit easier down the line.
#### Project creation
For organizations without an existing collaboration project, we create all
contact management projects within the
[zd-global-orgs group](https://gitlab.com/groups/support/zd-global-orgs).
1. Navigate to that group and click the blue `New project` button at the upper
right part of the page.
1. Select `Create from template`
1. Click the `Group` tab
1. Click the blue `Use template` button to the right of
`Contact Management Project Template`
1. Set the `Project name` to `Organization XXXX` (replacing `XXXX` with the
Zendesk Organizaton ID)
- Ensure the `Project slug` is `organization-xxxx` (replacing `xxxx` with the
Zendesk Organizaton ID)
1. Click the blue `Create project` button
After creation the project, you need to double check all settings are accurate.
In theory, the template project will handle that, but it always best to be sure.
The items to check are:
- Settings
- Settings > General
- Visibility, project features, permissions
- Project visibility: Private
- Enable CVE ID requests in the issue sidebar: disabled
- Forks: disabled
- Git Large File Storage (LFS): disabled
- CI/CD: disabled
- Container registry: disabled
- Analytics: disabled
- Requirements: disabled
- Secuirty & Compliance: disabled
- Wiki: disabled
- Snippets: disabled
- Package registry: disabled
- Pages: disabled
- Monitor: disabled
- Environments: disabled
- Feature flags: disabled
- Infrastructure: disabled
- Releases: disabled
- Settings > Repository
- Branch defaults
- Default branch: master
- Protected branches
- Branch: master
- Allowed to merge: 2 roles (Maintainers+Developers)
- Alowed to push: 2 roles (Maintainers+Developers)
- Allowed to force push: disabled
- Code owner approval: disabled
- Project files
- CONTACTS.md
- Verify the contents match what is detailed
[here](https://gitlab.com/support/zd-global-orgs/project-templates/contact-management-project-template/-/blob/master/CONTACTS.md)
- contacts.yaml
- Verify the contents match what is detailed
[here](https://gitlab.com/support/zd-global-orgs/project-templates/contact-management-project-template/-/blob/master/contacts.yaml)
After everything looks good to go, make sure to copy the project's ID. You'll
need it in the next step.
##### For organizations with an existing collaboration project
These are a bit trickier and can require a ton of back and forth. For the time
being, please assign these to a Support Operations Manager to work.
#### Webhook setup
Next, you'll need to setup the webhook for the project. To do this, navigate to
`Settings > Webhooks` on the project.
You then need to create a new webhook using the following information:
- URL:
`https://ops.gitlab.net/api/v4/projects/619/ref/master/trigger/pipeline?token=TOKEN&variables[PROJECT_ID]=PROJECT_ID`
- Replace TOKEN with the Contact Sync Token found within the Support Ops Vault
in 1Password.
- Replace PROJECT_ID with the project's ID.
- Check the box next to `Push events`
- Check the box next to `Enable SSL verification`
Once all that is in place, click the blue `Add webhook` button.
#### Organization update
Next, you will need to update the organization within Zendesk. You want to set
the `Contact Management Project ID` field to have the project ID.
#### Files setup
Next, you will add the contact's and add the organization ID to the
contacts.yaml file of the project.
Every contact within that file uses the format:
```yaml
- name: NAME_OF_CONTACT
email: EMAIL_OF_CONTACT
```
Where `NAME_OF_CONTACT` is the contact's name and `EMAIL_OF_CONTACT` is the
contact's email. Both are required, so if you do not know the `NAME_OF_CONTACT`,
use the `EMAIL_OF_CONTACT` value.
An example of a working and valid contacts.yaml can be found
[here](https://gitlab.com/support/zd-global-orgs/organization-380989798980/-/blob/master/contacts.yaml).
You should ensure the contacts listed matching what the Zendesk organization
_currently_ has in place.
Once that is all setup, commit the changes to the file (this will kick off a
sync pipeline on ops.gitlab.net).
#### User invites
Next, you need to invite the user(s) who will maintain the contacts.yaml file.
You should have a list of who to invite from your previous work in the ticket.
To invite the users, do the following:
1. Click `Project information` on the top-left hand side of the page
1. Click `Members` on the top-left hand side of the page (under
`Project information`)
1. Click the blue `Invite members` button at the top-right hand side of the page
1. Enter the email(s) to use under the `Username or email address` text box
1. Under `Select a role`, select `Developer`
1. Click the blue `Invite` button on the bottom-right of the modal
#### Final stage
With all of that done, the final part is to update the ticket using the macro
`Support::Support Ops::Contact management project setup`.
From there, the user might come back with questions or a need for assistance. Do
your best to guide them and assist them however you can. If you get stuck, reach
out in the support operations slack channel.
## Removal
To remove the setup, simply delete the project in question. Doing so will
effectively remove the contact management sync for the organization completely.
**NOTE** If the customer is over 30 contacts at the time of the removal request,
ask the customer to use the contact management project to lower their contact
numbers down to 30 first (as that is the limit for organization contacts when
not using a contact management sync project).
---
title: DEWR
description: Support Operations documentation page for dotcom escalation weekly reports
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/dewr"
---
## What is the DEWR
DEWR (Dotcom Escalation Weekly Report) is a project within gitlab.com that
generates weekly reports concerning dotcom console escalations.
The source code for it is located
[here](https://gitlab.com/gitlab-com/support/toolbox/dewr).
## How does the DEWR work
ADWR works by utilizing GitLab CI/CD and ruby scripts. It runs in two stages:
- gather
- create
### gather stage
This stage runs the `./bin/gather` script, which includes the DEWR lib files and
calls the function `DEWR::Gather.run!`. This function makes an API request to
gitlab.com to grab all the issues within the
[Support Internal Requests project](https://gitlab.com/gitlab-com/support/internal-requests)
that are in either recent or in an open state. It then compiles these issues
into a JSON file, which is stored as an artifact.
### create stage
This stage runs the `./bin/create` script, which includes the DEWR lib files and
calls the function `DEWR::Create.run!`. This function uses the artifact made in
the [gather stage](#gather-stage) to generate a report (which is an
[DEWR issue](https://gitlab.com/gitlab-com/support/internal-requests/-/issues?scope=all&state=opened&label_name[]=DEWR)).
The body of the created issues comes from parsing the issues from the artifact
made in the [gather stage](#gather-stage).
## When does the DEWR run
Currently, DEWR runs every Saturday at 0000 UTC.
## Change management
As these are maintained via sync repositories, our standard change management
process applies to all DEWR changes. See
[standard change management](/handbook/support/readiness/operations/docs/change_management#standard-change-management)
for more information.
#### Labels to use
For all issues and MRs involving DEWR, the label
`Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
As this is an internal tool with no direct impact, all issues/MRs related to
DEWR will be classified as
[criticality 4](/handbook/support/readiness/operations/docs/change_criticalities#criticality-4)
---
title: gl-support-bot tokens
description: An overview of gl-support-bot token use
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/gl-support-bot_tokens"
---
## What is gl-support-bot used for?
For many of our scripts and automations, we use tokens owned by the
[gl-support-bot](https://gitlab.com/gl-support-bot) user.
## List of usage
**Note** All links given are internal only and require access to the system
using it.
| Item using it | Token Name |
|--------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------|
| [1-1 Issue Generator](https://ops.gitlab.net/gitlab-com/support/1-1-issue-generator) | Support Ops - 1-1-issue-generator |
| [ADWR](https://ops.gitlab.net/gitlab-com/support/adwr) | Support Ops - ADWR |
| [Agents (Global)](https://ops.gitlab.net/gitlab-com/support/zendesk-global/agents) | Support Ops - Agents (Global) |
| [Agents (US Federal)](https://ops.gitlab.net/gitlab-com/support/zendesk-us-federal/agent-signatures) | Support Ops - Agents (US Federal) |
| [Customer Feedback](https://gitlab.com/gitlab-com/support/feedback) | Support Ops - Customer Feedback |
| [DEWR](https://gitlab.com/gitlab-com/support/toolbox/dewr) | Support Ops - DEWR |
| [Fieldnotes App](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/zendesk-apps/fieldnotes-app) | Support Ops - Field notes app |
| [Internal Requests](https://gitlab.com/gitlab-com/support/internal-requests) | Support Ops - Internal Requests |
| [Mechanizer](https://gitlab.com/gitlab-com/support/toolbox/mechanizer) | Support Ops - Mechanizer |
| [Mechanizer Reports](https://gitlab.com/gitlab-com/support/toolbox/mechanizer-reports) | Support Ops - Mechanizer Reports |
| [SGG Slackbot](https://ops.gitlab.net/gitlab-com/support/other-software/sgg-slackbot) | SGG Slackbot |
| [Support Pairing](https://gitlab.com/gitlab-com/support/support-pairing) | Support Ops - Support Pairing |
| [support-team-meta](https://gitlab.com/gitlab-com/support/support-team-meta) | Support Ops - support-team-meta |
| [Ticket Round Robin (Global)](https://ops.gitlab.net/gitlab-com/support/zendesk-global/ticket-round-robin) | Support Ops - Ticket round robin (Global) |
| [Ticket Round Robin (US Federal)](https://ops.gitlab.net/gitlab-com/support/zendesk-us-federal/ticket-round-robin) | Support Ops - Ticket round robin (US Federal) |
| [ZD Global webhook](https://gitlab.zendesk.com/admin/apps-integrations/webhooks/webhooks/01FQKTQHNEN1FA09JT54CZMKJQ/details) | Support Ops - ZD Global webhook 01FQKTQHNEN1FA09JT54CZMKJQ |
| [ZD Global webhook](https://gitlab.zendesk.com/admin/apps-integrations/webhooks/webhooks/01FQKTSD2Y3JTH0BMF09QNBN0H/details) | Support Ops - ZD Global webhook 01FQKTSD2Y3JTH0BMF09QNBN0H |
| [ZD Global webhook](https://gitlab.zendesk.com/admin/apps-integrations/webhooks/webhooks/01G4N1H580V8BK1G1FP6HE2MAR/details) | Support Ops - ZD Global webhook 01G4N1H580V8BK1G1FP6HE2MAR |
| [ZD US Federal webhook](https://gitlab-federal-support.zendesk.com/admin/apps-integrations/webhooks/webhooks/01FPDK25154KSCJNHVD2DY49SM/details) | Support Ops - ZD US Federal webhook 01FPDK25154KSCJNHVD2DY49SM |
| [ZD US Federal webhook](https://gitlab-federal-support.zendesk.com/admin/apps-integrations/webhooks/webhooks/01FT8S9Y6G4BPBV6EA1SVCSWJF/details) | Support Ops - ZD US Federal webhook 01FT8S9Y6G4BPBV6EA1SVCSWJF |
| [Zap 119607390](https://zapier.com/editor/119607390/published) | Support Ops - Zap 119607390 |
| [Zap 119775033](https://zapier.com/editor/119775033/published) | Support Ops - Zap 119775033 |
| [Zap 123381580](https://zapier.com/editor/123381580/published) | Support Ops - Zap 123381580 |
| [Zap 127101263](https://zapier.com/editor/127101263/published) | Support Ops - Zap 127101263 |
| [Zap 140595556](https://zapier.com/editor/140595556/published) | Support Ops - Zap 140595556 |
| [Zap 140604030](https://zapier.com/editor/140604030/published) | Support Ops - Zap 140604030 |
| [Zap 155828670](https://zapier.com/editor/155828670/published) | Support Ops - Ticket Escalations |
| [Zap 141986381](https://zapier.com/editor/141986381/published) | Support Ops - Auto-work account blocked tickets (Global) |
## Requesting a token
To request the token, file an
[acccess request](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/new?issuable_template=API_Token_Request).
For the issue, the `Service Name` is `gl-support-bot`
Please assign the issue to Jason Colyer and Lyle Kozloff at this time.
---
title: L&R internal requests
description: Support Operations documentation page for the L&R internal requests
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/lnr_irs"
---
## What is the L&R IR form?
The L&R IR form is a simple HTMl form generated via GitLab Pages that is used
for L&R IRs.
The source code for the Global variant is located
[here](https://gitlab.com/gitlab-com/support/support-ops/forms/internal-requests-form).
The source code for the US Federal variant is located
[here](https://gitlab.com/gitlab-com/support/support-ops/forms/us-federal-internal-request-form).
## What is the L&R IR processor?
The L&R IR processor is a set of scripts that handle requests sent from the L&R
IR form.
The source code for the Global variant is located
[here](https://gitlab.com/gitlab-com/support/support-ops/other-software/lnr-ir-processor).
The source code for the US Federal variant is located
[here](https://gitlab.com/gitlab-com/support/support-ops/other-software/lnr-ir-processor-us-federal).
## How does it all work?
The L&R IR form, when submitted, sends an AJAX request to trigger a pipeline on
ops.gitlab.net. This then runs the code of the L&R IR processor.
The L&R IR processor will then analyze the response to determine the validity of
the request itself. The end result of this analyzing is a Zendesk ticket being
created.
## Change management
As these are maintained via sync repositories, our standard change management
process applies to all L&R IR form or processor changes. See
[standard change management](/handbook/support/readiness/operations/docs/change_management#standard-change-management)
for more information.
#### Labels to use
For all issues and MRs involving L&R IR form changes, the label
`Support-Ops-Category::Forms` should be used.
For all issues and MRs involving L&R IR processor changes, the label
`Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
As this tool is very important in the interactions between sales and support,
all issues/MRs related to any of the components of L&R IRs will be classified as
either
[criticality 2](/handbook/support/readiness/operations/docs/change_criticalities#criticality-1)
or
[criticality 3](/handbook/support/readiness/operations/docs/change_criticalities#criticality-2)
---
title: Suport Team page
description: Support Operations documentation page for the Support team page
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/support_team_page"
---
## What is the Support Team Page
The [Support Team page](https://gitlab-com.gitlab.io/support/team/) is a page
generated from the content found within the
[Support Team repo](https://gitlab.com/gitlab-com/support/team). It contains
various useful functions and information, such as areas of focus, skill sets
within the team, who is oncall, a pairing counter, etc.
## How does the Support Team Page work
The Support Team Page is built via [Jekyll](https://jekyllrb.com/) and some
ruby scripts to generate the markdown files Jekyll uses. While a solid
understanding of Jekyll will help in understanding exactly how it all works,
this training material will go over the various folders and files to help you
understand the general layout of the repo and how it translates into the page
itself.
#### _includes folder
The _includes folder within the repo is used to store partials (ie HTML files
that make up a part of a page instead of a whole page). What exactly one uses in
the `_includes` folder depends on the developer. For the Support Team Page, we
use it to contain the HTML head DOM, any Javascript blocks we might use, and the
navigation bar.
#### _layouts folder
The _layouts folder is used for creating HTML template files you can utilize in
the various pages of your site. You can have as many as you want and can use
these in the site generation files as you see fit, but for the Support Team
Page, we use one single template file: default.html
#### _sass folder
The _sass folder is used to store SCSS files. SCSS, or Syntactically Awesome
Style Sheet (where SAAS comes from), files are more advanced versions of CSS
(Cascading Style Sheet) files. It allows for more dynamically built CSS files
that can use things such as variables. We use a single `main.scss` file for the
Support Team Page.
#### assets folder
The assets folder is used to store static content, such as CSS files, images,
Javascript files, fonts, etc. While the exact method to use this can vary based
on programmaing style, for the Support Team Page, we use subfolders within the
assets folder to store static files:
- css - Stores CSS files
- images - Stores image files
- js - Stores javascript files
#### collection folders
Collection folders as used to store files relating to a collection, which is a
Jekyll way of grouping related content. Collections are defined in the
[_config.yml file](#_configyml). For the Support Team Page, we have the following collection
folders:
- _members
- _skills
- _modules
- _module-catalog
- _oncall
- _pairings
As we generate these dynamically via the CI/CD (see
[file generation](#file-generation)), the folders do not contain any
data normally.
##### collection file
A collection file is simply a file within a collection folder than contains
information/content about said collection item. The exact contents of the file
can vary from collection to collection (and developer to developer), but the
biggest usefulness of these files is the ability to make metadata variables for
the collection item.
As an example, one collection file we make is the `jcolyer.yaml` file. This is
made under the members collection, and contains a large amount of information
about Jason Colyer:
```yaml
---
name: Jason Colyer
email: jcolyer@gitlab.com
title: Support Operations Manager
reports_to: Tom Cooney
region: AMER-C
```
Using this example, we have 5 variables associated to this member:
- member.name
- member.email
- member.title
- member.reports_to
- member.region
This is quite useful, especially in working with the dynamic nature of site
generation Jekyll provides.
This example was a YAML file, but you can use other files, such as markdown. If
using markdown, the variables are set within the metadata block, which starts
and ends with three hyphens (`---`). As an example:
```yaml
---
module-name: "vagrant"
area: "Troubleshooting & Diagnostics"
gitlab-group: "Enablement:Distribution Group"
maintainers:
- [astrachan]
---
```
Using this example, we have 4 variables associated to this member:
- module_catalog.module-name
- module_catalog.area
- module_catalog.gitlab-group
- module_catalog.maintainers
#### _config.yml
This is the file that Jekyll uses to determine how to setup and build the site.
The contents within can also be used as variables in the site files themselves.
The exact contents of a _config.yml file can vary from site to site, but ours
has the following:
| Item | What it does |
|-------------|--------------|
| title | The title for the project |
| email | The author email |
| description | The description for the project |
| baseurl | The subpath of your site |
| url | The base hostname & protocol for the site |
| theme | What theme to use |
| plugins | Any plugins to include into the site |
| collections | Defines the collections for the site |
| saas | Configuration options for SAAS rendering |
#### site page files
These are files that will determine what pages exist for the site by default (ie
not dynamically generated via collections, groups, etc.). These will vary from
site to site, but for the Support Team Page we have the following:
| File | What it is for |
|----------------------|----------------|
| ar_helper.md | The AR Helper page, which displays AR lines for each person |
| areas-of-focus.md | The Areas of Focus page, which displays where each person's focus is based |
| index.md | The home page |
| oncall.md | The Oncall page, which displays who is oncall currently and the following week |
| pairings.md | The Pairings page, which displays the number of pairings each person has completed |
| personal.md | The Personal Info page, which displays information about each person |
| skills-by-person.md | The Skills by Person page, which displays each person and their skill set |
| skills-by-subject.md | The Skills by Subject page, which displays each skill set and the persons who have them |
| skills-catalog.md | The Skills Catalog page, which displays various modules Support has |
Normally, a site page file like the ones we use will be in the format of:
```html
---
metadata block
---
page content
```
The exact contents of each file can vary from site to site, but to help get a
general feel for what they can do, we'll dig into two of them a bit deeper.
##### index.md
At the time of writing this training document, the index.md file contains the
following:
```html
---
layout: default
title: Home
---
Welcome to this site - it's a work in progress!
Click the links on the left to get an idea of what content will live here.
Generated via:
- [Support Team Project](https://gitlab.com/gitlab-com/support/team)
- [support-team.yaml](https://gitlab.com/gitlab-com/support/team/-/blob/master/data/support-team.yaml)
```
You can see how it starts with three hyphens (`---`). This is used to start the
metadata block, which Jekyll will use in the page generation. The next line then
specifies the layout for the page to use (default in this case). The following
line then specifies the page's title (Home in this case). After that, three
hyphens are used once more to specify the end of the metadata block.
After that, the actual content you want for the page is put into place. In the
case of the index.md file, it is static content.
##### skills-by-person.md
At the time of writing this training document, the skills-by-person.md file
contains the following:
```html
---
layout: default
title: Skills by Person
---
<table class='table table-striped table-hover dataTable'>
<thead class='thead thead-dark'>
<tr>
<th>Name</th>
<th>Region</th>
<th>Modules</th>
<th>Knowledge Areas</th>
</tr>
</thead>
<tbody>
{% for m in site.members %}
{% if m.modules.size > 0 or m.knowledge_areas.size > 0 %}
<tr>
<td class='align-middle'>{{ m.name }}</td>
<td class='align-middle'>{{ m.region }}</td>
<td>
<ul>
{% for b in m.modules %}
<li>{{ b }} Module</li>
{% endfor %}
</ul>
</td>
<td>
<ul>
{% for k in m.knowledge_areas %}
<li>{{ k }}</li>
{% endfor %}
</ul>
</td>
</tr>
{% endif %}
{% endfor %}
</tbody>
</table>
```
You can see how it starts with three hyphens (`---`). This is used to start the
metadata block, which Jekyll will use in the page generation. The next line then
specifies the layout for the page to use (default in this case). The following
line then specifies the page's title (Skills by Person in this case). After
that, three hyphens are used once more to specify the end of the metadata block.
After that, the actual content you want for the page is put into place. In the
case of the skills-by-person.md file, it is a mix of static and dynamic content.
The static content is a HTML table, using some bootstrap classes for stylistic
choices. The line right after `<tbody>` is where dynamic content comes into
play.
In Jekyll (and several other renderers, such as liquid), `{%` is used to start
a code block (with `%}` being used to end said code block).
In the case of line 15, `{% for m in site.members %}` is being used to start a
for loop. This specifically it stating to loop on `site.members`, where `site`
is the main variable for the site itself (a default from Jekyll) and `members`
is a collection we have defined (see [file generation](#file-generation) for how
that is done). For each iteration of the loop, the variable `m` will be used to
refer to the item within the iteration.
The next line (`{% if m.modules.size > 0 or m.knowledge_areas.size > 0 %}`), is
declaring an if statement that checks if the member's modules count is greater
than zero or the member's knowledge_areas count is greater than zero. If they
are, it will then render the next lines. If not, Jekyll will jump to the
corresponding `{% endif %}` block and continue rendering from there (line 35 in
this case).
In the if block:
- line 17 is simply static content starting a table row.
- line 18 creates a table cell that contains the member's name.
- line 19 creates a table cell that contains the member's region.
- line 20 is simply static content starting a table cell.
- line 21 is simply static content starting an unordered list.
- line 22 is starting a for loop on the member's modules.
- line 23 creates a list item contain the module.
- line 24 ends the for loop started on line 22.
- line 25 is simply static content ending an unordered list.
- line 26 is simply static content ending a table cell.
- line 27 is simply static content starting a table cell.
- line 28 is simply static content starting an unordered list.
- line 29 is starting a for loop on the member's knowledge areas.
- line 30 creates a list item contain the knowledge area.
- line 31 ends the loop started on line 29
- line 32 is simply static content ending an unordered list.
- line 33 is simply static content ending a table cell.
- line 34 is simply static content ending a table row.
The remaining lines in the file close out the table body and the table itself.
---
You can see how the file will be dynamically generated at the time of building
the site, but the end result is a static site file.
#### file generation
To generate the files for the collections, we utilize ruby scripts, housed
within the `bin` folder. These scripts are used with GitLab CI/CD (see
[site generation](#site-generation)). The two main file generation files are
`build_skills_catalog.rb` and `convert_for_jekyll.rb`.
##### build_skills_catalog.rb
This script grabs all issue templates from the
[support-training repo](https://gitlab.com/gitlab-com/support/support-training)
via the GitLab API and then iterates on them. During each iteration, a file is
generated in the `_module-catalog` folder to create a module-catalog collection
file. The contents of the files generated will be the raw output from the API
request.
##### convert_for_jekyll.rb
This script is responsible for obtaining much of the collection data the Support
Team Page currently uses. A solid understanding of ruby will help in
understanding what all this does, but the basic gist is that it obtains the
needed data from various sources and creates collection files from it.
##### data folder
The data folder is a folder we store data files in, used in conjunction with the
file generation scripts (and many other projects, due to the sheer usefulness of
the files themselves). There are currently three files within the data folder:
- static_data.yaml - used to store static_data, such as oncall schedule IDs,
skill sets, etc.
- support-team.yaml - used to store information about each member of the support
team
- template.yaml - a template for adding new support team members
#### site generation
All the above is used in the site's actual generation. This is done using Jekyll
and GitLab Pages together. Via CI/CD, we [generate the files](#file-generation),
have Jekyll build the site into a `public` folder, and then store this folder as
an artifact (but only for the master branch). GitLab Pages will then use this
`public` folder to create a website, ie the
[Support Team page](https://gitlab-com.gitlab.io/support/team/).
## Change management
As the support team changes are unique in deployment, please see
[Support team page change management](/handbook/support/readiness/operations/docs/change_management#support-team-page-change-management)
for more information.
#### Labels to use
For all issues and MRs involving support team page changes, the label
`Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
All issues/MRs related to any of the non-data files of support team page will be
classified as either
[criticality 2](/handbook/support/readiness/operations/docs/change_criticalities#criticality-1)
or
[criticality 3](/handbook/support/readiness/operations/docs/change_criticalities#criticality-2)
All issues/MRs related to the data files of support team page will be
classified as
[criticality 4](/handbook/support/readiness/operations/docs/change_criticalities#criticality-4)
---
title: Triage bot
description: Support Operations documentation page for the triage bot
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/triage_bot"
---
## What is triage bot
Triage bot is the term we use for automation that utilizes the
[gitlab-triage gem](https://rubygems.org/gems/gitlab-triage) to perform various
tasks automatically.
## Triage bot policies
Triage bot utilizes policies to determine what actions to perform on what items.
Currently, the policies contain rules that can be used on epics, issues, and
merge requests.
Each policy contains rules for the resource set. These rules are contained
within an array that detail what to run on and what to actually do. Each of
these rules usually contains:
- `name` - the name for the rule
- `conditions` - the conditions the rule applies on
- `limits` - the limit to how many items can be grabbed at any time
- `actions` - the tasks to be done on items the rule applies to
### name
This is a simple string that gives the rule a name.
### conditions
This is used to dictate what items the rule will apply to. This can be a simple
set of conditions or a complex one, depending on your needs. There are many
types of conditions you can use. For more information, see the
[GitLab Triage repo](https://gitlab.com/gitlab-org/gitlab-triage).
### limits
This details any limits on the items found. Generally speaking, you will specify
what limit to use and the number of items to applies this to. The limits you can
use are:
- `most_recent` - Limits by the most recent items, using the `created_at` value
sorted in descending order.
- `oldest` - Limits by the oldest items, using the `created_at` value sorted in
ascending order.
As an example, to only apply on the 20 most recently created items:
```yaml
limits:
most_recent: 20
```
As another example, to only apply on the 40 oldest items:
```yaml
limits:
oldest: 40
```
### actions
This is where you specify what to do on the items found. There are many types of
actions you can use. For more information, see the
[GitLab Triage repo](https://gitlab.com/gitlab-org/gitlab-triage).
## How Support Ops uses triage bot
At 1200 UTC everyday, we run triage-bot via the
[Support Ops Project repo](https://gitlab.com/gitlab-com/support/support-ops).
This utilize the
[Support Ops triage policies](https://gitlab.com/gitlab-com/support/support-ops/support-ops-project/-/blob/master/.triage-policies.yml)
to perform various triage actions on issues and merge requests we work out of.
Generally speaking, we have rules for:
- Issues
- Find issues missing a category label
- Find issues missing a priority label
- Find issues missing a progress label
- Find issues missing a milestone
- Find issues that missed their milestone
- Find closed issues with incorrect progress label
- Merge requests
- Find MRs missing a category label
- Find MRs missing a priority label
- Find MRs missing a progress label
- Find MRs missing a milestone
- Find MRs that missed their milestone
- Find closed MRs with incorrect progress label
- Find merged MRs with incorrect progress label
## Useful links
- [gitlab-triage gem](https://rubygems.org/gems/gitlab-triage)
- [GitLab Triage repo](https://gitlab.com/gitlab-org/gitlab-triage)
- [Support Ops triage policies](https://gitlab.com/gitlab-com/support/support-ops/support-ops-project/-/blob/master/.triage-policies.yml)
---
title: Usage ping requests
description: Support Operations documentation page for usage ping requests
canonical_path: "/handbook/support/readiness/operations/docs/gitlab/usage_ping_requests"
---
## What is the usage ping request form?
The usage ping request form is a simple HTMl form generated via GitLab Pages
that is sent to [Zapier](https://zapier.com/app/zap/125573569) for processing.
The source code for it is located
[here](https://gitlab.com/gitlab-com/support/support-ops/forms/usage-ping-request-form).
## How does it all work?
The usage ping request form, when submitted, sends an AJAX request to
[Zapier](https://zapier.com/app/zap/125573569). This then runs python code
within the zap itself.
<details>
<summary>Python code in zap</summary>
```python
import requests
def body(hostname, email):
message = "To whom it may concern,\n\n" \
"I am requesting the deletion of usage ping data related to the hostname of my GitLab instance: `%s`.\n\n" \
"Thank you." % (hostname)
return message
def subject(hostname):
message = "Usage ping request - %s" % hostname
return message
email = input_data['email']
hostname = input_data['hostname']
url = 'https://api.mailgun.net/v3/mg.gitlab.com/messages'
files = {
'from': (None, 'techsupport@gitlab.com'),
'to': (None, 'incoming+gitlab-com-usage-ping-request-27544965-issue-@incoming.gitlab.com'),
'subject': (None, subject(hostname)),
'text': (None, body(hostname, email)),
'h:Reply-To': (None, email),
}
requests.post(url, files=files, auth=('api', input_data['mailgun_key']))
```
</details>
The zap will create an issue in the
[Usage Ping Request project](https://gitlab.com/gitlab-com/usage-ping-request)
via service desk.
## Change management
As these are maintained via sync repositories, our standard change management
process applies to all usage ping request changes. See
[standard change management](/handbook/support/readiness/operations/docs/change_management#standard-change-management)
for more information.
#### Labels to use
For all issues and MRs involving usage ping request form changes, the label
`Support-Ops-Category::Forms` should be used.
For all issues and MRs involving usage ping request processor changes, the label
`Support-Ops-Category::GitLab Projects` should be used.
#### Change criticality
All issues/MRs related to any of the components of usage ping request will be
classified as either
[criticality 3](/handbook/support/readiness/operations/docs/change_criticalities#criticality-1)
or
[criticality 4](/handbook/support/readiness/operations/docs/change_criticalities#criticality-2)
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment