@@ -105,7 +105,9 @@ These are changes with high impact or high risk. If a change is going to cause d
1. Ensure there is Due Date set on the issue and to the [GitLab Production](https://calendar.google.com/calendar/embed?src=gitlab.com_si2ach70eb1j65cnu040m3alq0%40group.calendar.google.com) calendar.
1. Plannable C1s - including but not limited to proactive maintenance, scheduled upgrades, and planned infrastructure changes - require a minimum 2-week lead time to ensure proper stakeholder notification.
1. Changes which include downtime must be pre-communicated to users. Follow the guidance for [Communicating a change that requires downtime](/handbook/engineering/infrastructure-platforms/change-management/#communicating-a-change-that-requires-downtime-maintenance-window)
1. All the database changes related should have a review by a DBRE.
1. Database changes require a review from the appropriate expert depending on the type of change:
-**Database service changes** (infrastructure, configuration, replication, backup strategy, etc.) must have a review by a DBRE.
-**Database model changes** (migrations, schema changes, data model modifications, etc.) are application-layer changes and must have a review by a DB Maintainer (Backend Engineer) with expertise in the relevant area.
1. Have the change approved by Infrastructure Platform Leadership (EM+ or Staff+ ICs in Infrastructure Platforms) by obtaining the `platform_leadership_approved` label on the Change Request issue. Mention `@gitlab-org/saas-platforms/change-review-leadership` to request approval.The reviewer should be from a different team than the change author. Review the [Platform Leadership Review Guidelines](platform-leadership-review/) before approving.
1. Identify the Engineer On-Call (EOC) scheduled for the time of the change and make them aware of the change plan as soon as it is scheduled.
(The source is [incident.io](https://app.incident.io/gitlab/on-call/schedules/01K5YWAGZ7YCQGAG7ATQ9XQWHW), if you don't have access try [getting assistance](/handbook/engineering/infrastructure/team/))
@@ -138,7 +140,9 @@ These are changes that are not expected to cause downtime in Production, but whi
1. Ensure there is a Due Date to the issue and an event to the [GitLab Production](https://calendar.google.com/calendar/embed?src=gitlab.com_si2ach70eb1j65cnu040m3alq0%40group.calendar.google.com) calendar.
1. Changes which include downtime must be pre-communicated to users. Follow the guidance for [Communicating a change that requires downtime](/handbook/engineering/infrastructure-platforms/change-management/#communicating-a-change-that-requires-downtime-maintenance-window)
1. All the database changes related should have a review by a DBRE.
1. Database changes require a review from the appropriate expert depending on the type of change:
-**Database service changes** (infrastructure, configuration, replication, backup strategy, etc.) must have a review by a DBRE.
-**Database model changes** (migrations, schema changes, data model modifications, etc.) are application-layer changes and must have a review by a DB Maintainer (Backend Engineer) with expertise in the relevant area.
1. Have the change approved by Platform Leadership (Staff+ SREs, Principal Engineers, or Senior Staff Engineers) by obtaining the `platform_leadership_approved` label on the Change Request issue. Mention `@gitlab-org/saas-platforms/change-review-leadership` to request approval. The reviewer should be from a different team than the change author. Review the [Platform Leadership Review Guidelines](platform-leadership-review/) before approving.
1. Identify the Engineer On-Call (EOC) scheduled for the time of the change and review the plan with them.
(The source is [incident.io](https://app.incident.io/gitlab/on-call/schedules/01K5YWAGZ7YCQGAG7ATQ9XQWHW), if you don't have access try [getting assistance](/handbook/engineering/infrastructure/team/))
