Replay backlog: runbook безопасного восстановления live-data

Replay начинается не с кнопки «переиграть очередь», а с оценки разрыва. Пока команда не знает, какие события отсутствуют, какие производные состояния уже рассчитаны и где потребители успели принять решения на неполных данных, массовый replay способен увеличить ущерб.

Шаг 1. Зафиксировать границы backlog

Нужны начало и конец разрыва, затронутые partitions/competitions/providers и возраст самого старого необработанного события. Полезно отдельно считать ingest lag и processing lag: источник может уже присылать данные вовремя, а внутренний consumer всё ещё отставать.

Если порядок событий имеет значение, одного количества сообщений недостаточно. Нужны sequence/version markers или другой способ доказать, что восстановленный state соответствует целевой версии.

Шаг 2. Остановить рискованные производные действия

Перед replay определяют, какие downstream-компоненты безопасно продолжать, а какие надо ограничить. Например, аналитический dashboard может пережить задержку, а компонент, публикующий состояние рынка, требует более строгого контроля. Решение зависит от архитектуры; универсального правила «останавливать всё» нет.

Шаг 3. Проверить идемпотентность на малом диапазоне

Replay должен либо повторно применить событие без побочного эффекта, либо распознать уже обработанную версию. До большого прогона полезно выбрать небольшой диапазон и проверить duplicate handling, correction semantics и запись новых offset/checkpoint. Если повтор создаёт вторую бизнес-операцию, масштабировать replay нельзя.

Шаг 4. Восстанавливать приоритетами

Не всегда разумно обрабатывать backlog строго FIFO. В live-системе текущий матч может иметь больший пользовательский impact, чем давно завершившееся событие. Но приоритетная обработка безопасна только тогда, когда предметная модель позволяет не нарушить зависимости. Решение должно быть зафиксировано в incident log вместе с причиной.

Следят не только за скоростью «messages/sec», но и за нагрузкой на downstream: база данных, cache invalidation, pricing workers, API fan-out. Агрессивный replay, который обрушает зависимый сервис, превращает одну очередь в каскадный инцидент.

Шаг 5. Reconciliation — отдельная стадия

Нулевой backlog ещё не означает восстановление. После обработки сравнивают materialized state с authoritative snapshot или другим контрольным источником, проверяют пропуски/дубликаты и убеждаются, что клиентский контур видит актуальную версию. Только после этого снимают временные ограничения.

Exit criteria

• backlog обработан или остаток явно признан безопасным;
• возраст live-state вернулся в нормальный рабочий диапазон;
• reconciliation не показывает необъяснённых расхождений;
• downstream-сервисы не остаются в деградированном режиме;
• в incident record сохранены диапазон replay, версия инструмента и принятые решения.

Runbook полезно проверять на учебном сценарии заранее. Во время реального gap команда должна выбирать параметры восстановления, а не впервые выяснять, что replay tool не умеет dry-run или не показывает, какие сущности затронет.

После инцидента проверить сам инструмент replay

Если оператору пришлось вручную вычислять offsets, обходить ограничения или запускать несколько несвязанных команд, эти действия стоит превратить в требования к recovery tooling. Runbook не должен годами описывать опасную ручную процедуру как норму. Хороший итог инцидента — следующий replay требует меньше импровизации и оставляет более полный audit trail.

Throttle выбирают по самому хрупкому downstream

Скорость replay ограничивает не только broker. Если повторная обработка инвалидирует cache, пересчитывает derived tables или создаёт fan-out в API, узким местом станет другой слой. Перед большим прогоном полезно знать безопасную скорость и наблюдать saturation по всей цепочке. Автоматический throttle по downstream error/latency безопаснее фиксированного «максимального» значения, но его поведение тоже нужно проверить заранее, иначе recovery tool начнёт принимать неожиданные решения в инциденте.

Если backlog растёт быстрее, чем replay успевает его разбирать, команда должна отдельно решить вопрос текущего intake. Иногда полезно приоритизировать новые события и восстанавливать историю параллельно; иногда зависимость версий делает это опасным. Runbook должен явно описывать эту развилку.

После снятия ограничений стоит ещё некоторое время наблюдать повторный рост lag. Инцидент нельзя считать закрытым, если backlog просто временно обнулился, а первопричина продолжает накапливать новый хвост.

Очередь «в ноль» не является достаточным exit criteria

Consumer может быстро очистить backlog и при этом применить события в неправильной версии, пропустить correction или перегрузить downstream. Поэтому завершение recovery лучше подтверждать сверкой authoritative state и контрольных диапазонов. Перед запуском такого восстановления полезно проверить модель из ordering, dedup и replay: runbook должен использовать те же idempotency keys, правила corrections и checkpoints, что обычный live-path, а не отдельную «аварийную» логику.

Во время recovery важно ограничивать скорость не только по возможностям consumer, но и по состоянию downstream. Быстрый replay способен создать вторичный инцидент в cache, database или pricing service. Поэтому runbook полезно связывать с saturation-сигналами и иметь возможность временно снизить rate без потери checkpoint. Безопасное восстановление — это контролируемое приближение к актуальному состоянию, а не гонка за минимальным временем очистки очереди.