Модель в продакшене: мониторинг, инциденты, постмортемы

Что ломается после релиза LLM-сервиса и как это замечать: три слоя мониторинга, дрейф входов через PSI и тест Колмогорова — Смирнова на числах, момент поломки через CUSUM, алерты без шума, типичные инциденты, откат и канарейка, дежурство и постмортем без поиска виноватых по шаблону.

УРОКstage-11/11-1-real-work/04-production-incidents.mdx2 ч 30 минУрок 4 из 5

После урока вы сможете

Составить план мониторинга LLM-сервиса по трём слоям — техника, качество, данные — и объяснить, почему среднего мало
Посчитать PSI числового признака с бинами по квантилям и тест Колмогорова — Смирнова и понять, когда им верить
Найти момент деградации через CUSUM и построить алерт, который ловит инцидент и не будит дежурного по пустякам
Действовать в инциденте (откат, канарейка, A/B) и написать постмортем без поиска виноватых по шаблону

Зачем это нужно

Вот история из домашней работы этого урока. Ассистент поддержки маркетплейса на RAG спокойно работает три недели. В четверг в 15:00 команда выкатывает новую версию промпта: шесть примеров хороших ответов, тон стал лучше, регрессионный набор в CI зелёный. Сервис отвечает кодом 200, задержка в норме, ошибок в логах нет. Через четыре дня приходит жалоба клиента: «бот не находит ответы, которые есть в документах». Разбор покажет, что за семь суток плохой ответ получили 186 пользователей из 499, а у китайскоязычных запросов доля плохих ответов выросла с 11% до 55%.

Это типичный инцидент ML-системы. Обычный сервис ломается громко: падает, отвечает 500. ML-сервис чаще ломается тихо, как тихие баги из урока 11.1.2: всё работает, только ответы хуже. Поэтому мониторинг LLM-сервиса смотрит не только на технику, но и на качество и на данные.

Онлайн-метрики, трейсы, контрольную карту и PSI по категориям вы собрали в уроке 8.4.2. Здесь — работа дежурного инженера: от мониторинга и алертов до разбора, после которого инцидент не повторится.

Что мониторить: три слоя

flowchart LR
T["Техника<br/>задержка, ошибки, GPU, KV-кэш"] --> A["Алерты"]
Q["Качество<br/>отказы, дизлайки, судья, люди"] --> A
D["Данные<br/>дрейф входов и ответов"] --> A
A --> O["Дежурный"] --> M["Смягчение:<br/>откат, канарейка"]
M --> P["Постмортем"] --> X["Действия:<br/>тесты, алерты, процесс"]
X -.-> T
X -.-> Q
X -.-> D

Цикл эксплуатации: мониторинг → алерт → реакция → разбор → новые проверки, которые закрывают дыру

Слой	Что смотреть	Пример для LLM-сервиса	Когда узнаём
Техника	задержка p50/p95/p99 (TTFT и полное время), пропускная способность, доля ошибок и таймаутов, загрузка GPU, заполнение KV-кэша, длина очереди	p95 полного ответа вырос с 15 до 26 с	секунды
Качество	доля отказов, дизлайков, перегенераций и передач оператору, оценка LLM-судьи на 10–20% трафика, выборочная проверка людьми, жалобы	доля плохих по судье 8% → 22%	минуты (судья), дни (жалобы)
Данные	дрейф входов: длина, язык, тема, доля обрезанного контекста; дрейф ответов: длина, доля отказов, язык ответа не тот, что у вопроса	доля обрезанного контекста 0.4% → 31%	минуты

Технический слой SRE-инженеры Google описывают через четыре золотых сигнала: задержка, трафик, ошибки и насыщение. Для LLM-сервиса насыщение — это загрузка GPU и, главное, заполнение KV-кэша: когда он полон, новые запросы ждут в очереди. Задержки описывают перцентилями p95 и p99, а не средним, — это хвостовые задержки из урока 8.4.2.

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

Два правила для всех трёх слоёв:

Каждую метрику режут по версии модели и промпта, языку, теме. Средняя по сервису прячет сегмент, где всё сломалось: в истории выше русские запросы пострадали умеренно (9.5% → 16.7% плохих), а китайские — катастрофически.
Каждую выкатку пишут в лог — версию в каждой строке и событие в журнал изменений. Без этого разбор превращается в гадание.

vLLM из урока 7.1.2 сам отдаёт метрики в формате Prometheus: curl localhost:8000/metrics. Для дашборда хватит нескольких: vllm:num_requests_running и vllm:num_requests_waiting (сколько запросов считается и сколько ждёт), vllm:kv_cache_usage_perc (доля занятого KV-кэша, от 0 до 1), гистограммы vllm:time_to_first_token_seconds и vllm:e2e_request_latency_seconds. Загрузку и память каждой карты пишет nvidia-smi --query-gpu=index,utilization.gpu,memory.used --format=csv -l 5. Названия метрик меняются между версиями vLLM — сверяйтесь с выводом /metrics своей версии. Подробнее о машине — на странице «Ваша лаборатория».

Дрейф входов: PSI и тест Колмогорова — Смирнова

Дрейф данных — изменение распределения входов. В уроке 8.4.2 вы считали PSI для категорий (языков). Теперь — числовые признаки: длина входа в токенах, длина ответа, задержка.

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

Числа сначала раскладывают по бинам. Удобнее всего брать границы по квантилям эталонного периода: при четырёх бинах это 25-й, 50-й и 75-й перцентили прошлой недели. Тогда в эталоне в каждом бине ровно четверть значений, и пустых бинов там не бывает. Дальше — знакомая формула:

\mathrm{PSI} = \sum_i (a_i - e_i)\ln\frac{a_i}{e_i}.

Пример. На прошлой неделе доли по квартилям длины входа были $0.25, 0.25, 0.25, 0.25$ . На этой неделе в те же бины попало $0.10, 0.15, 0.25, 0.50$ : запросы стали длиннее. PSI $= (0.10-0.25)\ln 0.4 + (0.15-0.25)\ln 0.6 + 0 + (0.50-0.25)\ln 2 = 0.137 + 0.051 + 0 + 0.173 = 0.36$ — сильный дрейф по распространённому эмпирическому правилу (меньше 0.1 — нет, 0.1–0.25 — умеренный, больше 0.25 — сильный). Это договорённость практиков, а не статистический тест: у порогов нет p-value, и на малых выборках их приходится поднимать (ниже).

Три ловушки:

Пустой бин. Если в текущем периоде появилась новая категория (язык, которого не было), её эталонная доля 0, и $\ln(a/0)$ — бесконечность. Доли заменяют на маленькое $\varepsilon$ , например $10^{-4}$ . Но вклад новой категории тогда зависит от $\varepsilon$ : для доли 0.1 это $0.1 \cdot \ln(0.1/10^{-4}) \approx 0.69$ , а при $\varepsilon = 10^{-3}$ — около 0.46. Фиксируйте $\varepsilon$ и пишите его рядом с числом.
Маленькие выборки. Две выборки из одного и того же распределения по 200 значений при 10 бинах дают PSI в среднем около 0.09, а в 5% случаев больше 0.17 (проверено симуляцией). Это шум: оценка доли в каждом бине гуляет. Приближённо шум равен $(B-1)\left(\frac1n + \frac1m\right)$ для $B$ бинов. Пороги 0.1 и 0.25 придуманы для тысяч наблюдений — на сотнях их нужно поднимать.
Дрейф от вашей же выкатки. В истории из начала урока длина входа «выросла» на 2800 токенов, потому что вырос системный промпт. Самый сильный дрейф не обязательно пришёл извне.

Тест Колмогорова — Смирнова

тест Колмогорова — Смирнова сравнивает распределения без бинов. Эмпирическая функция распределения $F(x)$ — доля значений выборки, не больших $x$ . Статистика — наибольшее расстояние между двумя такими функциями:

D = \max_x \lvert F_a(x) - F_b(x) \rvert.

Пример: длины ответов в двух сменах $a = \{1, 2, 3, 4, 5\}$ и $b = \{3, 4, 5, 6, 7, 8\}$ (в сотнях токенов). В точке $x = 5$ : $F_a = 5/5 = 1$ , $F_b = 3/6 = 0.5$ , разница $0.5$ — больше, чем в любой другой точке, значит $D = 0.5$ . p-value даёт распределение Колмогорова: $\lambda = \sqrt{nm/(n+m)}\,D$ и $p = 2\sum_{k \ge 1}(-1)^{k-1}e^{-2k^2\lambda^2}$ . Здесь $\lambda = \sqrt{30/11}\cdot 0.5 \approx 0.83$ и $p \approx 0.50$ : на пяти и шести точках разница не значима. Формула асимптотическая, она точна для больших выборок; для таких крошечных scipy.stats.ks_2samp считает точное значение $p \approx 0.36$ — вывод тот же.

Обратная проблема — большой трафик. Две недели по 100 000 запросов, входы длиннее всего на 3%: симуляция даёт $D = 0.031$ и $p \approx 10^{-40}$ , а PSI — 0.005. При большом $n$ значим почти любой сдвиг: p-value отвечает «есть ли разница», а не «важна ли она» (урок 1.3.4).

	PSI	Тест КС
Признаки	числа (через бины) и категории	только числа
Отвечает на вопрос	насколько велик сдвиг	есть ли сдвиг вообще
На маленьких выборках	шумит, пороги нужно поднимать	честно говорит «не значимо»
На большом трафике	устойчив	значимо почти всё — смотрите на сам $D$
Типичное правило	больше 0.25 — разбираться	$D$ больше заданного порога и $p$ мал

Обе меры на NumPy — основа того, что вы напишете в домашней работе:

import numpy as np

def psi(e, a, eps=1e-4):
    e, a = np.asarray(e, float), np.asarray(a, float)
    e = np.maximum(e / e.sum(), eps)          # счётчики → доли; пустой бин → eps
    a = np.maximum(a / a.sum(), eps)
    return float(np.sum((a - e) * np.log(a / e)))

def psi_numeric(ref, cur, n_bins=10):
    edges = np.unique(np.quantile(ref, np.arange(1, n_bins) / n_bins))   # квантили ЭТАЛОНА
    count = lambda x: np.bincount(np.searchsorted(edges, x), minlength=len(edges) + 1)
    return psi(count(ref), count(cur))

def ks(a, b):
    a, b = np.sort(a), np.sort(b)
    grid = np.concatenate([a, b])
    fa = np.searchsorted(a, grid, side="right") / len(a)    # эмпирическая F(x)
    fb = np.searchsorted(b, grid, side="right") / len(b)
    return np.abs(fa - fb).max()

rng = np.random.default_rng(0)
week1 = rng.lognormal(np.log(3000), 0.4, 1000)              # длина входа, токенов
same = rng.lognormal(np.log(3000), 0.4, 1000)
longer = rng.lognormal(np.log(3000), 0.4, 1000) + 2800      # системный промпт вырос на 2800 токенов
print(f"та же неделя:  PSI = {psi_numeric(week1, same):.3f}, D = {ks(week1, same):.3f}")
print(f"промпт длиннее: PSI = {psi_numeric(week1, longer):.3f}, D = {ks(week1, longer):.3f}")

та же неделя:  PSI = 0.020, D = 0.052
промпт длиннее: PSI = 6.545, D = 0.799

side="right" в ks важен при повторах: $F(x)$ считается после всех значений, равных $x$ . Ответы LLM дрейфуют так же, как входы: длина ответа, доля отказов, доля ответов не на языке вопроса — это такие же признаки, и их сравнивают теми же мерами. Отдельно бывает дрейф понятий: входы те же, а правильные ответы изменились (новые тарифы, устаревшие документы). Его PSI не видит — только качество.

Когда именно сломалось: CUSUM

Дрейф отвечает на вопрос «что изменилось». Второй вопрос — «когда». Посуточная доля плохих ответов в истории выше: 11%, 7%, 13%, 7%… — а потом 22%, 24%, 28%. По дням ступеньку видно глазом, но по часам — нет. При семи запросах в час один плохой ответ из пяти — уже 20%, и почасовой ряд прыгает от нуля до 40% без всякого инцидента.

Это задача обнаружения точки изменения. Контрольная карта из урока 8.4.2 смотрит на каждую точку отдельно и ловит большие скачки. CUSUM (Пейдж, 1954) копит небольшие, но устойчивые отклонения по каждому запросу:

S_0 = 0, \qquad S_t = \max\bigl(0,\ S_{t-1} + x_t - p_0 - k\bigr),

где $x_t = 1$ для плохого ответа и 0 для хорошего, $p_0$ — нормальная доля плохих, $k$ — допуск, обычно половина сдвига, который хотим ловить. Тревога — когда $S_t > h$ . Начало изменения — первый запрос серии, в которой $S$ ни разу не обнулился.

Числа. Пусть $p_0 = 0.10$ , а ловить хотим рост до 0.25, тогда $k = 0.075$ . Плохой ответ добавляет к $S$ $1 - 0.175 = 0.825$ , хороший отнимает $0.175$ . В норме $S$ в среднем убывает: $0.1 \cdot 0.825 - 0.9 \cdot 0.175 = -0.075$ за запрос — и держится у нуля. При доле плохих 0.28 он растёт на $0.28 \cdot 0.825 - 0.72 \cdot 0.175 = +0.105$ за запрос и превысит $h = 8$ примерно за 76 запросов.

import numpy as np

def cusum(x, target, k, h):
    s, start = 0.0, 0
    for t, v in enumerate(x):
        s = max(0.0, s + v - target - k)
        if s == 0.0:
            start = t + 1                 # серия начнётся не раньше следующего запроса
        elif s > h:
            return t, start               # (момент тревоги, начало изменения)
    return None, None

rng = np.random.default_rng(1)
bad = np.concatenate([rng.random(600) < 0.10,     # 600 запросов в норме: 10% плохих
                      rng.random(300) < 0.28])    # потом 28% плохих
print(cusum(bad.astype(float), target=0.10, k=0.075, h=8))

(656, 600)

Тревога через 56 запросов после поломки, а начало найдено точно — запрос 600. Разница между моментом тревоги и началом важна для разбора: искать причину нужно у начала, а не у момента, когда заметили.

Алерты без шума

Алерт будит человека. Если он срабатывает зря, человек привыкает его игнорировать. Это усталость от алертов, и в истории из начала урока она сыграла роль: почасовой алерт «p95 задержки больше 25 с» 9 и 10 сентября сработал дважды — ночью по единственному медленному запросу и на 50-минутном всплеске после перезапуска сервера. Его перевели в ежедневную сводку, где до инцидента он отметился ещё пять раз без всяких проблем с качеством, и рост p95 с 15 до 26 с после выкатки никто не увидел.

Почему простые пороги шумят — это множественные сравнения: проверка раз в час — 720 проверок в месяц. Даже если каждая ошибается с вероятностью 1%, ложных тревог будет около семи. Что помогает:

Алертить на симптомы, а не на причины. Пользователю важна доля плохих ответов и время ответа, а не загрузка GPU. Причины — на дашборд, симптомы — в алерты. Каждый алерт должен требовать действия, и у каждого должен быть ранбук: что проверить и как откатить.
Порог, который зависит от числа запросов. Не «больше 25%», а $p_0 + z\sqrt{p_0(1-p_0)/n}$ : ночью, при малом $n$ , порог выше. Плюс минимальное $n$ в окне.
Длинное окно и несколько проверок подряд. Окно в сутки гасит часовые всплески и суточную сезонность, требование «три часа подряд» отсекает одиночные выбросы.
Два окна — для большого трафика. В книге Google по SRE алерты строят по SLO и бюджету ошибок. Если SLO — 99% хороших ответов за 30 дней, бюджет — 1% запросов. Скорость расхода (burn rate) 14.4 означает, что за час уходит $14.4 / 720 = 2\%$ месячного бюджета. Алерт горит, когда скорость высокая и в длинном окне (час), и в коротком (5 минут): длинное даёт уверенность, короткое — что проблема ещё идёт.
Сезонность. Если в выходные доля плохих всегда выше (другие пользователи, другие вопросы), сравнивайте с тем же днём недели, а не с прошлым часом.

Что это даёт на данных домашней работы (около 7 запросов в час): правило «доля плохих за 24 часа выше $p_0 + 3.5\sqrt{p_0(1-p_0)/n}$ , не меньше 30 запросов в окне, три часа подряд» срабатывает через 9 часов после выкатки и ни разу за три недели до неё — включая всплеск, где за час таймаутом закончились 4 запроса из 9. Девять часов — медленно, но это вместо четырёх дней до жалобы. При тысячах запросов в минуту окна можно сжать до минут.

Типичные инциденты LLM-сервиса

Что случилось	Симптомы	Где видно раньше всего	Первое действие
Обновили модель (свою или провайдер под тем же именем)	другая длина ответа, больше отказов, ломается JSON	дрейф ответов, доля невалидного JSON	откат версии; закрепить снимок модели (урок 8.4.1)
Обновили промпт	ступенька длины входа, обрезка контекста, отказы в одном сегменте	дрейф входа, срез по версии промпта	откат промпта, сравнение внутри сегментов
Выросла длина контекста, кончился KV-кэш	растут очередь и TTFT p99, падает пропускная способность, запросы вытесняются	`kv_cache_usage_perc` около 1, очередь	лимит длины входа, меньше параллельных запросов, вторая реплика
Поменялся формат входных данных	HTML вместо текста, другая кодировка, пустые поля	дрейф длины и языка, валидатор схемы	откат источника или фильтр; контракт данных (урок 11.1.1)
Сломался внешний инструмент агента	ошибки в одной теме, агент зацикливается или выдумывает	доля ошибок инструмента по темам	отключить инструмент и честно отказывать; тест контракта инструмента
Кончились лимиты или ключ API провайдера	ошибки 429 и 401, повторы	доля ошибок по кодам	резервный провайдер, лимиты на пользователя (урок 8.4.3)

Про KV-кэш — на числах из урока 8.4.3. У Qwen3-8B около 144 КБ кэша на токен, и 32 пользователя с документами по 8000 токенов требуют $32 \cdot 8000 \cdot 144\ \text{КБ} \approx 37$ ГБ. На RTX 4080 после весов (16.4 ГБ) при gpu-memory-utilization 0.9 остаётся $28.8 - 16.4 \approx 12$ ГБ, а за вычетом служебных буферов vLLM — около 11 ГБ, порядка 70–75 тысяч токенов (оценка из урока 7.1.2), то есть 8–9 таких пользователей. Остальные ждут, а vLLM вытесняет часть запущенных запросов (preemption). Модель не стала хуже, но сервис для пользователя сломался. Сломанный инструмент агента вы разберёте в практике ниже.

Что делать во время инцидента

flowchart TD
A["Алерт или жалоба"] --> B["Дежурный подтверждает:<br/>реальная проблема?"]
B -->|нет| N["Закрыть, поправить алерт"]
B -->|да| C["Оценить влияние:<br/>кто и сколько пострадал"]
C --> D{"Была выкатка<br/>незадолго до начала?"}
D -->|да| R["Откат"]
D -->|нет| F["Смягчение: отключить функцию,<br/>лимиты, резервный провайдер"]
R --> E["Диагностика: срезы, дрейф, трейсы"]
F --> E
E --> V["Проверить восстановление по метрикам"]
V --> P["Постмортем"]

Порядок действий: сначала смягчить, потом диагностировать

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

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

Канарейка вместо «сразу на всех». Канареечный выпуск из урока 8.4.2 — лучшая защита от инцидентов с выкаткой. Новая версия получает 10% трафика, метрики сравнивают по версиям. Сколько ждать — считается как в уроке 1.3.4. При 4000 запросов в сутки на канарейку за сутки придёт 400. Если старая версия даёт 10% плохих ответов, а новая 20%, стандартная ошибка разницы $\sqrt{0.1 \cdot 0.9 / 3600 + 0.2 \cdot 0.8 / 400} \approx 0.021$ , и разница 0.10 — почти пять стандартных ошибок. Суток хватит, чтобы остановить выкатку, и пострадают 10% пользователей, а не все.

A/B-тест — когда нужно не поймать поломку, а принять решение по небольшому эффекту: «v13 лучше по тону, но не хуже ли по точности?». Рандомизация по пользователям, размер выборки заранее по формуле мощности из урока 1.3.4, одна главная метрика и сегменты, которые смотрим обязательно.

Как искать причину. Найдите момент начала (CUSUM), выпишите все изменения рядом с ним (выкатки, работы, новые клиенты) и проверяйте каждое по одному вопросу: начался ли рост сразу после него, внутри сегментов? Если после выкатки выросла доля китайских запросов, а на китайском всегда хуже, рост средней доли плохих может быть просто сменой состава. Проверка: посчитайте, сколько плохих ответов было бы после, если бы доля плохих внутри каждого языка не изменилась, и сравните с наблюдаемым. В домашней работе ожидалось 39, наблюдалось 97 — значит, сломалось внутри языков, и дело не только в составе.

Постмортем без поиска виноватых

Постмортем — письменный разбор после инцидента. В книге Google по SRE главная идея сформулирована так: постмортем ищет, что в системе и процессе позволило ошибке случиться, и не ищет, кого наказать. Если за ошибку наказывают, люди скрывают ошибки, и следующий разбор начнётся без половины фактов. «Инженер не проверил длинные запросы» — тупик. «Почему системе было легко не проверить длинные запросы?» — начало полезного ответа.

Вместо	Пишите
Инженер выкатил промпт, не проверив длинные запросы	В регрессионном наборе нет запросов длиннее 4000 токенов, поэтому CI не мог заметить обрезку контекста
Дежурный проморгал рост задержки	Алерт на p95 был шумным и переведён в сводку; рост p95 после выкатки никто не видел
Причина — человеческий фактор	Выкатка шла сразу на 100% трафика без сравнения версий

Шаблон. Его же вы заполните в домашней работе:

Кратко — 3–5 предложений для руководителя: что, когда, насколько плохо, сколько длилось.
Влияние — числа: запросы, плохие ответы сверх нормы, пострадавшие пользователи, сегменты.
Хронология — события с датой и временем по порядку: выкатки, первые признаки в данных, когда узнали, гипотезы, откат, восстановление.
Причина — главная причина с механизмом и доводами, отдельно — способствующие факторы.
Почему не поймали раньше — какие защиты должны были сработать и почему не сработали.
Что помогло — что сохранить.
Что меняем — таблица действий: что, тип (обнаружение, предотвращение, смягчение), владелец, срок.
Уроки — 2–3 мысли на будущее.

«Пять почему» помогает дойти от симптома до системной причины. Плохие ответы — почему? Обрезался контекст. Почему? Вход не влез в бюджет 7168 токенов. Почему? Системный промпт вырос с 700 до 3500 токенов, а бюджет никто не пересчитал. Почему CI не заметил? В наборе нет длинных запросов. Почему не заметили в продакшене? Не было алерта на качество и канарейки, а алерт по задержке заглушили из-за шума. Каждый ответ даёт действие: длинные запросы в набор, бюджет от длины промпта, алерт на долю плохих, канарейка, тихий алерт по задержке.

Действие без владельца и срока не будет сделано, а «быть внимательнее» — не действие. Действие — «добавить в регрессионный набор 60 запросов длиной 4000–7000 токенов; владелец — команда ассистента; срок — 16 октября».

Практика

Агент поддержки три недели отвечает на вопросы о заказах, доставке, аккаунте и курсах валют; для последних он вызывает внешний API. Лог генерируется в коде с фиксированным seed. Посчитайте PSI каждого признака по неделям против первой, найдите признак с дрейфом и день, с которого выросла доля ошибок. Для дня используйте офлайн-метод «лучший разрез»: перебрать все точки, разрезать ряд на две части и выбрать разрез с минимальной суммой квадратов отклонений от средних частей.

Лог агента: дрейф по неделям и день поломкиnumpy, pandas · нужен интернет7 тестов

import numpy as np
import pandas as pd


def make_log(seed=7):
    """Синтетический лог агента поддержки за три недели (2–22 марта 2026), по строке на запрос.

    Столбцы: ts, lang, cat, in_tok, out_tok, error (1 — запрос закончился ошибкой).
    Агент для вопросов о курсах валют (cat == "fx") вызывает внешний API. Числа выдуманы.
    """
    rng = np.random.default_rng(seed)
    start = pd.Timestamp("2026-03-02")
    parts = []
    for day in range(21):
        n = 130 if day % 7 < 5 else 70                                   # в выходные запросов меньше
        secs = np.sort(rng.integers(0, 86400, n))
        p_zh = 0.08 + 0.32 * min(max((day - 7) / 10, 0), 1)              # с 9 марта растёт доля китайского
        u = rng.random(n)
        lang = np.where(u < p_zh, "zh", np.where(u < p_zh + 0.07, "en", "ru"))
        cat = rng.choice(["orders", "delivery", "fx", "account"], n, p=[0.3, 0.3, 0.2, 0.2])
        in_tok = rng.lognormal(np.log(1800), 0.35, n).astype(int)
        out_tok = rng.lognormal(np.log(220), 0.5, n).astype(int) + 10
        p_err = np.full(n, 0.04 + 0.01 * (day % 7 >= 5))
        if day >= 15:                                                    # 17 марта внешний API сменил формат
            p_err = np.where(cat == "fx", 0.8, p_err)
        error = (rng.random(n) < p_err).astype(int)
        ts = start + pd.Timedelta(days=day) + pd.to_timedelta(secs, unit="s")
        parts.append(pd.DataFrame({"ts": ts, "lang": lang, "cat": cat, "in_tok": in_tok,
                                   "out_tok": out_tok, "error": error}))
    return pd.concat(parts, ignore_index=True)


def psi(expected, actual, eps=1e-4):
    """PSI = Σ (a − e) · ln(a / e) по долям.

    expected, actual — доли или счётчики (счётчики нормируйте к сумме 1). Доли меньше eps замените на eps,
    иначе пустой бин даст ln 0. Пример: psi([0.5, 0.3, 0.2], [0.3, 0.3, 0.4]) ≈ 0.2408.
    """
    # TODO
    raise NotImplementedError


def feature_psi(ref, cur, n_bins=5, eps=1e-4):
    """PSI одного признака между эталонной (ref) и текущей (cur) выборками (pandas Series).

    Числовой признак (pd.api.types.is_numeric_dtype): внутренние границы — квантили ref на уровнях
    1/n_bins, …, (n_bins−1)/n_bins, склеенные np.unique; бины (−∞, e1], (e1, e2], …, (ek, +∞).
    Номер бина — np.searchsorted(edges, x, side="left"), счётчики — np.bincount(..., minlength=len(edges) + 1).
    Остальные признаки — категории: объединение значений ref и cur, счётчики через value_counts().reindex(...).
    """
    # TODO
    raise NotImplementedError


def weekly_psi(df, features, n_bins=5):
    """PSI каждой недели против первой.

    Неделя — (ts − полночь первого дня).days // 7 + 1. Возвращает DataFrame: индекс — номера недель 1, 2, …,
    столбцы — features, значения — PSI признака этой недели против недели 1 (у недели 1 — нули).
    """
    # TODO
    raise NotImplementedError


def daily_error_rate(df):
    """Доля ошибок по дням: Series с индексом — полночь каждого дня (Timestamp)."""
    # TODO
    raise NotImplementedError


def change_day(rates, min_size=3):
    """Лучший разрез ряда на две части: день, с которого начинается правая часть.

    Для каждого k от min_size до len − min_size: стоимость = сумма квадратов отклонений левой части от её
    среднего + то же для правой. Верните rates.index[k] с минимальной стоимостью.
    """
    # TODO
    raise NotImplementedError


try:
    df = make_log()
    table = weekly_psi(df, ["lang", "cat", "in_tok", "out_tok"])
    print(table.round(3))
    rates = daily_error_rate(df)
    print("Ступенька ошибок начинается", change_day(rates).date())
except NotImplementedError:
    print("Допишите функции — и здесь появится таблица дрейфа по неделям и день ступеньки.")

Что должно получиться. К третьей неделе сильно сдвинулся язык: PSI 0.54, доля китайского выросла с 9% до 39%. Тема, длина входа и длина ответа стабильны (PSI меньше 0.02). Ступенька ошибок — 17 марта: до этого доля ошибок по дням была от 2% до 9%, а с 17-го — от 13% до 23%. Соблазнительный вывод «ошибки из-за китайских клиентов» неверен: язык менялся плавно с 9 марта, а ошибки выросли скачком. Срез df.groupby("cat")["error"].mean() по третьей неделе покажет, что ошибок много только в теме fx (65% против 3–6% в остальных) — сломался API курсов валют. Дрейф и инцидент — разные вещи, и их надо проверять разными инструментами.

s11-hw03-incident — «Разбор инцидента: модель деградировала в продакшене». Лог RAG-ассистента за четыре недели (4216 запросов) и журнал изменений. В данные подложен инцидент с одной главной причиной и отвлекающими факторами: сезонность, обновление модели, постепенный дрейф языка, короткий всплеск задержки. Уровни: Simple — PSI и тест КС на ручных примерах; Medium — сравнение периодов и детектор точки изменения; Strong — алерт без ложных срабатываний и поиск причины (тесты проверяют и на второй выгрузке с другими датами); Boss — POSTMORTEM.md по шаблону этого урока и оценка «что если». Проверка из корня репозитория: python homework/check.py s11-hw03-incident, условие — homework/s11-hw03-incident/README.md, всё на CPU.

Китайский угол: «фупань», «выпуск в оттенках серого» и «Соловей»

«Фупань». Разбор инцидента в китайских IT-компаниях обычно называют «фупань сбоя» — «разбор сбоя». Само слово (буквально «переиграть партию») пришло из го (вэйци): после партии игроки заново расставляют ходы на доске и обсуждают, где ошиблись. Метафора точная: постмортем — это не поиск проигравшего, а повтор партии ход за ходом, чтобы в следующей сыграть лучше. Китайское издание книги Google о SRE вышло под названием, которое можно перевести как «SRE: эксплуатация по-гугловски», — по ней многие команды строили свои процессы дежурств и разборов.

Словарь дежурного. Алерт по-китайски — буквально «предупреждение о тревоге», дежурство — «нести вахту», откат — «откатиться назад», а усталость от алертов так и называют — «усталость от тревог». Канареечный выпуск чаще называют «выпуском в оттенках серого»: новая версия получает трафик постепенно, от малой доли к полной, — между «чёрным» и «белым».

Nightingale («Соловей»). Открытая система мониторинга с упором на алерты. По README проекта, её разработал и открыл DiDi, а 11 мая 2022 года передал в комитет по открытому исходному коду Китайской компьютерной федерации (CCF ODTC). В README_zh.md — правила подавления, раздел о шумоподавлении, эскалации и совместной работе и «самолечение» алертов: по алерту запускается заранее написанный скрипт. Хороший пример того, как зрелая система борется с усталостью от алертов. Эксплуатацию LLM-приложений разбирает и глава 4.3 «LLM-приложение в продакшене» курса Alibaba Cloud ACP.

Проверь себя

Проверь себя6 вопросов

1 Квартили длины входа прошлой недели делят её на 4 бина по 25%. На этой неделе в те же бины попало 10%, 15%, 25% и 50% запросов. Чему равен PSI? (округлите до 2 знаков)

2 Сравнили длину входа за две недели по 100 000 запросов:

D = 0.03

p \approx 10^{-40}

, PSI = 0.005. Что из этого следует?Срочно будить дежурного: распределение изменилосьСдвиг статистически значим, но практически мал; записать и следить, не растёт лиТест посчитан неверно: при таком p-value PSI не может быть маленькимВерить только тесту КС, PSI на больших выборках врёт

3 Почасовой алерт «доля плохих ответов больше 25%» при 7 запросах в час будит дежурного дважды в неделю, а настоящих инцидентов не было. Что уменьшит ложные тревоги и не ослепит алерт?Можно выбрать несколько ответовДлинное окно (например, сутки) и минимальное число запросов в нёмПорог, который зависит от числа запросов:

p_0 + z\sqrt{p_0(1-p_0)/n}

Требование, чтобы условие держалось несколько проверок подрядПеревести алерт в еженедельную сводкуСнизить порог до 15%

4 После выкатки нового промпта доля отказов выросла с 4% до 9%. В те же дни доля китайских вопросов выросла с 10% до 30%, а на китайском отказов всегда было больше. Какая проверка отделит эффект промпта от смены состава?Сравнить долю отказов внутри каждого языка до и после выкатки (сколько отказов ожидалось бы при прежних долях по языкам)Посчитать PSI языка между неделямиСравнить среднюю длину ответа до и послеПодождать месяц и посмотреть, не пройдёт ли само

5 Какая формулировка подходит для постмортема без поиска виноватых?Инженер выкатил промпт, не проверив длинные запросыВ регрессионном наборе нет запросов длиннее 4000 токенов, поэтому CI не мог заметить обрезку контекстаПричина инцидента — человеческий факторДежурный проморгал рост задержки

6 Пользователи стали присылать документы по 8000 токенов вместо 2000. В сервисе на vLLM TTFT p99 вырос в пять раз, очередь растёт, vllm:kv_cache_usage_perc держится около 1.0, судья качество не изменил. Что происходит?KV-кэш заполнен: запросы ждут места и вытесняются, одновременно обслуживается меньше пользователейМодель деградировала, нужен откат моделиСломался LLM-судьяДрейф понятий: правильные ответы изменились

Итоги

Мониторинг LLM-сервиса — три слоя: техника (задержка p95/p99, ошибки, KV-кэш, очередь), качество (отказы, дизлайки, судья, люди) и данные (дрейф входов и ответов). Каждую метрику режут по версии и сегментам, каждую выкатку пишут в лог.
PSI числового признака считают по бинам из квантилей эталона, пустой бин заменяют на $\varepsilon$ ; на маленьких выборках PSI шумит. Тест КС не требует бинов, но на большом трафике значим почти любой сдвиг — смотрите на $D$ .
CUSUM находит момент начала устойчивого роста доли плохих ответов, а не момент, когда его стало видно. Алерт без шума — длинное окно, порог от $n$ , несколько проверок подряд, только прошлые данные; при большом трафике — два окна и бюджет ошибок.
В инциденте сначала смягчают (откат за минуты), потом разбираются. Канарейка на 10% трафика ловит плохую выкатку за сутки, пока пострадала малая доля пользователей. Причину проверяют внутри сегментов, чтобы не спутать поломку со сменой состава.
Постмортем — без поиска виноватых: кратко, влияние, хронология, причина, почему не поймали раньше, что помогло, действия с владельцем и сроком, уроки.

Дальше: урок 11.1.5 — деньги и компромиссы. Сколько стоит LLM-функция через API и на своих GPU, где точка безубыточности и как обосновать решение руководителю на одной странице.