Rollback стратегії для AI-агентів: як безпечно відкотити реліз

Ідея за 30 секунд

Rollback стратегії — це runtime-механізм швидкого повернення трафіку на стабільну версію, коли новий реліз деградує метрики.

Коли це потрібно: коли агент релізиться через canary/rollout і будь-яка регресія в production має зупинятись без довгого downtime.

Проблема

Без rollback команда бачить проблему, але не може швидко прибрати її вплив. Поки триває аналіз, трафік іде на деградовану версію, а інцидент росте.

Типовий сценарій:

• росте error_rate або latency_p95
• користувачі продовжують потрапляти на проблемну версію
• команда робить ручні дії під тиском часу

Аналогія: це як не мати аварійного гальма. Коли система вже пішла в занос, повільна реакція коштує набагато дорожче, ніж саме виправлення.

І кожна хвилина без rollback додає нові помилки, витрати і втрату довіри.

Рішення

Рішення — зробити rollback окремим policy-рівнем у runtime release flow. Policy перевіряє сигнали деградації і вирішує: продовжувати rollout чи повертати трафік на stable version.

Rollback policy layer повертає технічне рішення: allow або stop з причиною:

• rollback_required
• sla_breach
• error_spike

При stop система виконує керований traffic switch на active stable version і фіксує подію в audit log. Це окремий аварійний контроль, а не ручна імпровізація в момент інциденту.

Rollback ≠ kill switch

Це різні інструменти:

• Rollback повертає на попередню стабільну версію.
• Kill switch зупиняє дії або трафік без зміни версії.

Одне без іншого не працює:

• без rollback важко відновити нормальну роботу після регресії релізу
• без kill switch складно швидко "притиснути" ризикові дії до завершення rollback

Приклад:

• rollback: 2.4.0 -> 2.3.3 після error_spike
• kill switch: тимчасово writes_disabled=true, поки повертається stable version

Компоненти rollback-контролю

Ці компоненти працюють разом під час кожного rollout.

Приклад alert:

Slack: 🛑 Rollback triggered support-agent@2.4.0 -> 2.3.3, reason=error_spike, stage=canary.

Як це виглядає в архітектурі

Rollback policy layer стоїть між release runtime і трафіком та блокує деградований rollout до його масштабування. Кожне рішення (allow або stop) фіксується в audit log.

Кожен етап rollout проходить через цей flow перед розширенням трафіку: runtime не масштабує candidate напряму, а передає рішення policy layer.

Коротко по flow:

• Моніторинг дає сигнал деградації
• Policy перевіряє error_rate, latency_p95, tool_failures, rollback_plan
• allow -> rollout триває
• stop -> трафік перемикається на active stable version
• обидва рішення пишуться в audit log

Приклад

Після релізу support-agent@2.4.0 росте tool_failure_rate у canary. Rollback policy повертає stop (reason=rollback_required).

Результат:

• трафік повертається на 2.3.3
• candidate блокується для подальшого розширення
• команда розбирає причину вже без активного інциденту

Rollback зменшує збиток під час інциденту, а не після того, як він масштабувався.

У коді це виглядає так

У спрощеній схемі вище показано основний flow. Критично: rollback має бути ідемпотентним і швидким, щоб повторний сигнал не зламав traffic switch.

Приклад rollback-конфігурації:

rollback:
  stable_version: support-agent@2.3.3
  candidate_version: support-agent@2.4.0
  triggers:
    error_rate_p95: 0.05
    latency_p95_ms: 1800
    tool_failure_rate: 0.03
  lock_candidate_after_rollback: true

release_cfg = load_release_config("support-agent")
signal = monitor.read(version_id=release_cfg.candidate_version)
decision = rollback_policy.check(signal, release_cfg)

if decision.outcome == "stop":
    switch_result = traffic.switch(
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

    if release_cfg.lock_candidate_after_rollback:
        rollout.lock(version_id=release_cfg.candidate_version)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
        switch_status=switch_result.status,
    )
    alerts.notify_if_needed(release_cfg.candidate_version, decision.reason)
    return stop(
        decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

allow_decision = Decision.allow(reason=None)  # standard allow outcome/reason model
audit.log(
    run_id,
    decision=allow_decision.outcome,
    reason=allow_decision.reason,
    version_id=release_cfg.candidate_version,
    stage="canary",
)
return continue_rollout()

Як це виглядає під час виконання

Сценарій 1: rollback_required у canary

1. Candidate версія отримує 5% трафіку.
2. Метрики порушують пороги (error_rate і tool_failure_rate).
3. Policy повертає stop (reason=rollback_required).
4. Трафік повертається на stable version.
5. Candidate блокується до розбору інциденту.

Сценарій 2: false alarm, rollback не потрібен

1. Моніторинг дає короткий сплеск, але пороги не порушені.
2. Policy повертає allow.
3. Rollout триває на поточному stage.
4. Подія записується в audit log.
5. Система лишається стабільною без зайвого rollback.

Сценарій 3: повторний сигнал після rollback

1. Після відкату приходить ще один alert із тим самим сигналом.
2. Ідемпотентна логіка не робить повторний switch.
3. Policy повертає технічний статус без дублю дій.
4. У логах видно, що rollback вже застосовано.
5. Команда працює над root cause без додаткового шуму.

Типові помилки

• rollback запускається тільки вручну без policy-тригерів
• немає stable version, на яку можна швидко повернутись
• відсутній lock candidate після rollback
• rollback робить switch, але не перевіряє recovery метрики
• немає idempotency для повторних rollback сигналів
• в audit log не пишеться from/to version і reason

У результаті rollback ніби є, але в інциденті працює повільно і непередбачувано.

Самоперевірка

Швидка перевірка rollback стратегії перед запуском у production:

FAQ

Q: Коли запускати rollback автоматично, а коли вручну?
A: Для чітких SLO-порогів краще автоматично. Для неоднозначних кейсів (наприклад, ризикована бізнес-операція) — human approval поверх policy.

Q: Rollback і kill switch дублюють одне одного?
A: Ні. Rollback повертає стабільну версію, а kill switch швидко обмежує дії. У production ці механізми мають працювати разом.

Q: Що робити після rollback?
A: Зафіксувати incident snapshot (версія, reason, метрики), заблокувати candidate, і запускати повторний rollout тільки після виправлення і перевірки.

Q: Чи потрібен rollback, якщо є canary?
A: Так. Canary лише зменшує blast radius, але rollback потрібен, щоб швидко повернути систему в стабільний стан.

Q: Які поля обов'язково логувати?
A: reason, from_version, to_version, stage, switch_status, timestamp, actor (якщо rollback manual).

Де Rollback у загальній системі

Rollback стратегії — це один із рівнів Agent Governance. Разом із versioning, лімітами, бюджетами, approval і audit вони формують систему безпечних змін у production.

Пов'язані сторінки

Далі за темою:

• Огляд Agent Governance — загальна модель контролю агентів у production.
• Agent Versioning — як керувати змінами prompt/tools/policy до rollback.
• Kill switch — як миттєво обмежити дії під час інциденту.
• Rate limiting для агентів — як стримувати піки під час деградації.
• Audit logs для агентів — як відновлювати ланцюг rollback-рішень.