Cron, мониторинг и восстановление
Ежедневные фоновые проверки, сигналы здоровья и recovery runbook.
Ежедневные задачи
В приложении нет in-process scheduler. Внешний cron один раз в сутки должен
вызвать оба endpoint с одним CRON_SECRET:
curl --fail --request POST \
https://itam.example.com/api/cron/license-checks \
--header "Authorization: Bearer $ITAM_CRON_SECRET"
curl --fail --request POST \
https://itam.example.com/api/cron/attestation-checks \
--header "Authorization: Bearer $ITAM_CRON_SECRET"license-checks переводит приближающиеся к окончанию лицензии в Expiring,
пересчитывает автоматически поддерживаемые метрики и отправляет напоминания за
90/30/7 дней. Типичный ответ:
{"transitioned":1,"recalculated":3,"emailed":2}attestation-checks считает overdue assets и за 14 дней до срока уведомляет
ответственных. Типичный ответ:
{"overdue":2,"emailed":1}Обе задачи идемпотентны в пределах соответствующего срока уведомления. При
отсутствующем server-side CRON_SECRET endpoint возвращает 500 и ничего не
выполняет; неверный Bearer token должен быть отклонён.
Что наблюдать
| Сигнал | Условие тревоги | Первое действие |
|---|---|---|
/health | не 200 или не {"status":"ok"} | проверить container и startup logs |
| Deploy | новый container не стал healthy | проверить migration, seed и env |
| Cron | нет успешного daily run | повторить вызов и проверить secret/SMTP |
| SMTP | ошибки transport или доставки | проверить credentials, sender и provider |
| Database | connection/migration error | проверить URL, schema и grants |
| Audit | ожидаемая mutation без записи | остановить сценарий и расследовать путь |
Health endpoint подтверждает доступность процесса, но не заменяет отдельные проверки базы, SMTP, cron freshness и бизнес-сценариев.
Backup и recovery
- Снимайте PostgreSQL backup по политике RPO организации; включайте ITAM schema.
- Храните копии отдельно от runtime database и шифруйте их.
- Периодически восстанавливайте копию в изолированную базу.
- Проверяйте миграционную историю, количество ключевых сущностей и вход тестового пользователя.
- Документируйте фактические RPO/RTO и последнюю успешную recovery drill.
Диагностика инцидента
Сначала определите границу: весь сервис, authentication, database, SMTP, один cron или отдельное permission. Сохраните timestamp, user, route, status code, commit SHA и correlation из platform logs. Для изменений данных сопоставьте событие с Audit Log; не исправляйте записи напрямую до создания backup.
Cron secret — отдельный credential
Не используйте BETTER_AUTH_SECRET как cron token. Ротация CRON_SECRET
требует синхронного обновления приложения и внешнего scheduler.