Advocacy and Constructive Dissent Questions

Situation: In a weekly reliability sync, the backend lead proposed deploying a DB schema migration that required a brief but blocking migration window during peak traffic late that day to meet a product deadline.

Task: As the SRE on-call owner for the service, I needed to prevent an outage risk while keeping the release timeline reasonable.

Action:

• I started by clarifying: “Help me understand the rollback plan and traffic profile during that window.”
• I presented concise evidence: recent CPU and connection metrics showing 35% higher traffic at that time, the last two migrations’ latency spikes from APM traces, and our runbook which flags any blocking migration during high QPS as high-risk.
• I proposed a lower-risk alternative: split the migration into two non-blocking steps, deploy a schema-first change with backward-compatible code, and run a controlled canary during a low-traffic hour. I offered to own the canary and provided a short checklist (alerts to mute, health checks, rollback SQL).
• I acknowledged the product urgency and suggested a trade-off timeline that moved the final blocking step to the next low-traffic window.

Result: The team agreed to the staged approach. We ran the canary, observed no regressions, and completed the final step off-peak with zero customer impact. The product shipped with a one-day delay. Afterward we added a migration checklist to the runbook and scheduled migrations into the release calendar.

Learning: Respectful disagreement works best when backed by measured evidence, clear alternatives, willingness to take responsibility, and empathy for competing priorities.