Reactive EngineeringRE Docs
Эксплуатация

Мониторинг и восстановление

Диагностика типовых отказов, backup и rollback.

Операционный checklist

КомпонентПризнак нормы
Web/health успешен, login и защищённые страницы доступны
WorkerВ логах есть startup; процесс не перезапускается циклически
SyncПоследний FeedbackSyncRun успешен, lastSuccessAt обновляется
LeaseНет записей, зависших дольше десятиминутного lease
ProvidersConnection tests проходят, quotas и credentials действительны
SMTPPassword recovery и тестовое письмо доставляются
DatabaseMigrations применены, backup создаётся и тестово восстанавливается

Отзывы перестали загружаться

  1. Проверьте, что integration включена.
  2. Найдите последний FeedbackSyncRun и соответствующее audit-событие.
  3. Сверьте nextSyncAt, lastSuccessAt, lastError и syncLeaseUntil.
  4. Убедитесь, что worker работает с правильными Environment variables.
  5. Выполните connection test.
  6. Только после этого запустите один ручной Sync now.

Для Google отсутствие новых отзывов может быть нормальным. Для Minfin ошибка zero-card обычно указывает на изменение HTML parser contract.

Ответ не опубликован

  • PENDING: дождитесь следующей синхронизации Apple;
  • FAILED: проверьте safe error, provider permission и лимит текста, затем retry;
  • внешний ответ отсутствует локально: дождитесь bounded reconciliation или выполните контролируемый manual sync;
  • Minfin: публикуйте ответ непосредственно на площадке.

Backup

Резервная копия должна включать PostgreSQL database/schema. Отдельно храните:

  • FEEDBACK_CREDENTIALS_ENCRYPTION_KEY;
  • BETTER_AUTH_SECRET;
  • provider credentials или процедуру их повторного выпуска;
  • Dokploy Environment configuration;
  • точную версию application image.

Проверяйте восстановление на изолированном окружении. Database backup без encryption key не позволит прочитать сохранённые credentials.

Rollback

Application rollback не откатывает database migrations. Перед destructive migration подготовьте backup и forward recovery. Предпочтительный порядок:

  1. оценить совместимость предыдущего image с текущей schema;
  2. остановить новые мутации, если это необходимо;
  3. восстановить совместимый image или выпустить forward fix;
  4. проверить /health, login, worker и sync;
  5. документировать результат и состояние migration.

Не откатывайте Prisma вслепую

SQL rollback может потерять данные или нарушить совместимость. В production используется reviewed migration и заранее описанный recovery path.

On this page