Відмовостійкість AI-агентів: failover та автозаміна

Розробка системи failover та автозаміни AI-агентів

Уявіть: AI-агент обробляє чергу запитів клієнтів, раптово падає, і всі незбережені діалоги втрачаються. Без failover простий триває 10–15 хвилин, поки оператор вручну перенаправляє завдання. За даними Gartner, кожна година простою AI-систем обходиться в середньому в $300,000 для великих компаній. Помилка в моделі, вичерпання GPU-пам'яті, збій мережі — будь-який із цих сценаріїв призводить до падіння агента. Без автоматичного failover команда витрачає 10–15 хвилин на ручне відновлення, а клієнти втрачають дані. Ми бачили проєкти, де втрата checkpoint за 5 хвилин роботи коштувала компанії $50,000. Наша система вирішує цю проблему — проєктуємо автоматичне перемикання на резервний агент без втрати прогресу. Зв'яжіться з нами, щоб отримати оцінку вашого проєкту за 2 дні.

Чому failover критичний для AI-агентів?

Безперервні процеси — моніторинг дашбордів, обробка вхідних повідомлень, довгострокові RAG-ланцюжки — вимагають відмовостійкості. Один збій може коштувати тисячі доларів необроблених транзакцій. Наша система гарантує RTO < 5 секунд з warm standby та RPO не більше 60 секунд роботи. Warm standby відновлює роботу в 60 разів швидше за cold start — менше 5 секунд замість 5–15 хвилин. Надлишковість агентів (agent redundancy) знижує ризик single point of failure.

Як працює автоматична заміна агента?

Оркестратор кожні 15 секунд перевіряє health endpoint кожного агента. При трьох послідовних помилках агент позначається як failed, його завдання (з checkpoint) перенаправляються найменш завантаженому здоровому агенту з підвищеним пріоритетом. Одночасно запускається новий інстанс через Kubernetes або Docker.

Архітектура failover

               ┌─────────────────────────────────┐
               │       Task Queue (Redis/Kafka)   │
               └────────────┬────────────────────┘
                            │
              ┌─────────────▼──────────────┐
              │    Orchestrator / Scheduler  │
              │   (health checks, failover)  │
              └──────┬─────────────┬────────┘
                     │             │
              ┌──────▼───┐  ┌──────▼───┐
              │  Agent 1  │  │  Agent 2  │
              │  (active) │  │ (standby) │
              └──────┬───┘  └──────────┘
                     │ crash
              ┌──────▼──────────────────────┐
              │  Failover: задачі Agent 1    │
              │  передані Agent 2 (із        │
              │  checkpoint або черги)      │
              └─────────────────────────────┘

Реалізація health check та оркестратора

import asyncio
import aiohttp
from datetime import datetime, timedelta


@dataclass
class AgentHealth:
    agent_id: str
    last_heartbeat: datetime
    last_task_completed: datetime | None
    consecutive_failures: int
    status: str  # healthy / degraded / failed


class AgentHealthMonitor:
    def __init__(self, failure_threshold: int = 3, heartbeat_timeout: int = 30):
        self.failure_threshold = failure_threshold
        self.heartbeat_timeout = heartbeat_timeout
        self.agent_health: dict[str, AgentHealth] = {}

    async def check_agents(self, agent_ids: list[str]) -> dict[str, AgentHealth]:
        tasks = [self._check_agent(agent_id) for agent_id in agent_ids]
        results = await asyncio.gather(*tasks, return_exceptions=True)

        for agent_id, result in zip(agent_ids, results):
            if isinstance(result, Exception):
                self._record_failure(agent_id, str(result))
            else:
                self._record_success(agent_id, result)

        return self.agent_health

    async def _check_agent(self, agent_id: str) -> dict:
        url = f"http://{agent_id}:8080/health"
        async with aiohttp.ClientSession(timeout=aiohttp.ClientTimeout(total=5)) as session:
            async with session.get(url) as response:
                return await response.json()

    def _record_failure(self, agent_id: str, error: str):
        health = self.agent_health.setdefault(agent_id, AgentHealth(
            agent_id=agent_id, last_heartbeat=datetime.utcnow(),
            last_task_completed=None, consecutive_failures=0, status="healthy"
        ))
        health.consecutive_failures += 1
        if health.consecutive_failures >= self.failure_threshold:
            health.status = "failed"
            logger.critical(f"Agent {agent_id} marked as FAILED after {health.consecutive_failures} failures")

    def get_failed_agents(self) -> list[str]:
        return [aid for aid, h in self.agent_health.items() if h.status == "failed"]

    def get_healthy_agents(self) -> list[str]:
        return [aid for aid, h in self.agent_health.items() if h.status == "healthy"]

class FailoverOrchestrator:
    def __init__(self, task_queue: TaskQueue, health_monitor: AgentHealthMonitor,
                 checkpoint_manager: CheckpointManager):
        self.task_queue = task_queue
        self.health_monitor = health_monitor
        self.checkpoint_manager = checkpoint_manager

    async def run_failover_loop(self):
        while True:
            await asyncio.sleep(15)  # перевірка кожні 15 секунд

            failed_agents = self.health_monitor.get_failed_agents()
            if not failed_agents:
                continue

            healthy_agents = self.health_monitor.get_healthy_agents()
            if not healthy_agents:
                logger.critical("NO HEALTHY AGENTS AVAILABLE - alerting on-call")
                await self._page_oncall("All agents failed")
                continue

            for failed_agent in failed_agents:
                await self._failover_agent(failed_agent, healthy_agents)

    async def _failover_agent(self, failed_agent: str, healthy_agents: list[str]):
        logger.info(f"Starting failover for agent {failed_agent}")

        # Отримуємо завдання, призначені впавшому агенту
        assigned_tasks = await self.task_queue.get_tasks_for_agent(failed_agent)

        for task in assigned_tasks:
            # Пробуємо відновитися з checkpoint
            checkpoint = await self.checkpoint_manager.load(task.id)

            # Вибираємо найменш завантажений здоровий агент
            target_agent = self._select_least_loaded_agent(healthy_agents)

            # Перенаправляємо завдання з checkpoint
            await self.task_queue.reassign_task(
                task_id=task.id,
                new_agent=target_agent,
                checkpoint=checkpoint,
                priority=TaskPriority.HIGH  # підвищуємо пріоритет для failover задач
            )

            logger.info(f"Task {task.id} reassigned from {failed_agent} to {target_agent}")

        # Позначаємо агент як такий, що потребує заміни
        await self._trigger_agent_replacement(failed_agent)

    async def _trigger_agent_replacement(self, agent_id: str):
        """Запускаємо новий інстанс агента через K8s або Docker."""
        if self.is_kubernetes:
            await k8s_client.delete_pod(agent_id)
        else:
            await docker_client.restart_container(agent_id)

Порівняння методів health check

Які стратегії failover обрати для AI-агентів?

Вибір стратегії залежить від критичності завдань. Warm standby — золота середина: резервний агент завантажено моделлю та прогріто, але він не обробляє завдань. Failover займає менше 5 секунд проти 5–15 хвилин при cold start. Для фінансових транзакцій, де кожна секунда на рахунку, краще підходить hot standby з RTO менше 1 секунди, але він вимагає синхронізації стану та 3× ресурсів. Якщо ж простій допустимий, cold start економить ресурси, але RTO сягає 15 хвилин.

Порівняння стратегій failover

RTO та RPO для AI-агентів

RTO (Recovery Time Objective): час відновлення після збою. З warm standby: < 30 сек. З checkpoint + cold start: 5–15 хв. RPO (Recovery Point Objective): втрата даних/прогресу. З checkpoint кожні 60 сек: втрата не більше 60 сек роботи. Для фінансових транзакцій — checkpoint після кожного кроку. Детальніше про метрики читайте в документації з RTO.

Приклад конфігурації Kubernetes для failover:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-agent
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    spec:
      containers:
      - name: agent
        image: myregistry/ai-agent:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 15
        resources:
          requests:
            nvidia.com/gpu: 1

Що входить в роботу

• Архітектурна схема failover (health check, orchestration, checkpointing)
• Реалізація оркестратора та пулу standby агентів
• Інтеграція з чергою завдань (Redis/Kafka) та Kubernetes/Docker
• Документація з експлуатації (RTO/RPO, playbook)
• Тестування сценаріїв відмови (crash, network partition, resource exhaustion)
• Підтримка 2 тижні після впровадження

Як ми працюємо

1. Аналітика — вивчаємо поточну архітектуру агентів, визначаємо RTO/RPO, обираємо стратегію
2. Проєктування — малюємо схему, узгоджуємо health check endpoint та protobuf-контракти
3. Реалізація — пишемо оркестратор, налаштовуємо warm standby, підключаємо checkpointing
4. Тестування — симулюємо відмови (Chaos Engineering), вимірюємо метрики failover
5. Деплой — розгортаємо в staging, проводимо навантажувальні тести, передаємо в production

Терміни та вартість

Проєкт від 2 до 5 робочих днів для одного AI-агента. Вартість розраховується індивідуально — залежить від складності моделі, обсягу контексту та вимог до RTO/RPO. Оцінимо ваш проєкт за 2 дні — зв'яжіться з нами для консультації. Спираючись на досвід 50+ реалізованих систем відмовостійкості, гарантуємо коректну роботу failover в умовах реального навантаження. Ми використовуємо сучасний стек: Python asyncio, vLLM, Kubernetes, Apache Kafka. Замовте впровадження та отримайте надійний захист від простоїв.

MLOps: інфраструктура для навчання, деплою та моніторингу ML-моделей

Модель навчена, метрики — F1 0.94 на валідації. Через три місяці в продакшені якість падає на 12%. Ніхто не знає, коли саме — немає моніторингу. Не можна швидко перенавчити — навчальний скрипт лежить у Jupyter-ноутбуці у data scientist’а, який вже звільнився. Дані для ретрейну збирають вручну з трьох розрізнених систем. Приблизно половина проєктів приходять до нас із цим болем. Ми будуємо MLOps платформу під ключ: від трекінгу експериментів до автоматичного деплою та моніторингу дрейфу даних. Оцінимо вашу інфраструктуру за 1–2 тижні, а через 4–6 тижнів ви отримаєте базове ядро MLOps, що працює в продуктивному контурі. Наша команда — 10+ років досвіду в ML-інфраструктурі, понад 50 впроваджень.

Як побудувати MLOps-інфраструктуру?

Experiment tracking та відтворюваність

Без трекінгу ML-проєкт перетворюється на хаос: незрозуміло, який чекпоінт кращий, які гіперпараметри використовувались, який датасет. Відтворити результат через місяць — квест.

MLflow — open source стандарт для трекінгу. Логує параметри, метрики, артефакти (моделі, графіки) та код. MLflow Model Registry — централізоване сховище моделей з версіонуванням та lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving або інтеграція із зовнішніми системами.

Типова ініціалізація в коді:

import mlflow

mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
    mlflow.log_metric("val_f1", val_f1, step=epoch)
    mlflow.pytorch.log_model(model, "model")

Це мінімум. В production додаємо логування системних метрик (GPU utilization, memory), датасету (hash, версія), коду (git commit hash). Weights & Biases — більш багатий UI, collaboration features, sweep для hyperparameter optimization. MLflow — для on-premise deployment без зовнішніх залежностей.

DVC (Data Version Control) — версіонування даних та моделей поверх git. Дані зберігаються в S3/GCS/Azure Blob, у git — лише метадані (хеші). dvc repro відтворює весь пайплайн від сирих даних до метрик.

Як забезпечити відтворюваність навчання?

Фіксуйте random seeds (torch.manual_seed, numpy.random.seed, random.seed) та записуйте їх у метадані експерименту. Без цього дебагінг нерегулярних результатів — біль. Логуйте версію датасету (DVC hash) та git commit — тоді будь-який експеримент можна повторити з точністю до байта. Це скорочує час на відтворення результатів у 2–3 рази.

Оркестрація пайплайнів: Kubeflow, Airflow, Prefect

Коли потрібен оркестратор пайплайнів?

Скрипт навчання на 100 рядків у cron — нормально для простих задач. Але як тільки з'являється multi-step пайплайн (завантаження даних → preprocessing → feature engineering → навчання → валідація → деплой якщо якість вище порогу), потрібен оркестратор з retry-логікою, візуалізацією, алертами.

Kubeflow — Kubernetes-native оркестратор для ML. Кожен крок — Docker-контейнер. Підтримує паралельні кроки, умовні гілки, артефакти між кроками. Інтегрується з Katib (AutoML), KServe (serving), Feast (feature store). Kubeflow краще за Airflow для ML-пайплайнів у 2–3 рази за швидкістю налаштування та інтеграції з ML-інструментами.

Apache Airflow — більш загальний DAG-оркестратор. Широка екосистема операторів (S3, Spark, DBT, Kubernetes). Простіше розгорнути, якщо в компанії вже є Airflow.

Prefect / Metaflow — менше boilerplate. Prefect 2.x з декораторами @flow та @task — швидкий старт для невеликих команд.

Типова архітектура навчального пайплайну на Kubeflow:

1. Data ingestion component — забирає дані з S3/БД, валідує схему через Great Expectations
2. Preprocessing component — трансформації, normalization, train/val/test split
3. Training component — навчання на GPU, логування в MLflow
4. Evaluation component — обчислення метрик, порівняння з baseline в Model Registry
5. Conditional deployment — деплой тільки якщо нова модель краща за поточну на >2% F1

Кожен component — окремий Docker-образ. Пайплайн версіонується в git. Запуск за розкладом (ретрейнінг раз на тиждень на нових даних) або вручну.

from kfp import dsl

@dsl.pipeline(name='training-pipeline')
def pipeline():
    data_op = data_ingestion_op()
    preprocess_op = preprocessing_op(data_op.output)
    train_op = training_op(preprocess_op.output)
    eval_op = evaluation_op(train_op.output)
    with dsl.Condition(eval_op.output > 0.95):
        deploy_op = deployment_op(train_op.output)

Model Registry та управління життєвим циклом

Model Registry — не просто сховище чекпоінтів. Це централізована система, яка знає:

• Яка модель зараз у продакшені (і з якими метриками)
• Історія всіх версій з параметрами навчання
• Метадані: датасет, git commit, результати валідації
• Lifecycle stage: None → Staging → Production → Archived

MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.

Просування моделі через стейджі: автоматично переводимо модель у Staging після успішного проходження eval, потім ручне або автоматичне (при A/B тесті) просування в Production. Rollback — перемикання на попередню Production-версію за секунди.

Serving: від FastAPI до Triton Inference Server

Простий випадок. FastAPI + PyTorch/ONNX на одному сервері — 80% production ML deployments саме так. Достатньо для більшості задач з навантаженням до 100 req/s.

from fastapi import FastAPI
import onnxruntime as ort

app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])

@app.post("/predict")
async def predict(request: PredictRequest):
    inputs = preprocess(request.text)
    outputs = session.run(None, {"input_ids": inputs})
    return {"label": postprocess(outputs)}

FastAPI + ONNX підходить для 80% задач, але при навантаженні понад 100 req/s Triton Inference Server дає у 3 рази вищу пропускну здатність. Triton — production-стандарт для високих навантажень (500+ req/s). Dynamic batching, concurrent model execution, model ensemble. Підтримує TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel.

KServe — Kubernetes-native ML serving з autoscaling, canary deployments, A/B testing з коробки. Scale-to-zero для неактивних моделей — економія на інфраструктурі до 40%.

Моніторинг: data drift, model drift, інфраструктурні метрики

Моніторинг — те, що зазвичай роблять в останню чергу і про що шкодують у першу. Три рівні.

Інфраструктурний моніторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold або error rate > 1%.

Data drift моніторинг. Розподіл вхідних даних змінюється з часом. Детектуємо через PSI (Population Stability Index) для числових ознак: PSI > 0.2 — сильний дрейф. Chi-squared test для категоріальних, Kolmogorov-Smirnov test для неперервних. Evidently AI — open source бібліотека з готовими дрейф-тестами.

Model drift моніторинг. Якщо є ground truth із затримкою (наприклад, через тиждень знаємо конверсію) — моніторимо реальні метрики. Якщо ні — surrogate метрики: розподіл prediction scores, частка confident predictions.

Alerting. Три рівні: INFO (невеликий дрейф, логуємо), WARNING (значний, повідомляємо команду), CRITICAL (якість впала нижче порогу — автоматичне перемикання на fallback-модель).

Чому важливий моніторинг дрейфу даних?

Без нього ви дізнаєтеся про деградацію моделі тільки за скаргами користувачів або дзвінким SLA. Алерт про дрейф дозволяє перенавчити модель заздалегідь, до того як помилки почнуть приносити збитки. В одному з наших проєктів моніторинг PSI виявив дрейф через 2 дні після зміни джерела даних — це врятувало кампанію з бюджетом понад $100K. За словами CTO клієнта, впровадження моніторингу скоротило час виявлення проблем з 2 тижнів до 2 годин.

Feature Store

Feature Store вирішує проблему training-serving skew. Якщо preprocessing під час навчання та інференсу реалізований у двох різних місцях — розбіжність неминуча.

Коли потрібен Feature Store?

• Кілька моделей використовують одні й ті ж ознаки
• Ознаки обчислюються з потокових даних (real-time)
• Велика команда з різними людьми на feature engineering та model training

Feast — open source Feature Store. Офлайн store (S3 + Parquet) для навчання, онлайн store (Redis, DynamoDB) для low-latency інференсу. Feature definitions як код, materialization job синхронізує офлайн → онлайн.

Tecton (комерційний), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варіанти з меншим ops overhead.

Як автоматизувати CI/CD для ML?

ML CI/CD — звичайний CI/CD плюс специфічні ML-кроки.

ML-специфічні checks в CI:

• Перевірка відтворюваності: запустити навчання з фіксованим seed, результат має збігатися
• Data validation: Great Expectations або Pandera на schema/distribution checks
• Model performance check: автоматичний eval на holdout, блокувати merge якщо деградація > порогу
• Latency regression test: inference має вкладатися в SLA

GitOps для деплою. Merge в main → CI запускає навчання → eval → якщо проходить → автоматичний деплой у Staging → smoke tests → ручне просування в Production або автоматичне при успішному canary.

Інструменти: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплою на Kubernetes.

Що входить у розробку MLOps-платформи

Ми надаємо повний цикл робіт, документацію та навчання команди.

Підсумковий термін від аудиту до повноцінної MLOps-платформи: 3–5 місяців. Базовий рівень (трекінг + serving) за 4–6 тижнів. Вартість розраховується індивідуально під обсяг даних (від 1 ТБ), кількість моделей та вимоги до інфраструктури. Замовте аудит MLOps-інфраструктури — отримайте roadmap за 1–2 тижні. Зв'яжіться з нами для оцінки вашого проєкту — ми надішлемо попередній розрахунок за 2 робочих дні.

Гарантія на архітектурні рішення — 12 місяців. Надаємо сертифікати інтеграції з основними хмарними провайдерами (AWS, GCP, Azure). За час роботи ми не втратили жодного клієнта після першого впровадження — досвід 50+ успішних MLOps-проєктів говорить сам за себе. Отримайте консультацію щодо побудови MLOps платформи вже сьогодні.