Чеклист запуска в прод

Перед выводом приложения в production полезно пройтись по короткому чеклисту. Он помогает убрать самые частые эксплуатационные ошибки ещё до первого реального трафика.

1. Секреты и доступы

• API key хранится отдельно от PostgreSQL‑DSN;
• pg_user / pg_password лежат в Secret Manager или CI secrets;
• в приложении не зашит API key там, где нужен только DSN;
• права токена минимальны и соответствуют задаче.

2. Подключение и TLS

• приложение использует Gateway‑хост из Console или DSN;
• в строке подключения включён sslmode=require как минимум;
• connect_timeout не слишком маленький;
• проверен тестовый connect из того же окружения, где будет жить приложение.

3. Поведение при cold start

• драйвер умеет повторять подключение;
• общий дедлайн на connect учитывает, что sleeping‑база может проснуться не мгновенно;
• для критичных пиков есть сценарий прогрева обычным тестовым подключением;
• команда понимает, что старт теперь идёт через soft basebackup и тонкий startup‑образ, а не через полный локальный restore.

4. Профиль и автоскейлер

• выбран подходящий стартовый size;
• если важен autoscale‑handoff, учитывается, что активный runtime‑контракт сегодня — L1/L2;
• long‑lived session‑state и pinned‑соединения не используются там, где нужен максимально гладкий handoff;
• команда знает, что при смене профиля writer платформа делает candidate/freeze/drain/promote, а не “живое изменение” пода.

5. Наблюдаемость

• у команды есть быстрый путь к Metrics и Logs;
• понятны действия при state=error, затяжном booting и проблемах с TLS;
• понятно, как читать scale_state, current_profile, target_profile, freeze_new_checkouts;
• заранее определено, какие сигналы считаются инцидентом: долгий cold start, ошибки подключения, FAILED autoscale, рост числа pinned sessions.

6. Миграция и откат

• описан cutover‑сценарий;
• сохранён план возврата или повторного переключения;
• согласованы окна работ, если вы переносите production‑данные.

7. Финальная проверка

Перед реальным трафиком желательно выполнить короткий end‑to‑end тест:

1. открыть приложение из production‑окружения;
2. убедиться, что оно делает connect к SPG99;
3. выполнить несколько чтений и записей;
4. проверить логи, state и runtime‑поля БД в Console.

Если этот цикл проходит без сюрпризов, дальше эксплуатация обычно уже сводится к обычной работе с PostgreSQL и нормальной serverless‑моделью SPG99.