Provider Failover Policy в 2026: когда переключать провайдера, а когда лучше остановиться

Короткая версия

Хорошая failover policy в 2026 обычно задаёт:

1. Compatibility pools
2. Явные trigger conditions
3. Quarantine для плохих secondary paths
4. Failback через canary, а не сразу на весь трафик
5. Отдельные правила для high-risk lanes

Что особенно важно

• failover только внутри совместимого lane;
• проверка schema/tool compatibility заранее;
• логирование why_failed_over;
• отключение dangerous automation, если совместимого fallback нет.

Primary route для support workflow использует strict JSON schema и tool calling. Можно ли при ошибке переключить его на провайдера без совместимого tool behavior?

1. Failover начинается с compatibility pools

Самое полезное practical правило: провайдеры должны быть сгруппированы не "по брендам", а по совместимости с конкретным lane.

Например:

• structured support lane;
• cheap FAQ lane;
• premium reasoning lane;
• tool-using agent lane.

Внутри каждого pool должны быть заранее проверены:

• output schema;
• tool support;
• context limits;
• refusal patterns;
• cost and latency envelope.

Только тогда failover становится управляемым, а не хаотичным.

2. Trigger conditions должны быть явными

Полезно различать причины failover:

• outright outage;
• repeated 5xx;
• severe latency breach;
• rate-limit saturation;
• schema invalid spike;
• tool execution mismatch.

Это важно, потому что разные причины требуют разных реакций:

• при outage можно идти на secondary;
• при schema drift лучше остановить lane;
• при budget saturation лучше model downgrade;
• при latency burst иногда лучше queue-first path.

3. Semantic compatibility важнее API compatibility

Даже если два провайдера оба принимают JSON и messages, они всё равно могут различаться там, где это реально больно:

• по strictness structured outputs;
• по склонности к refusals;
• по tool selection behavior;
• по длине и стилю ответов;
• по handling edge cases.

Именно здесь blind failover часто ломает production:

• parser принимает формат, но downstream semantics другие;
• tool lane начинает вызывать не те actions;
• policy-sensitive ответы становятся мягче или жёстче;
• citation coverage silently падает.

4. Quarantine нужен для secondary routes не меньше, чем для primary

После переключения secondary path тоже нужно уметь быстро изолировать.

Когда quarantine полезен:

• выросла schema invalid rate;
• пошли repeated tool mismatches;
• резко упала judge-score на sampled traffic;
• secondary route дал wrong-policy behavior.

Без quarantine secondary path часто продолжает quietly портить трафик дольше, чем primary outage вообще длился.

5. Failback должен идти через canary

Когда primary возвращается, не стоит сразу возвращать на него весь трафик.

Более зрелый путь:

1. small canary back to primary;
2. проверка latency, schema, tool behavior;
3. gradual restoration;
4. post-incident comparison.

Это особенно важно после нестабильных инцидентов, где root cause ещё не до конца подтверждён.

6. Что делать, если совместимого fallback нет

Это самый неприятный, но важный сценарий.

Вместо слепого failover лучше:

• partial service;
• async queue;
• stale cache для low-risk;
• propose-only mode;
• manual handoff;
• honest refusal.

Именно здесь failover policy пересекается с graceful degradation.

7. Что чаще всего ломают команды

Один общий fallback list

Все lanes падают в один и тот же secondary provider.

Нет semantic checks

Смотрят только transport success и 200 OK.

Failover without observability

Команда не знает, сколько трафика уже ушло на fallback path.

No failback discipline

После инцидента весь трафик резко возвращают на primary без canary.

Mixed risk buckets

High-risk automation и low-risk FAQ используют один и тот же policy.

8. Какие метрики полезны

Минимальный failover dashboard обычно включает:

• failover activation rate by lane;
• reason for failover;
• schema/tool compatibility failures on secondary;
• judge-score delta primary vs secondary;
• quarantine events;
• failback canary success rate.

Отдельно полезно смотреть availability saved vs contract lost. Иначе команда может гордиться uptime, не замечая деградации продукта.

Пример failover policy

lanes:
  structured_support:
    primary: openai/gpt-5.4-mini
    secondary:
      - anthropic/claude-sonnet-4-6
    triggers:
      - provider_5xx_rate > 0.15
      - p95_latency > 10s
    block_on:
      - schema_invalid_rate > 0.02
      - tool_mismatch_detected = true

  high_risk_actions:
    primary: openai/gpt-5.4
    secondary: []
    on_unavailable: manual_handoff

Простой failover decision

def should_failover(route):
    if route.schema_invalid_rate > 0.02:
        return False, "contract_risk"
    if route.provider_5xx_rate > 0.15:
        return True, "transport_failure"
    if route.p95_latency > 10:
        return True, "latency_breach"
    return False, "healthy"

Практический совет: если secondary path не прошёл те же contract checks, что и primary, его нельзя считать настоящим failover. Это просто другой риск, замаскированный под устойчивость.