Scalability:Practices Team
Mission
We enable GitLab services to operate at production scale by providing paved roads for onboarding and maintaining features and services.
Common Links
| Workflow | Team workflow |
| GitLab.com | @gitlab-org/scalability/practices |
| Issue Trackers | Scalability |
| Team Slack Channels | #g_scalability-practices - Team channel #scalability_social - Group social channel |
| Information Slack Channels | #infrastructure-lounge (Infrastructure Group Channel), #incident-management (Incident Management), #alerts-general (SLO alerting) |
Team Members
The following people are members of the Scalability:Practices team:
| Name | Role |
|---|
Responsibilities
- Runway: Internal Platform as a Service for GitLab, enabling teams to deploy and run their services quickly and safely.
- Production Readiness Review: A process that helps identify the reliability needs of a service, feature, or significant change to infrastructure for GitLab.com
- Specific Counterparts Arrangements: Enabling specific stage group counterparts to self-serve on SRE support. Currently we are Infrastructure counterparts for the Stage groups
- Redis
- Sidekiq
- Participation in SRE on-call rotation
How We Work
Communication
- Slack Updates: Regular status updates in #g_scalability-practices Slack channel with no strict update frequency
- Scheduled Calls: Working async is our preferred and default way of communication. We also have a weekly group call for synchronous discussions on any open questions that async discussions did not cover
Project Management
Refer to Scalability Group’s Project Management Section for details on how we manage projects particularly the project ownership and project structure
Project Management Links: Scalability:Practices Team Level
- Scalability:Practices Epic Board
- Scalability:Practices Issue Board
- Scalability:Practices Issues not in an Epic
- Scalability:Practices Issues by Team Member
Issue management
Our work is collaborative across teams and we mainly operate from the scalability issue tracker. We work from our main epic: Scaling GitLab’s SaaS Platforms.
Labels
All issues pertaining to our team have the ~"team::Scalability-Practices" label.
All issues that are within scope of current work have a ~board::build or ~board::planning label.
All issues require either a Service label or the team-tasks, discussion, or capacity planning labels.
Assignees
We use issue assignments to signal who is the DRI for the issue. We expect issue assignees to regularly update their issues with the status, and to be as explicit as possible at what has been done and what still needs to be done. We expect the assignee of an issue to drive the issue to completion. The assignee status typically expresses, that the assigned team member is currently actively working on this or planning to come back to it relatively soon. We unassign ourselves from issues we are not actively working on or planning to revisit in a few days.
Boards
The Scalability::Practices uses issue boards as guided in Scalability group issue boards section to track the progress of ongoing work.
The specific Scalability::Practices boards are:
- Scalability:Practices Build Board
- Scalability:Practices Planning Board
- Runway Build Board
- Runway Planning Board
Counterpart Arrangements
The specific counterparts arrangements can request for SRE support through the following steps:
- Create an issue using the counterpart issue template in the Scalability tracker. The title of the issue should be a descriptive goal of the engagement.
- Follow the checklist in the template.
af33af46)
