تحديد معايير التراجع التلقائي

At 3 a.m. nobody is watching dashboards. Automatic rollback lets the system itself revert a bad model the moment it crosses a danger line. 🚨

A rollback rule needs a measurable guardrail metric, like error rate or p99 latency, with a number that clearly means trouble.

Turn vague worry into a concrete limit. For example, roll back if the canary error rate exceeds 2% over the measurement window.

Absolute limits miss slow regressions. Also roll back if the canary is clearly worse than the champion, say 20% higher latency on the same traffic.

Judge metrics over a rolling window, like the last 5 minutes. One unlucky request should never trigger a full rollback by itself.

A 100% error rate over three requests means nothing. Require a minimum sample size before any metric is allowed to fire a rollback.

The check is just a comparison: if the live metric breaches its limit, return a rollback signal for the orchestrator to act on.

A model can be fast and error-free yet still tank conversions. Guard the outcomes that matter, not only the technical health signals.

Rollback should be one fast, safe step: flip traffic back to the proven champion. Keep that previous version warm and ready to take over.

Automation handles the emergency stop, but it must notify the team too. An auto-rollback should page someone to investigate the root cause.

Do not auto-redeploy the same failing model right after rollback. Freeze the rollout until a human reviews, so it cannot flap back and forth.

Which design choice keeps rollback rules trustworthy?

Good rollback criteria use clear thresholds over a fair window with enough traffic, compare to the champion, alert a human, and revert fast. ✅