Дежурство по LLM-платформе: какие алерты будят зря

Почему ночные алерты ломают дежурство

Дежурство по LLM-платформе разваливается не в момент большой аварии, а раньше - когда пейджер будит из-за событий, которые почти не влияют на пользователей. Короткий всплеск ретраев, медленный ответ у одного провайдера или разовый рост 429 на фоне пакетной нагрузки не всегда требуют подъема всей смены. Но сон они уже ломают.

После нескольких таких ночей человек перестает верить сигналу. Вместо мысли "что сломалось?" появляется другая: "опять шум". Это опасный сдвиг. Доверие к алертам уходит быстрее, чем команда успевает переписать правила.

На LLM-платформе это особенно заметно. Один запрос проходит через роутинг, прокси, кэш, маскирование PII, провайдера модели и внутренние лимиты. Если система умеет переключать трафик и пользователь все равно получает ответ, отдельный сбой на одном участке не должен будить дежурного. Иначе десятки технических событий прячут один случай, где люди правда теряют ответы или ждут по 40 секунд.

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

Дальше команда начинает защищаться как может. Кто-то ставит mute на канал. Кто-то убирает звук звонков. Кто-то делает личные фильтры и оставляет только пару шаблонов. Формально дежурство есть. По факту система уже приучила людей реагировать медленнее.

Утром цена такого шума становится еще заметнее. Вместо разбора причин команда разгребает хвост уведомлений, ищет первый симптом и собирает картину по кускам. На это уходит час, иногда два. За это время никто не улучшает маршрутизацию, не чинит пороги и не убирает слабые места в мониторинге.

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

Что требует звонка ночью

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

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

• пользователи перестали получать ответы, или задержка ушла далеко выше нормы и держится дольше согласованного окна;
• 5xx идут не коротким всплеском, а серией на уровне сервиса, модели или маршрута;
• очередь запросов растет даже после автоскейла, и система не успевает разбирать хвост;
• роутер не уводит трафик с упавшего провайдера, хотя должен был переключиться автоматически;
• расход токенов или денег резко подскочил и это похоже на цикл ретраев, сломанный промпт или runaway job.

Хороший пример - падение одного внешнего провайдера. Если шлюз просто перевел трафик на другой маршрут и пользователи почти ничего не заметили, ночью будить некого. Если же reverse proxy продолжает слать запросы в мертвый апстрим, 5xx копятся, очередь распухает, а ответы не приходят, дежурный должен подняться сразу.

С задержкой правило такое же. Если p95 вырос с 4 до 6 секунд на десять минут, это неприятно, но не всегда повод для звонка. Если же типичный запрос, который обычно укладывается в 8-10 секунд, внезапно ждет 40 секунд, а потом падает по таймауту, это уже прямой удар по продукту.

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

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

Что лучше снять с пейджера

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

Одиночные 4xx почти никогда не требуют подъема команды. Пользователь мог отправить битый JSON, старый токен, слишком длинный prompt или просто гонять тесты из CI. Если таких ответов мало, они идут от одного клиента и не растут сразу по нескольким интеграциям, это задача на рабочее время.

Короткий всплеск задержки тоже часто шумит зря. Если p95 подпрыгнул на 2-3 минуты, но очередь не растет, таймауты не посыпались, а support молчит, система, скорее всего, переварила пик сама. Для LLM это обычная история: тяжелый батч, прогрев новой модели, краткий перекос в маршрутизации. Будить из-за такого вредно.

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

Предупреждения по диску и памяти с большим запасом тоже редко нужны ночью. Если диск занят на 70% и растет медленно, утром можно спокойно проверить retention логов, кэши и бэкапы. То же с памятью: разовый всплеск без OOM, рестартов и деградации ответа не требует звонка.

Небольшой дрейф качества, который виден только в offline eval, тоже не место на пейджере. Метрика могла просесть на пару пунктов после смены маршрута или новой версии prompt. Если пользователи не жалуются, бизнес-поток идет, а safety-фильтры не ломаются, это тема для дневного разбора, а не ночного инцидента.

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

Как собрать уровни алертов за один проход

Начинать стоит не с метрик, а с ночных рисков, на которые дежурный реально может повлиять за 10-15 минут. Для LLM-платформы это обычно отказ провайдера, всплеск 5xx на общем маршруте, массовые таймауты, падение собственной GPU-ноды или сбой, который ломает запросы у большого числа клиентов. Если ночью никто не может это исправить, пейджер тут бесполезен.

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

Один риск - одна метрика - одно действие

Для каждого ночного риска привяжите одну метрику и одно понятное действие. Не пять графиков и не длинный runbook, а самый короткий путь до решения.

Например, массовые 5xx по прод-трафику означают, что нужно переключить маршрут на резервного провайдера или собственную модель. Если таймауты выше порога на основном пуле, дежурный режет долю трафика на проблемный маршрут. Если падает GPU-хост с hosted-моделью, модель снимают из роута и переводят запросы на запасной вариант. А вот ошибка в биллинге или логировании, при которой запросы клиентов продолжают проходить, обычно должна уйти в чат и дождаться утра.

Дальше задайте окно проверки. Почти весь минутный шум исчезает, если смотреть не на одну точку, а на 5-10 минут подряд. Задержка выше порога три минуты из пяти - это сообщение в чат. Та же проблема держится 10 минут и режет успех запросов - уже звонок.

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

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

Смотрите на весь путь запроса

При дежурстве по LLM-платформе одна общая метрика по ошибкам почти всегда врет. Запрос ломается не в "платформе целиком", а на конкретном участке: на входном лимите, в роутере, в очереди, у провайдера, на маскировании PII или уже после ответа модели. Если вы видите только один красный график, ночью он будит всех подряд и почти ничего не объясняет.

Разбейте путь запроса на отдельные точки и считайте их по отдельности. Для LLM-шлюза обычно хватает пяти участков:

• входной контроль: rate limit, авторизация, размер запроса;
• роутер: выбор модели, провайдера и правила фолбэка;
• очередь и воркеры: сколько запрос ждет до отправки;
• провайдер: сетевые ошибки, 429, 5xx, обрывы стрима;
• внутренние шаги: маскирование PII, AI-Law метки, постобработка.

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

Таймауты тоже нужно считать по участкам. Фраза "средний ответ 18 секунд" мало помогает, если непонятно, где пропало время. Иногда провайдер отвечает за 2 секунды, а еще 12 секунд запрос стоит в очереди. Иногда очередь пустая, но роутер слишком долго ищет маршрут после серии фолбэков. Для ночного алерта полезнее пять коротких метрик, чем одна красивая сводка.

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

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

Пример ночной смены без лишних звонков

В 02:15 один из внешних провайдеров начал отдавать 429 на части трафика. Не на всем потоке, а только на запросах к нескольким моделям, где ночной батч неожиданно съел лимит быстрее обычного. Пользователи почти ничего не заметили, потому что роутер сразу стал уводить новые запросы на запасной маршрут.

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

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

Для ночи достаточно трех правил: звонить, если очередь держится выше порога несколько минут; звонить, если запасной маршрут тоже начал сыпаться; не звонить по каждому всплеску 429, если роутинг сам выровнял трафик.

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

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

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

Ошибки в правилах, из-за которых все просыпаются

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

Так бывает в схеме с единым OpenAI-совместимым endpoint. Если внешний провайдер начал отдавать 5xx, сначала пишет gateway, потом шумит worker, потом мониторинг приложения видит рост ошибок у клиента. Дежурному не нужны три одинаковых звонка. Нужен один корневой алерт и тихие зависимые уведомления без пейджера.

Не меньше вреда приносят пороги по среднему времени ответа. Среднее часто выглядит терпимо, даже когда хвост задержки уже развалился. Для LLM это обычная история: 80% запросов идут быстро, а длинные генерации или ответы от одного провайдера внезапно уползают в p95 и p99. Пользователи злятся, а правило молчит. Бывает и обратная ошибка: среднее слегка выросло на коротком всплеске, и система объявляет инцидент там, где влияния на продукт нет.

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

Хуже всего алерт без контекста. Сообщение вроде "latency above threshold" ночью почти бесполезно. Дежурному нужно сразу видеть, какой маршрут деградировал, какой провайдер задействован, как меняется success rate и что система уже пыталась сделать сама. Без этого первые минуты уходят не на действие, а на угадывание.

Плохой алерт сообщает, что график покраснел. Хороший алерт помогает принять первое решение.

Быстрая проверка перед запуском дежурства

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

Самая частая проблема простая: алерт срабатывает, а дальше никто не понимает, кто его берет и что делает в первые 10 минут. Если у правила нет владельца и явного действия, это не ночной пейджер, а шум. Для каждого сигнала должен быть понятный ответ: кто идет смотреть, в какой системе и какое решение он может принять до подъема всей команды.

Удобно пройтись по короткому списку:

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

Для LLM-систем это особенно важно. Если запрос идет через единый OpenAI-совместимый шлюз, а дальше маршрутизируется по разным моделям и провайдерам, один сбой легко дает россыпь копий: 5xx на шлюзе, рост таймаутов у провайдера, падение синтетики, ошибки в приложении. Дежурному не нужны четыре звонка об одной и той же поломке.

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

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

Что сделать дальше

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

Возьмите историю пейджера за последние 30 дней. Отметьте каждое срабатывание, после которого команда ничего не делала ночью. Это первый список на удаление, перевод в дневной канал или понижение уровня. Часто туда попадают короткие всплески задержки, единичные 5xx от провайдера и временный рост retry.

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

Отдельно договоритесь о двух неприятных темах: кто принимает решение по стоимости и кто будит команду из-за безопасности. Резкий рост spend, утечка PII в логах, сбой маскирования и проблемы с аудит-трейлами нельзя сваливать в один поток. Если ответственный не назначен заранее, ночью все спорят, а не чинят.

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

Если команде нужен единый OpenAI-совместимый эндпоинт с маршрутизацией между провайдерами, логами и биллингом внутри РФ, RU LLM может быть удобной точкой контроля. Особенно в сценариях, где важно менять base_url без переписывания SDK, кода и промптов и при этом держать логи и бэкапы в российских серверах.

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