Runbook очереди уведомлений

Цель

Документ определяет действия ответственного при тревогах закрытого health-endpoint и запрещает массовые или неподтверждённые повторные отправки.

Web3Forms остаётся независимым рабочим каналом. Проблема Supabase или Telegram не должна блокировать получение email-заявки.

Уровни состояния

OK

Условия:

status = ok;
массив alerts пуст;
нет failed;
нет зависших sending;
очередь pending ниже порога.

Действие: никаких изменений. Зафиксировать только регулярную успешную проверку в системе мониторинга.

Warning

Возможные коды:

failed_present;
pending_backlog;
attempts_elevated.

Действия:

не включать hybrid, если он ещё не принят;
проверить Telegram-конфигурацию и события в доверенной среде;
установить, относится ли проблема к одной тестовой заявке или очереди;
не копировать телефон, имя и текст заявки в issue;
не выполнять retry без сверки request ID в базе и Telegram;
при подтверждённом failed использовать только broker-notification-retry и код причины из whitelist;
повторить health-запрос после исправления.

Critical

Возможные коды:

stale_sending;
failed_critical.

Действия:

оставить или вернуть сайт в режим web3forms с пустым endpoint;
не выполнять массовый retry;
проверить, не принял ли Telegram сообщение до аварийного завершения функции;
определить число затронутых записей через агрегаты, без выгрузки персональных данных;
остановить дальнейшее развёртывание Supabase-канала;
устранить причину конфигурации, RPC или Telegram;
обрабатывать подтверждённые failed по одной заявке;
повторить smoke и health-проверку;
зафиксировать технический итог в issue №7 без идентификаторов клиента.

Матрица кодов

Код	Возможная причина	Первое действие	Retry
`failed_present`	единичная ошибка Telegram или сводки	проверить `notification_last_error` в доверенной среде	только после сверки
`failed_critical`	массовая ошибка конфигурации или Telegram	остановить включение Supabase, проверить secrets и доступность	массовый retry запрещён
`stale_sending`	функция прервалась во время доставки	сверить request ID в Telegram и базе	штатное восстановление или ручное решение
`pending_backlog`	handler не забирает очередь или Telegram выключен	проверить deploy, secrets и claim RPC	retry не требуется до диагностики
`attempts_elevated`	таймауты, повторы или аварийное окно	проверить события и повторные вызовы	только подтверждённый failed

Проверка перед ручным retry

Обязательно подтвердить:

статус заявки failed;
Telegram-сообщение с этим request ID отсутствует;
причина ошибки устранена;
выбран корректный reason code;
оператор работает с одной конкретной заявкой;
NOTIFICATION_ADMIN_TOKEN не выводится в командную историю общего доступа;
результат будет проверен повторным health-запросом.

Запрещено:

переводить sent в retry;
повторять disabled;
вручную менять pending или активный sending;
передавать свободный комментарий администратора;
публиковать UUID, request ID, телефон или текст заявки в issue;
выполнять циклический или массовый вызов retry-функции.

Проверка после retry

Проверить:

HTTP-ответ административной функции;
notification_status;
увеличение notification_manual_retry_count ровно на один;
наличие notification_retry_requested;
наличие notification_retry_sent или notification_retry_failed;
одно сообщение в Telegram;
отсутствие персональных данных в техническом событии;
исчезновение или изменение соответствующего health alert.

Работа с зависшим sending

stale_sending означает, что sending старше 15 минут.

Перед восстановлением:

проверить Telegram по request ID;
проверить время notification_attempted_at;
проверить события notification_sent и notification_failed;
учитывать аварийное окно: Telegram мог принять сообщение до фиксации sent.

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

Закрытие инцидента

Инцидент можно закрыть, когда:

health вернулся в ok либо согласованный warning;
новые заявки не накапливаются в pending;
нет зависших sending;
причина ошибки зафиксирована техническим кодом;
duplicate-проверка не создаёт второе сообщение;
Web3Forms продолжает доставлять email;
секреты не попали в логи, issue или репозиторий;
ответственный подтвердил результат.

Эскалация

Эскалация обязательна, если:

critical сохраняется после исправления;
несколько заявок получили одинаковую ошибку;
обнаружена возможная повторная отправка;
есть подозрение на раскрытие token;
health endpoint возвращает персональные данные;
Web3Forms также перестал работать.

При подозрении на утечку token его необходимо немедленно заменить, удалить старое значение из окружения и повторить smoke авторизации.

Откат

Безопасный откат:

lead_capture:
  mode: "web3forms"
  endpoint: ""

Дополнительно:

отключить monitor/admin secrets при необходимости;
не удалять заявки и события во время расследования;
не откатывать миграции удалением колонок;
анализировать только технические коды и агрегаты;
после исправления повторить все smoke-чеклисты.