Как вы проектируете on-call ротацию для AI сервиса?

Краткий тезис

On-call ротация для AI-сервиса — это система дежурств, обеспечивающая круглосуточную реакцию на инциденты. Ключевые элементы: primary (инженер первой линии), secondary (тимлид или старший инженер для эскалации), детальные runbooks для типовых проблем и чёткий процесс эскалации (например, 15 минут без ответа → secondary → lead). Для AI-сервисов важно учитывать специфику: падение качества ответов, дрейф данных, сбои LLM-провайдеров, поэтому runbooks должны покрывать не только инфраструктурные, но и модельные инциденты.

1. Зачем AI-сервису on-call ротация?

On-call — это практика, при которой один или несколько инженеров находятся в режиме ожидания для немедленного реагирования на инциденты. Для AI-сервисов это критично, потому что:

• Пользователи ожидают высокой доступности (SLA 99.9%+). Если сервис отвечает медленно или выдаёт мусор, бизнес теряет деньги.
• Модели могут «ломаться» без изменения кода: дрейф данных, внезапное падение качества эмбеддингов, блокировка API провайдера.
• Сложность диагностики: проблема может быть в retrieval, генерации, промпте или инфраструктуре — нужен человек, способный быстро локализовать.

Без on-call инциденты остаются незамеченными до утра, что неприемлемо для production-систем.

2. Роли в on-call ротации

Важно: secondary не должен дублировать primary — его задача подключаться, когда primary не справляется или не отвечает.

3. Процесс эскалации

Эскалация — это чёткая цепочка повышения уровня ответственности. Пример для AI-сервиса:

1. Алерт → primary получает уведомление (PagerDuty, Opsgenie, Telegram-бот).
2. Primary не отвечает 15 минут → автоматическая эскалация secondary.
3. Secondary не отвечает 10 минут → эскалация lead.
4. Lead не отвечает 5 минут → эскалация CTO / VP of Engineering.

Правило: время эскалации должно быть задокументировано и автоматизировано. Ручные звонки — последнее средство.

Для AI-сервисов стоит добавить автоматическую эскалацию по типу инцидента: если алерт связан с падением качества ответов (мониторинг faithfulness), сразу уведомлять ML-инженера, а не только дежурного по инфраструктуре.

4. Runbooks: что должно быть в каждом

Runbook — это пошаговая инструкция по устранению типового инцидента. Для AI-сервиса runbooks делятся на категории:

4.1 Инфраструктурные

• Высокая задержка (latency): проверить CPU/GPU, количество реплик, лимиты API провайдера.
• Ошибки 5xx: проверить балансировщик, логи контейнеров, доступность векторной БД.
• Падение индекса: перестроить индекс, проверить краулер.

4.2 Модельные

• Дрейф данных: запустить пайплайн мониторинга распределений, сравнить с baseline.
• Падение faithfulness: проверить последние изменения в промпте, откатить версию.
• Блокировка API LLM: переключиться на fallback-модель (например, с GPT-4 на Claude).

4.3 Бизнес-метрики

• Резкое падение конверсии: проверить A/B-тесты, откатить фичу, уведомить продакт-менеджера.

Каждый runbook должен содержать:

• Симптомы (как понять, что это именно этот инцидент)
• Диагностические шаги (команды, дашборды)
• Действия по исправлению
• Критерии завершения (как убедиться, что проблема решена)

5. Мониторинг и алерты для on-call

Алерты должны быть actionable (требовать действия) и не шуметь. Для AI-сервиса типовые алерты:

Правило: каждый алерт должен иметь runbook. Если runbook нет — алерт не нужен.

6. Балансировка нагрузки между дежурными

Чтобы избежать выгорания, ротацию проектируют так:

• Продолжительность смены: 1 неделя (не больше 2-х подряд).
• Частота: не чаще 1 раза в 4-6 недель на человека.
• Компенсация: дополнительный выходной или денежная выплата.
• Overlap: в начале смены primary и secondary проводят handoff (передачу контекста).

Для небольших команд (2-3 человека) используют follow-the-sun (дежурство по часовым поясам) или автоматизированное эскалирование до CTO.

7. Онбординг новых дежурных

Новый инженер не должен заступать на дежурство без подготовки. Процесс:

1. Shadowing — неделя наблюдения за текущим primary.
2. Изучение runbooks — прочитать все, задать вопросы.
3. Симуляция инцидентов — GameDay (искусственное создание проблем в staging).
4. Пробное дежурство — с secondary в режиме ментора.

Чеклист готовности:

• Умеет читать логи (Kibana, Grafana Loki).
• Знает, как перезапустить сервис.
• Знает, как откатить модель.
• Имеет доступ ко всем системам.

8. Post-mortem и улучшение ротации

После каждого серьёзного инцидента (P0/P1) проводится post-mortem (разбор без обвинений). Цель — улучшить runbooks, мониторинг и процесс.

Вопросы для post-mortem:

• Что пошло не так?
• Почему алерт не сработал раньше?
• Было ли достаточно информации в runbook?
• Как предотвратить повторение?

Результат — обновлённые runbooks, новые алерты, изменения в архитектуре.

9. Автоматизация on-call

Часть рутинных действий можно автоматизировать:

• Авто-эскалация через PagerDuty / Opsgenie.
• Авто-откат модели при падении faithfulness ниже порога.
• Чат-бот для первичной диагностики (например, запрос статуса сервиса через Slack).
• Авто-создание тикета в Jira при эскалации.

Но полную автоматизацию замены дежурного делать нельзя — сложные инциденты требуют человеческого суждения.

10. Психологическая безопасность

On-call — стресс. Чтобы снизить выгорание:

• No-blame culture — ошибки дежурного не наказываются.
• Чёткие границы — после смены дежурный не обязан отвечать на сообщения.
• Поддержка — secondary всегда готов помочь.
• Ретроспективы — команда обсуждает, как улучшить процесс.

Пет-проект для закрепления

Задача: Разработать систему on-call для AI-чат-бота, который отвечает на вопросы по документации.

Инструменты:

• PagerDuty (или Opsgenie) — для ротации и эскалации.
• Grafana + Prometheus — мониторинг метрик (latency, error rate, faithfulness).
• Python-скрипт — симулятор инцидентов.
• GitHub — хранение runbooks в Markdown.

Шаги:

1. Определить 3 типовых инцидента (высокая latency, падение faithfulness, ошибка API).
2. Написать runbook для каждого.
3. Настроить алерты в Grafana (например, при faithfulness < 0.8).
4. Создать ротацию в PagerDuty на 2-х человек (primary и secondary) с эскалацией через 15 минут.
5. Провести GameDay: запустить скрипт, который искусственно вызывает инцидент, и проверить, как сработает эскалация.
6. После инцидента написать post-mortem и обновить runbook.

Ожидаемый результат: Работающая on-call система с документацией, автоматической эскалацией и проверкой через симуляцию.

Связь с другими вопросами

Навигация

• Предыдущий: 389
• Следующий: 391
• Индекс: 00. Индекс разборов