Files
rf4-spotter/docs/incident-runbook.md

5.1 KiB

Incident runbook RF4 Spotter

Сначала зафиксировать время, revision из /api/v1/admin/diagnostics, симптомы и последние изменения. Не удалять volumes и не запускать миграции повторно вслепую. Если есть риск порчи или утечки, включить maintenance mode по deploy/README.md.

Заполнение диска

  1. Проверить host disk, размеры PostgreSQL/MinIO и возраст backup через deploy/monitor.sh.
  2. Остановить scheduler, чтобы не росли импорт и логи; публичное чтение оставлять только если база стабильна.
  3. Освободить место вне volumes: старые build-artifacts и журналы согласно системной retention. Не удалять файлы MinIO или PostgreSQL вручную.
  4. Выполнить штатный retention dry-run, затем apply только после проверки отчёта. После восстановления места проверить /ready и создать свежий backup.

PostgreSQL недоступен

  1. Проверить контейнер, healthcheck, свободное место и последние логи без вывода секретов.
  2. Не выполнять автоматический reset/recreate. При повреждении развернуть отдельный чистый контур и использовать deploy/restore.sh с последним проверенным backup.
  3. После запуска сверить Alembic head, /ready, счётчики diagnostics и контрольные данные.

MinIO недоступен

  1. Проверить health, диск и доступ app-пользователя только к целевому bucket.
  2. Отключить загрузку новых скриншотов или включить maintenance; текстовые заявки не считать потерянными.
  3. После восстановления проверить stat bucket, отрицательную проверку глобального list и чтение одного тестового объекта подписанной ссылкой.

Зависший импорт

  1. Проверить import run, advisory lock, время старта и процесс scheduler. Не запускать второй импорт того же источника.
  2. Если процесса уже нет, сохранить диагностику и пометить run failed штатным административным способом; не менять опубликованные записи.
  3. Следующий запуск делать только после site-wide cooldown. При повторных ошибках оставить backoff и проверить DOM-контракт на fixture.

Ошибка миграции

  1. Остановить rollout; не запускать API новой версии поверх неизвестной схемы.
  2. Сохранить логи migrate и backup. Определить, транзакционна ли упавшая ревизия и какой alembic current фактически записан.
  3. Предпочесть исправленную forward migration. Rollback приложения допустим, только если старая версия совместима с текущей схемой; восстановление БД — по документированной release-процедуре.

Компрометация секрета

  1. Немедленно включить maintenance и отозвать затронутый секрет: admin token, Basic Auth, rate-limit HMAC, app S3 или root MinIO.
  2. Создать новый уникальный секрет, обновить .env.production вне Git и перезапустить только зависимые сервисы. Для MinIO сначала выпустить нового app-пользователя, проверить policy, затем удалить старого.
  3. Проверить moderation history, auth attempts, object operations и deploy-доступ за предполагаемый период без публикации персональных данных.
  4. Если мог раскрыться RATE_LIMIT_SECRET, учитывать, что сменятся HMAC-идентификаторы клиентов. Зафиксировать инцидент и время ротации.

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

/health и /ready успешны, monitor не выдаёт предупреждений, последняя миграция и backup проверены, причина и принятые меры записаны. После критического инцидента обязателен отдельный restore drill и короткое обновление этого runbook.