GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsGitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsOnce a quarter, Support Operations is to conduct audits on all the tech stacks we manage. These currently include:
All of these are conducted via issues in the support-ops/audits project.
These are done and tracked via the Zendesk Issue Template.
This is a more complex audit, requiring a lot of checking and following up. To start, run this script. It will take a considerable amount of time, but reduce a good portion of the work required on your part. Use the output to fill out the notes section of the issue you generated.
From there, you need to go through the items reported and ping the person in the issue to ask for the issue to be fixed (or clarify if this is intentional). This can take time, so wait about 72 hours after pinging someone before following back up. If the issue is not addressed within a week, ping that person's manager.
After that, you need to review the API tokens currently in use. The script above will output the basic details of what to put into the issue. You will need to fill it out and seek out the maintainer/requester of the API token to enter the justification/use case. This can take time, so wait about 72 hours after pinging someone before following back up. If the issue is not addressed within a week, ping that person's manager.
These are done and tracked via the Zendesk Issue Template.
This is a more complex audit, requiring a lot of checking and following up. To start, run this script. It will take a considerable amount of time, but reduce a good portion of the work required on your part. Use the output to fill out the notes section of the issue you generated.
From there, you need to go through the items reported and ping the person in the issue to ask for the issue to be fixed (or clarify if this is intentional). This can take time, so wait about 72 hours after pinging someone before following back up. If the issue is not addressed within a week, ping that person's manager.
After that, you need to review the API tokens currently in use. The script above will output the basic details of what to put into the issue. You will need to fill it out and seek out the maintainer/requester of the API token to enter the justification/use case. This can take time, so wait about 72 hours after pinging someone before following back up. If the issue is not addressed within a week, ping that person's manager.
These are done and tracked via the Calendly Issue Template.
As the API is not yet able to handle this, this process will be a bit more of a manual process. To starter, you will need will first make an audit issue via the Calendly Issue Template.
After doing so, you will want to run this script. Use the output to fill out the notes section of the issue you generated.
From there, you need to go through the items reported and ping the person in the issue to ask for the issue to be fixed (or clarify if this is intentional). This can take time, so wait about 72 hours after pinging someone before following back up. If the issue is not addressed within a week, ping that person's manager.
After that, you need to go into calendly and confirm who is and isn't there. It helps to make a list of who all is in the Calendly group and then correlate it to what the script outputed. Any users in Calendly but not outputted from the script need to be noted and we will need confirmation of why they are in there. If no justifcation can be made, they will need to be removed.
These are done and tracked via the Pagerduty Issue Template.
This is a simpler audit, since it is mostly just checking for valid IDs and schedules. As this doesn't require much human interaction, it is largely scripted.
To do these, first make an audit issue via the Pagerduty Issue Template. Then run this script. Use the output to fill out the notes section of the issue you generated.
From there, you need to go through the items reported and ping the person in the issue to ask for the issue to be fixed (or clarify if this is intentional). This can take time, so wait about 72 hours after pinging someone before following back up. If the issue is not addressed within a week, ping that person's manager.
Once all that has been done, ping the Support Operations Manager for review.