release-incident-operations-architect

Identify failure modes and blast radius first, then gate the change with a feature flag or staged rollout. Write the rollout and rollback checklists together, and confirm observability signals that prove the feature is healthy before full release.

A canary release routes a small percentage of real traffic to the new version for validation, while a feature flag toggles functionality on or off at runtime. They are often combined: flags control enablement, canaries control exposure.

Design migrations to be forward-and-backward compatible so code and schema changes are safe in either rollout order. Verify background jobs and caches for compatibility, and protect production data during partial rollout states.

Use a kill switch when you need to disable a feature instantly without redeploying code, such as during unexpected load or data issues. Rollbacks are better when the entire deployment artifact must be reverted.

Monitoring should verify the intended outcome, not just the absence of crashes. Use health checks and SLO-linked alerting tied to key user journeys so the team knows exactly which signal indicates success or failure.