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
Kennedy Wanyangu	Engineering Manager, Scalability:Practices
Senior Site Reliability Engineer	Senior Site Reliability Engineer
Chance Feick	Senior Backend Engineer
Senior Site Reliability Engineer	Senior Site Reliability Engineer
Florian Forster	Staff Site Reliability Engineer, Scalability
Furhan Shabir	Senior Site Reliability Engineer, Systems:Gitaly
Gonzalo Servat	Senior Site Reliability Engineer
Rehab Hassanein	Site Reliability Engineer
Sylvester Chin	Backend Engineer, Scalability

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
  • Fulfillment Platform Group / CustomerDot - Linked Issue
  • Runner Group - Linked Issue
  • Product Analytics Group - Linked Issue
• 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

1. Scalability:Practices Epic Board
2. Scalability:Practices Issue Board
3. Scalability:Practices Issues not in an Epic
4. 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:

1. Scalability:Practices Build Board
2. Scalability:Practices Planning Board
3. Runway Build Board
4. 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.