Runbook для дежурного по LLM-сервису на первые 15 минут

Что обычно ломается в первые 15 минут

В начале инцидента почти никогда нет одного чистого симптома. Ошибки уже растут, но причина еще прячется за шумом: часть запросов падает по таймауту, часть уходит в повторные попытки, часть доезжает до запасной модели и меняет поведение сервиса.

Из-за этого графики часто противоречат друг другу. В одном месте вы видите всплеск 5xx, в другом - рост 429, а в продукте жалобы звучат так, будто это разные поломки. На деле источник может быть один: провайдер начал отвечать медленнее, очередь выросла, повторные попытки добавили нагрузку, а потом посыпались ошибки по лимитам и бюджету.

Цена тоже умеет расти без явного скачка трафика. Часто сервис незаметно переключается на более дорогую модель или fallback уводит часть запросов к другому провайдеру. Бывает и проще: ломается ограничение по max_tokens, в промпт попадает лишний контекст, ответы становятся длиннее. Еще одна частая причина - повторы. Один пользовательский запрос может списать токены два или три раза, если система слишком настойчиво добивается ответа.

С задержкой ситуация еще неприятнее. Она растет даже тогда, когда входящий поток почти не изменился. Так бывает, если провайдер дольше держит запросы, забился пул воркеров, отключился кеш промптов или модель на своих GPU уперлась в ресурс и начала копить очередь. Для дежурного это выглядит обманчиво: трафик ровный, а пользователи уже пишут, что сервис "думает" по 20-30 секунд.

Обычно жалобы приходят сразу в нескольких формах:

• "Ответы пропали"
• "Все стало медленнее"
• "Качество резко хуже"
• "Счет растет слишком быстро"

Для сервиса с LLM это нормальная картина. Один продукт может одновременно обращаться к нескольким моделям, провайдерам и запасным маршрутам. Если запросы идут через шлюз вроде AI Router, часть трафика уже может уйти по другому пути, а часть остаться на старом. Поэтому пользователи описывают разные симптомы в одно и то же время.

Нормальный runbook в первые 15 минут помогает не искать "одну ошибку", а быстро выбрать между тремя версиями: сломался маршрут, выросла длина генерации или система начала тратить больше попыток на каждый запрос.

Что подготовить до инцидента

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

Сначала определите пороги. Не общие формулировки вроде "что-то медленно", а числа: какой процент ошибок вы считаете аварией, какой p95 latency нормален для каждого важного сценария и где проходит граница по стоимости на один запрос, тысячу запросов или сессию. Если сервис использует несколько моделей, храните пороги отдельно. У большой внешней модели, open-weight модели и rerank-вызова нормальная задержка разная.

Дальше подготовьте карту маршрутов. У дежурного должна быть простая таблица: какая модель стоит в проде, через какого провайдера она идет, какой есть запасной путь и что меняется при переключении. Если команда работает через AI Router, в этой таблице удобно сразу отмечать, какие сценарии можно быстро перевести на другого провайдера через тот же endpoint api.airouter.kz, а какие - на модель, размещенную внутри страны, когда важны data residency и низкая задержка.

Третий блок - журнал последних изменений. Источник проблемы очень часто банален: новый промпт, выросший max_tokens, включенный флаг, смена модели по умолчанию, свежий релиз клиента или новый rate limit. Дежурный не должен вспоминать это по памяти. Нужен короткий список изменений хотя бы за последние 72 часа с временем, автором и ожидаемым эффектом.

В одном месте должны лежать:

• пороги по ошибкам, задержке и цене
• текущие модели, провайдеры и запасные маршруты
• последние релизы, флаги и правки промптов
• контакты владельца сервиса и человека, который принимает бизнес-риск

Последний пункт часто недооценивают. Нужен не просто список имен, а понятный порядок звонка: кто решает, можно ли временно отключить дорогую модель, кто согласует деградацию ответа, кто отвечает за клиентов с жестким SLA. Тогда в 02:15 не нужно гадать, кому писать первым.

Хорошо собранный runbook экономит не часы. Чаще он экономит первые 7-10 минут, а это и есть разница между локальной просадкой и заметным инцидентом для пользователей.

Первые 5 минут

Сначала проверьте, что алерт живой, а не шум. Один график не убеждает. Сверьте его хотя бы с двумя сигналами: логами ошибок, p95 latency, числом запросов, расходом токенов или жалобами из продукта.

Если алерт сработал по одному сервису, а соседние метрики спокойны, не спешите объявлять инцидент. Часто ломается не сама модель, а мониторинг, лимит на одном ключе или отдельный провайдер.

Потом посмотрите на время начала проблемы. Откройте ленту релизов, фичефлагов и расписание фоновых задач. Сравните это с трафиком: был ли всплеск запросов, смена модели по роутингу, крупная рассылка, ночной batch-процесс или новый клиент. В сервисах с LLM рост ошибок и задержки нередко начинается не с падения провайдера, а с обычного скачка нагрузки после релиза.

В эти минуты полезно быстро разложить симптомы по трем корзинам:

• ошибки: 4xx, 5xx, таймауты, rate limit, пустые или оборванные ответы
• цена: выросла стоимость запроса, токены на запрос или доля дорогой модели
• задержка: выросли p95 и p99, очередь, время до первого токена

Такое разделение экономит время. Если выросла только цена, не нужно чинить сеть. Если выросла только задержка, не стоит сразу откатывать последний релиз API.

Следующий шаг простой и часто самый полезный: поставьте на паузу все, что само меняет поведение системы. Остановите раскатку, канарейку, автоэксперименты, A/B-тесты, автоматическое переключение на новые модели, если оно не ограничено жесткими лимитами. Сначала зафиксируйте картину, потом меняйте настройки.

Если команда работает через единый шлюз, в первые минуты особенно полезно проверить, не сменился ли провайдер или маршрут модели. Код мог остаться тем же, а задержка и цена изменились из-за другого внешнего пути.

И еще одно действие, которое многие пропускают: сразу откройте заметку инцидента и запишите текущее состояние. Достаточно четырех строк - время начала, что сломалось, что уже проверили, что заморозили. Через десять минут память подводит, а короткая запись убирает споры о фактах.

Минуты 5-10

Если тревога не снялась за первые минуты, пора сузить круг причин. Не смотрите на общий график. Разложите сбой по четырем срезам: модель, маршрут, ключ и клиент. Часто одна модель дает всплеск 5xx, один маршрут ловит рост задержки, а один клиент просто начал отправлять слишком длинные запросы.

В логах и метриках полезно быстро ответить на два вопроса: проблема общая или локальная, и что выросло первым - ошибки, задержка или стоимость. Если у вас единый API-шлюз, как AI Router, этот шаг особенно важен. Снаружи все выглядит как один поток, но внутри причина может сидеть в одном провайдере или даже в одном правиле маршрутизации.

Проверьте настройки, которые ломают сервис тихо, без явной аварии. Таймауты могли стать слишком короткими для текущей модели. Rate limit на уровне ключа мог упереться в потолок. Длина ответов тоже часто бьет сразу по двум метрикам: растут задержка и счет.

Быстрая проверка в этот момент обычно выглядит так:

• сравните p95 latency и error rate по каждой модели и маршруту
• найдите клиентов или ключи, у которых резко выросли prompt tokens и completion tokens
• посмотрите, не просела ли доля попаданий в кеш на частых запросах
• проверьте, не включился ли дорогой маршрут заметно чаще обычного

Просадка кеша часто выглядит как "внезапно все стало дороже и медленнее". На деле сервис просто перестал попадать в повторяющиеся ответы, и каждое обращение ушло в полную генерацию. Такое бывает после изменения промпта, системного сообщения или параметров семплирования.

Если задержка и цена растут вместе, не ждите идеального диагноза. На 5-10 минуте лучше ограничить ущерб. Снизьте max_tokens для проблемного маршрута. Уберите самый дорогой путь из цепочки fallback. Переведите часть трафика на запасную модель, если недавние проверки показали, что она держит приемлемое качество.

Временное решение должно быть обратимым. Запишите, что именно вы поменяли: процент трафика, лимит токенов, список клиентов или маршрут. Через час это сэкономит много нервов и не даст "починить" сервис ценой новой, уже скрытой проблемы.

Минуты 10-15

Если ошибки или задержка держатся уже десять минут, дежурному лучше перестать пробовать все сразу. В этот момент нужен один шаг с быстрым эффектом и понятной проверкой через несколько минут.

Режим деградации включают не для отчета, а чтобы сервис продолжал дышать. Он нужен, когда полное качество ответа уже бьет по SLA, цене или длине очереди. На практике это может быть временное снижение max_tokens, отключение tool calling для второстепенных сценариев, перевод несрочных задач в очередь или переход с дорогой модели на более быструю. Если команда работает через AI Router, быстрым ходом часто становится перевод части трафика на другого провайдера или другую модель через тот же OpenAI-совместимый endpoint.

Плохая идея - менять сразу четыре вещи. Если вы одновременно тронете модель, таймаут, повторы и лимиты, через пять минут никто не поймет, что именно сработало. Лучше выбрать одно действие и смотреть на те же метрики, которые подняли тревогу. Например, снизить долю трафика на проблемную модель с 80% до 20% и проверить, упали ли error rate, p95 и средняя стоимость запроса.

Команде и саппорту нужен короткий статус, без длинных объяснений. Достаточно написать, когда началась проблема, какие запросы затронуты, что уже изменили и когда будет следующее обновление. Для саппорта хватает простой формулировки: "Видим рост задержки в части запросов, включили обходной маршрут, вернемся с новым статусом через 10 минут".

Для эскалации обычно хватает такого набора:

• время начала инцидента
• что затронуто: модель, провайдер, регион или тип запроса
• цифры до и после изменения
• что уже сделали и в какую минуту
• какой риск остается прямо сейчас

Следующую проверку ставят сразу, а не "позже". Через 5-10 минут дежурный снова смотрит те же графики и принимает одно из трех решений: оставить деградацию, откатить изменение или звать следующую линию. Это простое правило часто полезнее любой красивой схемы.

Как быстро отделить рост цены от роста трафика

Если счет растет вместе с числом запросов, легко сделать ложный вывод: нагрузка выросла, значит расход тоже вырос ожидаемо. Проверка начинается не с общего счета, а с удельной стоимости. Смотрите цену на один запрос и цену на 1000 входных и выходных токенов. Если трафик поднялся на 30%, а стоимость запроса выросла почти вдвое, причина не только в трафике.

Потом разбейте расход по моделям. Частая история: часть запросов ушла с дешевой модели на дорогую после fallback, смены провайдера или правки правил маршрутизации. Если вы работаете через единый шлюз, такой сдвиг быстрее видно по доле запросов на каждую модель и каждого провайдера. Иногда хватает 10% трафика на дорогой маршрут, чтобы бюджет поплыл.

Отдельно проверьте размер промпта и ответа. При том же числе запросов расход может резко вырасти, если системный промпт стал длиннее, пользователи начали отправлять больше контекста или модель стала отвечать слишком подробно. Смотрите среднее значение и p95 по input tokens и output tokens. Рост только по output tokens часто указывает на длинные ответы или лишние циклы вызовов инструментов.

Быстрый срез лучше делать по пяти точкам:

• стоимость на запрос и на 1000 токенов
• доля трафика по моделям и провайдерам
• средний размер системного промпта, пользовательского ввода и ответа
• число повторов, таймаутов и дублей
• недавние правки в системном промпте и вызовах инструментов

Повторы и дубли жгут бюджет тихо. Пользователь видит один ответ, а сервис успевает сделать два или три вызова из-за короткого таймаута, повторной отправки из очереди или ошибки идемпотентности. Если полезных ответов не стало больше, а расход вырос, сначала ищите именно это.

После этого откройте последние изменения. Нередко виновата маленькая правка: добавили длинный системный промпт, подняли max_tokens, включили новый инструмент или перевели часть задач на более дорогую модель. Поэтому пороги лучше задавать заранее: какой рост стоимости на запрос терпим, какая доля дорогой модели допустима и при каком размере промпта команда сразу откатывает правку.

Пример ночной смены

02:13. После ночного релиза дашборд показывает неприятный сдвиг: p95 вырос с 4 до 11 секунд. При этом 5xx почти не двигаются, таймаутов мало, а жалоб от клиентов еще нет. Это опасный случай. Сервис формально жив, но пользователь уже ждет слишком долго, а деньги начинают уходить быстрее обычного.

Дежурный сначала смотрит не на общий график, а на срез по маршрутам. Запросов в минуту стало лишь немного больше, зато средний output tokens на ответ вырос почти вдвое. На графике стоимости виден еще один след: часть трафика после релиза ушла на fallback, и fallback теперь ведет не на обычную модель, а на более дорогую. Если команда работает через единый шлюз, такой перекос хорошо виден по доле маршрута и цене за 1K токенов.

Через пару минут картина складывается. Новый маршрут стал чаще срабатывать по порогу задержки, поэтому система слишком рано переводит запросы на запасную модель. Ошибок мало, потому что дорогая модель отвечает стабильно. Но она думает дольше и отдает более длинные ответы. Отсюда сразу две проблемы: растет p95, и счет за токены тоже ползет вверх.

Дежурный не спорит с графиками и не ищет идеальную причину. Он делает два обратимых шага. Сначала возвращает прошлый маршрут для основного типа запросов. Потом режет max_tokens до безопасного лимита, который уже был в проде до релиза. Это грубая мера, но ночью она часто лучше красивой гипотезы.

Через 10 минут метрики начинают выправляться. p95 спускается сначала до 8 секунд, потом ниже. Средний размер ответа падает, доля дорогой модели возвращается к обычному уровню, стоимость за минуту тоже идет вниз. Ошибки почти не меняются, и это хороший знак: команда поправила именно маршрут и длину ответа, а не замаскировала сбой повторами.

После этого дежурный фиксирует три факта в журнале: какой релиз вышел, какой fallback включился и какой лимит max_tokens вернули. Утром по этим трем строкам команда быстро найдет корень проблемы и обновит runbook так, чтобы следующий ночной сдвиг занял не 20 минут, а 5.

Где дежурные чаще всего ошибаются

Самая частая ошибка проста: человек начинает крутить все рычаги сразу. Меняет модель, снижает таймаут, правит rate limit, включает новый маршрут. Через пять минут уже непонятно, что помогло, а что добавило шум. Во время инцидента лучше делать одну правку за раз и сразу отмечать время.

Такой хаос дорого стоит. Если команда одновременно включила повторы и перевела трафик на более дорогую модель, сервис может снова отвечать, но счет вырастет так, что утром придется разбирать уже другой инцидент.

Среднее успокаивает слишком рано

Многие смотрят только на среднюю задержку. Это ловушка. Среднее может оставаться нормальным, пока p95 и p99 уже ушли вверх, а пользователи массово ждут дольше обычного.

Если дежурный видит "среднее 2 секунды" и успокаивается, он пропускает реальную проблему в хвостах распределения. Для сервисов с LLM это обычная история: часть запросов идет быстро, а длинные или сложные промпты застревают и портят опыт живым пользователям.

Еще один частый промах - лечить только ошибки и не смотреть на стоимость. Допустим, 5xx исчезли после переключения на другой маршрут. Хорошо. Но что случилось со стоимостью за 1K токенов, длиной ответов и числом повторных запросов? Иногда ошибка уходит только потому, что система начала отвечать длиннее, медленнее и дороже.

Переключение трафика без быстрой проверки качества

Во время инцидента хочется увести трафик на любой живой маршрут. Это понятно, но риск высокий. Другая модель может вернуть иной формат JSON, хуже держать инструкции или чаще пропускать обязательные поля. Если смена провайдера занимает минуты, это удобно, но быстрая проверка качества все равно нужна.

Обычно хватает короткого прогона на нескольких реальных запросах: один короткий, один длинный, один с жестким форматом ответа. Это занимает меньше времени, чем разбор сломанной интеграции после поспешного переключения.

И последняя ошибка, самая скучная и самая дорогая: дежурный не оставляет точную запись своих действий. Без отметок по времени команда потом спорит, когда вырос p99, кто включил повторы и после какой правки подскочила цена. Поэтому runbook должен требовать простую запись: что изменили, во сколько и какой эффект был через 2-3 минуты.

Короткий чек-лист перед эскалацией

Эскалация без фактов только добавляет шум. Если дежурный пишет "сервис падает", владелец сервиса сначала задаст пять уточняющих вопросов, и вы потеряете время. Перед сообщением соберите короткую сводку, по которой можно сразу принять решение.

Сначала зафиксируйте точное время начала и текущий масштаб. Нужна одна строка: когда пошел первый скачок, какой показатель вышел за норму, сколько запросов или клиентов это уже затронуло. Разница между "ошибки с 02:14" и "что-то странное ночью" огромная.

Потом отделите главный симптом от сопутствующего. Часто вместе растут и ошибки, и задержка, и расходы, но почти всегда один сигнал уходит вверх сильнее остальных. Если p95 вырос вдвое, а ошибки почти не изменились, это один сценарий. Если стоимость запроса резко выросла при том же трафике, ищите другую модель, другого провайдера, fallback или рост max_tokens.

Перед эскалацией проверьте пять вещей:

• есть время начала, текущий error rate, p95 или стоимость на запрос
• понятно, что растет сильнее всего: ошибки, задержка или расход
• видно, какие модели, API-ключи, провайдеры и клиенты попали в инцидент
• уже выполнено одно безопасное действие, и его эффект измерили через 2-3 минуты
• владелец сервиса получил короткое сообщение с цифрами и следующим шагом

Один быстрый шаг нужен почти всегда. Можно убрать дорогой fallback, перевести часть трафика на соседнюю модель, снизить rate limit для шумного клиента или временно отключить длинные ответы. Важен не сам шаг, а измеримый результат: стало лучше, хуже или без изменений.

Если трафик идет через единый шлюз, полезно сразу смотреть срез по модели, провайдеру и ключу. Иногда проблема не во всем сервисе, а в одном маршруте или одном клиентском ключе. Это сильно меняет эскалацию.

Сообщение владельцу сервиса должно помещаться в 4-5 строк. Например: "02:14 начался рост 5xx, сейчас 12% запросов с ошибкой. Затронуты Qwen 3 и DeepSeek V3.2 у двух клиентов. Переключили 30% трафика на резервный маршрут, за 3 минуты error rate снизился до 7%. Нужна проверка лимитов у провайдера и решение по полному переключению".

Что добавить в runbook после инцидента

После инцидента runbook лучше править сразу, пока дежурный помнит, где он потерял время. Если человек 10 минут искал нужный график, вспоминал команду для переключения маршрута или сверялся с чатом, проблема уже в документе.

Сначала внесите точные пороги. Не общие фразы, а числа: какой процент 5xx считать аварией, какая p95 latency уже требует переключения, какой рост расходов за 10 минут считать ненормальным, при каком числе 429 нужно проверять лимиты. Рядом запишите команды, названия дашбордов и снимки графиков в норме и во время сбоя. Дежурный должен сразу видеть, куда смотреть первым.

Разделите runbook по типу сбоя

Один общий документ на все случаи быстро путает. Лучше держать отдельные ветки для ошибок, цены, задержки и упора в лимиты. Симптомы могут быть похожими, но первые действия разные.

Рост цены часто связан не с поломкой модели, а с длинными ответами, отключившимся кешем, сменой маршрута на более дорогую модель или повторными попытками. Рост задержки чаще ведет к проверке провайдера, длины очереди, таймаутов и размера ответа. Если все это лежит в одном разделе, дежурный начинает метаться между шагами.

Для каждого маршрута укажите основную модель, запасную модель и допустимую деградацию. Например, можно временно снизить max_tokens, отключить тяжелый reasoning, упростить формат ответа или перейти на более быструю модель с чуть худшим качеством. В runbook лучше прямо писать предел: что можно ухудшить, а что трогать нельзя.

Если вы работаете через AI Router, добавьте еще три пункта: где смотреть аудит-логи, как проверять маршрутизацию по провайдерам и какие лимиты стоят на уровне ключа. Это помогает быстро отделить сбой у внешнего провайдера от локального всплеска нагрузки или упора в rate limit у конкретного сервиса.

Обновляйте runbook сразу после инцидента

После инцидента хватает короткого разбора на 15-20 минут. Зафиксируйте, какой сигнал заметили поздно, какой шаг сработал сразу, что оказалось лишним и чего не хватало на экране дежурного.

Если ночью сервис начал сыпать 429, а команда спасла ситуацию переводом части трафика на запасную модель, этот путь нужно записать в runbook в виде конкретных действий. Не в памяти одного инженера, а в документе, который другой человек откроет в 03:00 и выполнит без догадок.

Командам, которые уже строят такую схему через AI Router, проще держать один источник правды по маршрутам, аудит-логам и лимитам. Но даже с хорошим шлюзом runbook никто не отменял: в инциденте выигрывает не тот, у кого больше настроек, а тот, кто за первые 15 минут принимает одно верное решение за другим.