Skip to content

Move GL Self-Monitoring to Enablement

Kevin Chu requested to merge self-monitoring-to-enablement into master

GitLab self-monitoring is meant to enable self-hosted GitLab administrators with the tools to operate GitLab by surfacing the health of the GitLab instance, alerting on issues that need to be resolved, and enabling triage and resolutions to problems. The former Monitor APM team made significant progress, creating the GitLab Instance group and Monitoring project. However, the vision for the GitLab Instance group expands far beyond Monitoring categories (Runbooks, Instance Usage, Instance Incidents, WAF, Load Times). As such, it belongs to the Enablement section, whose mission is to provide the features and tools our customers use to operate GitLab at all scales (in this case leveraging many of the same capabilities we provide our customers to operate their own applications).

Since the Monitoring section, specifically, the APM group was recently disbanded, there is no longer any relevant domain expertise. The former engineering team members will follow the engineering handbook's collaboration for ongoing development.

Proposed solution

Shift Self-Monitor category to Enablement, but leave it in "Other functionality" for now and not attached to a group. This is because there is no current group in Enablement which makes sense to shift this to, even though the stage is aligned.

This change at least aligns the category to the stage vision, even though neither stages are positioned to drive this category forward without additional staffing.

To resolve the staffing problem, Enablement is planning to propose a new group to include this functionality for FY22, tentatively titled 'Instance Group'. Given how close we are to FY22 planning, it makes sense to hold this in "Other functionality" for now. If we end up not funding this group, we would need to consider the alternatives.

Alternatives

  • Shift to Manage.
  • Remove the category, and let this functionality become part of the shared responsibility of all groups

Approvals

Merge requests with changes to stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:

The following people need to be on the merge request so they stay informed:

  • EVP of Engineering @edjdev
  • VP of Development @clefelhocz1
  • Director of Quality @meks
  • The Product Marketing Manager relevant to the stage group(s)
Edited by Chun Du

Merge request reports