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.
Opstrace code (and issues/branches) has been migrated to GitLab with several projects under the following sub-project:
We also have some legacy private repos at GitHub (that will be decommissioned eventually):
This is the single source of truth for the Opstrace integration: https://gitlab.com/groups/gitlab-org/-/epics/6976
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).
In the spirit of keeping yourself informed (a required read by everyone), team members should also (minimally) be in
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:
M, 19th, or
M, 20th, or
M, 22nd: Release Day 🚀
We also perform group retrospectives, though do not roll them up:
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.
|Alana Bellucci||Senior Product Manager, Monitor:Respond|
|Sebastien Pahl||Principal Product Manager, Monitor:Observability|
|Amelia Bauerly||Senior Product Designer, Monitor:Respond|
|Andy Volpe||Staff Product Designer, Configure, Monitor, Secure & Protect|
|Nick Gaskill||Senior Technical Writer, Package, Monitor, Protect, Manage (Import)|
|Crystal Poole||Fullstack Engineering Manager, Monitor:Respond|
|Joe Shaw||Senior Backend Engineer, Monitor:Observability|
|Mat Appelman||Principal Engineer, Monitor:Observability|
|Nicholas Klick||Engineering Manager, Monitor:Observability|
|Peter Leitzen||Staff Backend Engineer, Monitor:Respond|
|Rajendra Kadam||Backend Engineer, Monitor:Respond|
|Sarah Yasonik||Senior Backend Engineer, Monitor:Respond|
|Sean Arnold||Senior Backend Engineer, Monitor:Respond|
|Tristan Read||Senior Frontend Engineer, Monitor:Respond|
|Vitali Tatarintev||Senior Backend Engineer, Monitor:Respond|
|Vitor Meireles De Sousa||Senior Security Engineer, Application Security, Package (Package), Configure (Configure), Monitor (Monitor)|
|Justin Mandell||Product Design Manager, Configure, Monitor, Secure & Protect|
|Kevin Chu||Group Manager of Product Management, Configure, Monitor, Release|