Готовность к продакшену

Эта страница — чек-лист до переключения трафика на AACsearch в проде. Намеренно гранулярный: чекбоксы можно скопировать в launch-тикет. Если уже прошли Security overview и Operations, большая часть знакома; здесь — точка пересечения.

Ежедневная эксплуатация после запуска — Operations. Pre-launch чек-лист безопасности — Security overview.

Как использовать

• Каждый раздел — чек-лист по одной зоне продакшена.
• Пункт, не применимый к вашему деплою, пометьте N/A — но запишите почему, не «пропустили».
• Правило двух лиц: каждый чекбокс проверяет не тот, кто его поставил.

1. Окружение

• Прод-деплой — отдельная организация, не проект внутри staging-org.
• Домен, с которого ходим в AACsearch, поднят (ваш API-эндпоинт, хост виджета).
• NODE_ENV=production в рантайме.
• DATABASE_URL указывает на прод-БД (не staging). .env.local и .env сходятся.
• BETTER_AUTH_SECRET — сильное уникальное значение в проде (32+ случайных байта).
• NEXT_PUBLIC_* env-ы не утекают непубличные значения. Сверьте по бандлу.
• CDN перед приложением настроен под регионы, которые обслуживаете.
• Reverse-proxy / LB терминирует TLS 1.3.
• Healthcheck-и смотрят на /health приложения, а не на AACsearch.

2. База данных

Это ваша БД, не наша. PostgreSQL AACsearch управляется нами; этот раздел — про БД с вашими источниками истины: продуктами, контентом, клиентами.

• Пул соединений под пик нагрузки (старт — max = (cpu × 4) + 1).
• Бэкапы настроены и проверены — pg_dump сам по себе не стратегия; используйте WAL archiving.
• Restore проверен из бэкапа хотя бы раз, а не «бэкапы существуют».
• Replication lag мониторится (если есть реплики).
• Алерт на долгие запросы (например, > 30 сек) подключён к paging.
• План миграций схемы: изменения через Prisma migration, не сырой SQL-drift.
• PII-колонки зашифрованы at-rest, если требует юрисдикция.

3. Поисковый кластер (AACsearch)

• Прод-проект отдельный от staging-проекта (разные ключи, индексы, биллинг).
• Схемы индексов отревьювлены: каждое поле, по которому ищем, — в query_by; каждое поле, по которому фильтруем, — index: true.
• default_sorting_field задан там, где порядок важен на query-time.
• Стартовый реиндекс выполнен и проверен — см. Реиндексирование.
• Doc count drift ниже 5 % (зелёный health-значок).
• Минимум один негативный тест изоляции арендаторов проходит — см. Изоляция арендаторов.
• Синонимы и курации применены к прод-индексам.
• Webhook-и (если используете) смотрят на прод-эндпоинты, не staging.

4. Секреты и API-ключи

• Ни ss_search_…, ни ss_connector_…, ни ss_scoped_… не закоммичено ни в одном репо. Поищите по всем репо команды.
• Прод-ключи отличаются от dev и staging.
• Браузерные ключи — только search + origin allow-list — см. Origin allow-list.
• Серверные ingest/admin ключи — в secret-менеджере (Vault, AWS Secrets Manager, Doppler), не в коммитнутом env.
• У каждого сервиса свой ключ. Не разделяем один admin-ключ между сервисами.
• Календарь ротации — 90 дней для admin, 30 дней для браузерных — норм.
• 2FA принудительно у всех с ролью admin/owner.
• При использовании SCIM bearer-токен лежит в secret-сторе IdP — см. SSO и SCIM.

5. Storage

Относится к S3 / object storage вашего приложения, не внутренних бакетов AACsearch.

• Прод-бакет(ы) отдельны от непрод. Кросс-бакетные read-ы не выданы.
• Регион бакета соответствует data residency.
• Шифрование at-rest (SSE-S3 или SSE-KMS).
• Версии включены при деструктивных записях.
• Lifecycle: архив старых объектов в дешёвый storage, expire по retention.
• CORS — только ваши домены (не *).
• Pre-signed URL — HTTPS, короткоживущие, с минимальными правами.

6. Email

Если приложение шлёт транзакционные/нотификационные письма через AACsearch (reset, алерты) или напрямую:

• SPF, DKIM, DMARC опубликованы на отправляющем домене.
• DMARC переключается в p=quarantine только после p=none-периода с подтверждённым выравниванием.
• Bounce-ы и жалобы перехватываются и обрабатываются (не пишите на мёртвые адреса).
• Email-путь тестировался с реальным, не девелоперским ящиком до запуска.
• Unsubscribe-ссылка в маркетинге — RFC 8058 (List-Unsubscribe).
• Транзакционный и маркетинг — разные домены/субдомены отправки.

7. Биллинг

• Способ оплаты — на прод-организации, не личная карта.
• Биллинг-контакт — общий ящик (billing@yourcompany.com), не один человек.
• Тариф соответствует прогнозу нагрузки с минимум 30 % запасом на первый месяц.
• Алерты по квоте включены — см. Лимиты и квоты.
• Если настроены wallet / overage-bypass — порог топ-апа задокументирован.
• Для Enterprise: контракт, DPA и кастомный SLA подписаны и подшиты.

8. Мониторинг

• Каждый из четырёх сигналов подключён к observability — см. Мониторинг: drift, lag, error rate, 429.
• Пороги соответствуют странице мониторинга (или жёстче).
• Алерты идут в paging с ротацией, не в почту.
• Подписка на статусную страницу — см. Статус и инциденты. В чат инцидентов, не в личку.
• Sentry (или аналог) тегирован requestId, orgId, indexId — см. Observability.
• Синтетический поиск каждую минуту из каждого региона.

9. Бэкапы и recovery

• Понятно, что бэкапим мы, а что — вы.
• Экспорт индексов на вашу сторону по расписанию (NDJSON в ваш S3) — закрывает «нужна своя копия».
• Экспорт аудита по расписанию — см. Экспорт аудита.
• Restore-drill: хотя бы один человек в команде прогнал восстановление из ваших бэкапов за последние 90 дней.
• DR runbook вашего приложения существует — наш runbook как референс: DR recovery runbook.

10. Smoke-тесты перед запуском

Прогон до открытия трафика:

• Вход в дашборд каждой ролью (owner, admin, member) — корректный вид.
• Создаёте тестовый документ через ingest, ищете его.
• Удаляете — пропадает из поиска в течение 60 секунд.
• Поиск с заведомо невалидным фильтром — ошибка ожидаемая.
• Поиск с заведомо нулевыми хитами — пустое состояние UX.
• Поиск, упирающийся в rate limit — клиент откатывается аккуратно.
• Mint scoped-токен, поиск с tenant id пользователя — кросс-tenant данных не видно. См. Изоляция арендаторов.
• Если есть webhook-и: триггер события, подтверждение в Webhooks → Deliveries.
• Если есть SCIM: деактивация тестового пользователя в IdP — теряет доступ в AACsearch в окно sync.

После запуска

Первые 72 часа — встреча чек-листа с реальностью. Внимательно — четыре сигнала из Мониторинга; ждите, что один порог окажется шумным, а другой — слишком тихим. Корректируйте первую неделю, потом не трогайте.

Еженедельный обзор audit log первый месяц ловит drift рано. См. Аудит.

См. также

• Обзор безопасности — чек-лист перед запуском
• Operations
• DR recovery runbook
• Enterprise procurement — дополнительные пункты для enterprise