Make rollback a
known decision.
A conservative pre-launch guide for defining a reversible response to unexpected release behavior. It does not instruct anyone to alter production without the team’s own authorization and safeguards.
USE IT TO: Use before release to identify a scoped rollback route, its decision authority, and customer-path checks after an approved action.
Work the next known step.
- Before release, record the release identifier, the smallest reversible unit, the authorization owner, and the approved mechanism already available to the team.
- Use staged rollout and supervision where the team’s platform supports it. Pause when observed behavior exceeds the team’s own agreed boundary.
- Capture the observation, timing, scope, and active release identifier before an approved rollback. Do not substitute a broad destructive action for a scoped reversal.
- After the approved action, verify the primary customer paths, communicate only confirmed facts, and preserve evidence for a later review.
Confirm the rollback route is documented against the exact release mechanism, not a remembered previous workflow.
Review any irreversible migration or external change with its owner before release.
Run an approved dry-run or tabletop exercise where possible; record findings without making production changes.
Source notes, not borrowed certainty.
Planning basis: Google SRE production-service practices
- Google SRE Book — Production service best practices ↗The guidance recommends supervised progressive rollouts and rolling back first when unexpected behavior is detected, then diagnosing to reduce recovery time.
Authorship: SIU Enablement editorial draft; source-bounded operational guidance. Reviewed by: Release owner, platform owner, and data owner review required before use. Revalidate: Revalidate before material release-process, migration, hosting, or provider changes.