Rollback и shadow-деплой

Две страховки для релизов: мгновенный откат назад и теневая проверка вперёд.

Rollback — быстрый возврат к предыдущей версии модели при проблеме; shadow-деплой — параллельный прогон новой модели на реальном трафике без влияния её ответов на пользователя.

Rollback: план отступления

Любой релиз может пойти не так. Rollback — это заранее готовая возможность за секунды вернуть прод-трафик на прошлую, проверенную версию. Благодаря реестру моделей это не пересборка, а смена указателя: сервис снова берёт предыдущую Production-версию.

client = mlflow.MlflowClient()
# вернуть прошлую версию в Production
client.transition_model_version_stage(
    name="fraud-detector", version=6, stage="Production",
    archive_existing_versions=True,  # проблемную v7 -> Archived
)

Чтобы rollback был быстрым, нужны: версионированные модели в реестре, идемпотентный деплой и предсказуемость старой версии (её артефакт и образ сохранены). Если старую модель «потёрли», откатываться будет некуда.

Shadow-деплой: проверка без риска

Новую модель ставят рядом и кормят тем же боевым трафиком, но её ответы не доходят до пользователя — их только логируют и сравнивают с текущей. Это позволяет оценить новую модель на настоящем распределении запросов до того, как доверить ей реальные решения.

запрос --> [модель v6] --> ответ пользователю (реальный)
       \--> [модель v7] --> ответ только в лог (теневой)
                 |
       сравниваем v7 vs v6 на боевом трафике, риска ноль

Когда что использовать

Часто это конвейер: сначала shadow (риск ноль), потом канарейка (малый риск), и всегда наготове rollback.

Что даёт shadow, чего не даёт офлайн-валидация

Офлайн-валидация проверяет модель на историческом наборе. Shadow — на живом, текущем трафике, включая редкие и новые случаи, которых в валидации не было. Он ловит проблемы интеграции (форматы, латентность, ошибки на реальных входах), а не только качество. Минус: shadow тратит ресурсы (две модели считают каждый запрос) и не измеряет влияние на пользователя (ответы-то теневые).

Как работает под капотом

Shadow реализуют асинхронным дублированием: основной путь отвечает пользователю синхронно, теневой вызов уходит параллельно (часто неблокирующе, чтобы не повышать латентность ответа) и пишет результат в лог. Сравнение v7 и v6 идёт офлайн по логам: где расходятся, насколько, нет ли у новой версии всплесков ошибок или латентности. Rollback опирается на реестр и неизменность старого артефакта: переключение стадии атомарно, поэтому возврат мгновенный.

Частые ошибки

• Нет плана rollback. Без готового отката инцидент затягивается на часы паники.
• Удалять старые версии/образы. Тогда откатываться некуда.
• Делать shadow синхронно блокирующим. Теневой вызов не должен увеличивать латентность реального ответа.
• Считать shadow заменой A/B. Shadow не измеряет влияние на пользователя — для этого нужен живой трафик с реальными ответами.

Итог

• Rollback — заранее готовый мгновенный возврат к прошлой версии через смену стадии в реестре.
• Shadow-деплой прогоняет новую модель на боевом трафике без влияния на пользователя — проверка с нулевым риском.
• Безопасный релиз: shadow → канарейка → полный выкат, с rollback наготове; старые артефакты не удаляют.