Monitor:Observability Group

1. You are here:
2. Engineering
3. Development Department
4. Ops Sub-department
5. Monitor Stage
6. Monitor:Observability Group

Maintained by:

On this page

• On this page
• Monitor:Observability
• Code
• Integration milestones
  • SLA
• Communication
• Planning
• Tracking work in issues
• Team members
• Stable counterparts

Monitor:Observability

The Monitor:Observability group at GitLab is responsible for building tools that enable DevOps teams to respond to, triage and remediate errors and IT alerts for the systems and applications they maintain. Based on the recent Opstrace acquisition, we aim to provide a streamlined Operations experience within GitLab that enables the individuals who write the code, to maintain it at the same time.

Code

Opstrace code (and issues/branches) has been migrated to GitLab with several projects under the following sub-project:

• https://gitlab.com/gitlab-org/opstrace/

We also have some legacy private repos at GitHub (that will be decommissioned eventually):

• https://github.com/opstrace/next-website/ (our current website)
• https://github.com/opstrace/opstrace-prelaunch/ (pre-open source code and issues)
• https://github.com/opstrace/private/ (customer-related issues)

Integration milestones

This is the single source of truth for the Opstrace integration: https://gitlab.com/groups/gitlab-org/-/epics/6976

SLA

The expected SLA for these "integration milestones" will be best effort. That is, we will not have a 24x7 on-call rotation with any published response time. Instead, we will do our best to keep the system available and reliable as we focus on the development work (defined in the integraiton milestones) to ship features to our early adopters. After the integration milestones are complete, we will work together to decide how to best provide a published SLA, such as working with the Infrastructure team to operate our service for GitLab.com with an associated escalation policy to us in Development (similar to what exists today).

Communication

• Slack channel: #g_observability

In the spirit of keeping yourself informed (a required read by everyone), team members should also (minimally) be in #development, #ops-section and #s_monitor.

Planning

For the first 6-9 months, our goals are entirely driven by the bi-monthly acquisition milestones.

To accomplish these, we align our work loosely with the GitLab product development timeline. In particular, we define our Milestones to ship on the 22nd of the month.

We use GitLab milestones to track our work. All work being done for one of the integraiton milestones should have this milestone set.

We also adopt the "code freeze" by the 17th:

• On M, 19th, or M, 20th, or M, 21st:
  • Milestone Cleanup runs on the schedule at Milestone cleanup schedule
• On month M, 22nd: Release Day 🚀
  • Release deployed to production.
  • Release published—including docs and blog.

We also perform group retrospectives, though do not roll them up:

• On or around M, 19th:
  • Group Retrospectives should happen so they can inform the public retrospective summary and discussion

Tracking work in issues

In addition to adding the aforementioned milestone to our issues, we also adopt workflow labels:

• workflow::in dev: A developer indicates they are developing an issue by applying the in dev label.
• workflow::in review: A developer indicates the issue is in code review by removing the in dev label, and applying the in review label.
• workflow::verification: A developer indicates that all the development work for the issue has been done and is waiting to be deployed.

Team members

Stable counterparts