Как проверить веб-продукт перед запуском: production checklist от DNS до backup

Проект разработан.

Основные сценарии работают.

Тесты проходят.

На локальном компьютере всё выглядит готовым.

Остаётся перенести приложение на VPS, подключить домен и открыть доступ пользователям.

Именно в этот момент особенно легко решить:

Раз локально работает — можно запускать.

Но локальная готовность и production readiness — далеко не одно и то же.

На production появляется целый слой вещей, которых почти не существует в локальной среде:

DNS
HTTPS
Nginx
firewall
production secrets
реальная база данных
backup
email
object storage
background workers
внешние API
кеширование
мониторинг
нагрузка
rollback

Можно получить идеально работающий frontend и при этом запустить продукт, у которого:

не создаются резервные копии;

или:

Service Worker продолжает отдавать старую версию;

или:

worker вообще не запущен;

или:

доступ к приватным файлам открыт напрямую;

или:

после первой миграции базы невозможно вернуться на предыдущий release.

Поэтому перед запуском мы бы задавали не один вопрос:

Работает ли приложение?

А четыре:

Работает ли оно в production?

Безопасно ли оно работает?

Поймём ли мы, что оно сломалось?

Сможем ли мы его восстановить?

Если хотя бы на последний вопрос нет уверенного ответа, проект ещё рано считать полностью готовым к запуску.

Production начинается не с копирования файлов на сервер

Одна из типичных ошибок — воспринимать deployment как финальную команду:

docker compose up -d

или:

npm start

Сам запуск процесса — только небольшой этап.

Production-система выглядит скорее так:

Пользователь
     ↓
DNS
     ↓
HTTPS
     ↓
Nginx / Reverse Proxy
     ↓
Application
     ↓
┌──────────┬──────────┬───────────┐
│          │          │           │
PostgreSQL Redis    Storage     Worker
│                                 │
Backup                         Background jobs

Если хотя бы один критичный элемент этой цепочки не проверен, пользовательский интерфейс может открываться, но продукт уже находится в неопределённом состоянии.

Перед запуском полезно зафиксировать release candidate

Не стоит одновременно:

деплоить production;
доделывать последнюю функцию;
менять зависимости;
править дизайн;
изменять миграцию.

Сначала полезно определить конкретную сборку:

Release:
3.4.0

Commit:
a8f2...

Build:
2026-09-28

И именно её проверять.

Иначе QA тестирует одну версию, а через час в production оказывается уже немного другая.

У релиза должен существовать однозначный ответ на вопрос:

Какой именно код сейчас запущен?

Это кажется мелочью до первого инцидента.

Когда возникает проблема, информация:

production version = ?

становится одной из самых важных.

Первый слой — DNS

До запуска приложение обычно доступно через:

localhost

или временный IP.

Но пользователь приходит по:

example.ru

И первым техническим компонентом на его пути становится DNS.

Нужно проверить не только наличие A-записи.

Например, могут существовать:

example.ru
www.example.ru
api.example.ru

и каждый адрес должен иметь понятное назначение.

Особенно опасны старые DNS-записи

Компания могла раньше использовать другой VPS.

В DNS остались:

старый A;
старый AAAA;
старый CNAME.

Часть пользователей попадает на новый сервер.

Часть — на старый.

Разработчик проверяет:

example.ru

и видит правильный IP.

Но через IPv6 пользователь получает совершенно другую машину.

Поэтому перед запуском нужно проверить весь relevant DNS zone, а не только одну запись.

Нужно заранее решить судьбу www

Например:

example.ru

является основным адресом.

Тогда:

www.example.ru

может делать постоянный redirect:

www.example.ru
      ↓
example.ru

Или наоборот.

Главное — иметь один canonical вариант.

Иначе поисковые системы и пользователи могут видеть сайт сразу по нескольким URL.

DNS и почта тоже связаны

Если домен одновременно используется для сайта и корпоративной почты, изменение зоны требует осторожности.

Нельзя удалить:

MX;
SPF;
DKIM;
DMARC

только потому, что:

Сейчас меняем DNS для сайта.

Веб-проект заработает.

Корпоративная почта перестанет.

Production checklist должен смотреть на домен как на общую инфраструктуру, а не исключительно на адрес приложения.

Второй слой — HTTPS

После DNS нужно проверить сертификат.

Не просто:

Замочек появился.

А:

сертификат выдан правильному hostname;

цепочка корректна;

сертификат не истекает прямо сейчас;

HTTP переводится на HTTPS;

renewal автоматизирован.

Если сертификат установлен вручную и никто не следит за его продлением, текущая проверка:

HTTPS ✓

мало что означает.

Через несколько месяцев сервис может внезапно начать показывать предупреждение безопасности.

Автоматическое продление нужно проверять до окончания сертификата

Плохое время для проверки:

А работает ли renew?

— день истечения сертификата.

Если используется автоматизация, она должна быть частью эксплуатационного контура.

И желательно отдельно контролировать дату окончания сертификата мониторингом.

HTTP должен иметь предсказуемое поведение

Пользователь вводит:

http://example.ru

и должен оказаться на:

https://example.ru

а не получить:

connection refused

или отдельную незащищённую версию приложения.

Особенно важно проверить:

cookies;
redirect URI;
OAuth callback;
WebSocket;
API URL.

Все они могут зависеть от итогового production-origin.

Третий слой — сам VPS

Перед размещением приложения нужно проверить сервер как инфраструктурный ресурс.

Например:

CPU
RAM
disk
filesystem
network
OS
time

Проект может успешно собраться на машине разработчика с 32 ГБ RAM и упасть на VPS с 1 ГБ сразу после запуска нескольких контейнеров.

Особенно важен свободный диск

На одном VPS обычно находятся не только файлы приложения.

Диск постепенно используют:

PostgreSQL;
Docker;
логи;
backup;
releases;
temporary files;
uploads.

Если перед запуском свободно:

1,5 ГБ

а первая резервная копия требует:

2 ГБ,

проект уже запускается с будущим инцидентом.

Поэтому мы бы проверяли не:

Есть ли немного свободного места?

А:

Достаточно ли его для нормальной эксплуатации, следующего deployment и резервного копирования?

Production должен иметь запас

Если файловая система заполнена на:

99%

приложение может пока открываться.

Но это не здоровое состояние.

PostgreSQL, логам и временным файлам тоже нужно пространство.

Полезно заранее определить safety reserve, ниже которого система начинает предупреждать администратора или ограничивать операции, способные быстро заполнить диск.

Время сервера тоже имеет значение

Неправильное системное время способно влиять на:

сессии;
JWT;
TLS;
отложенные задачи;
логи;
платежи;
уведомления.

Поэтому clock synchronization — ещё одна маленькая проверка, последствия которой могут быть совсем не маленькими.

Четвёртый слой — сеть и firewall

Открывать наружу нужно только то, что действительно должно быть доступно.

Обычно пользователю требуются:

80
443

и, в ограниченной форме, администратору:

SSH

Но PostgreSQL не обязан быть доступен всему интернету.

То же относится к:

Redis;
внутреннему Object Storage;
служебным портам приложения.

Например, если Node.js работает на:

4173
4174

это ещё не означает, что оба порта должны быть публичными.

Нормальная схема:

Internet
   ↓
80 / 443
   ↓
Nginx
   ↓
internal application ports

Пятый слой — production-конфигурация

Здесь встречается огромное количество ошибок.

Например локально:

NODE_ENV=development

случайно попал в production.

Или:

API_BASE_URL=http://localhost:4173

Или CORS по-прежнему разрешает тестовый origin.

Или application secret совпадает с development.

Production secrets не должны быть частью frontend

Если значение оказывается в JavaScript bundle браузера, оно больше не является секретом.

Там нельзя хранить:

database password;
private API key;
encryption master key;
SMTP password;
admin secret.

Frontend по определению находится у пользователя.

Настоящие secrets должны оставаться на серверной стороне.

Перед запуском полезно проверить каждый обязательный env

Не просто:

.env существует.

А:

Все ли переменные действительно production?

Например:

DATABASE_URL
APP_BASE_URL
SMTP_HOST
SMTP_USER
SMTP_PASSWORD
STORAGE_ENDPOINT
STORAGE_KEY
ENCRYPTION_KEY

Для критичных переменных полезен fail-fast.

Если:

ENCRYPTION_KEY

отсутствует, приложение лучше вообще не запускать, чем тихо перейти в небезопасный fallback.

Production не должен автоматически использовать development fallback

Опасная конструкция:

const secret =
  process.env.SECRET ||
  'development-secret';

На компьютере разработчика она удобна.

В production одна опечатка превращает:

SECRET отсутствует

в:

вся система работает
с публично известным fallback.

Лучше разделять режимы явно.

Шестой слой — PostgreSQL и миграции

До первого production deployment база может быть пустой.

Но уже через месяц она станет одним из самых ценных компонентов всего продукта.

Поэтому первое правило:

production migration — не просто ещё одна команда запуска.

Сначала нужно проверить, какая схема ожидается

Например приложение версии:

3.4.0

ожидает migration:

20260928_add_payment_events

Если backend обновился, а migration нет, приложение может начать падать только на определённом endpoint.

То есть главная страница будет работать.

Часть системы — нет.

Перед опасной миграцией нужен backup

Особенно если migration:

удаляет колонку;
меняет тип;
массово переписывает данные;
создаёт новую структуру.

Предрелизный вопрос:

Что мы будем делать, если migration прервётся на середине?

должен иметь ответ до запуска.

Хорошая migration должна быть повторяемой или иметь понятное состояние

Плохо, если после ошибки разработчик не знает:

она не началась?
выполнилась наполовину?
выполнилась полностью,
но runner этого не записал?

Migration lifecycle должен быть наблюдаемым.

Нельзя забывать индексы

Небольшая локальная база:

100 записей

работает быстро даже с плохим запросом.

Production:

2 000 000 записей

уже нет.

Например:

SELECT *
FROM messages
WHERE project_id = $1
ORDER BY created_at DESC;

без подходящего индекса может со временем стать заметной проблемой.

Поэтому production readiness включает не только правильную схему, но и базовые query patterns.

Connection pool тоже требует проверки

На локальной машине существует:

1 backend process.

В production:

API #1
API #2
Worker
Scheduler

Если каждый открывает десятки соединений, PostgreSQL может получить существенно больше connections, чем ожидалось.

Поэтому:

max connections;
pool size;
количество процессов

нужно рассматривать вместе.

Седьмой слой — пользовательские файлы

Если продукт хранит:

PDF;
изображения;
архивы;
чеки;
договоры,

нужно проверить не только upload.

Нужен полный lifecycle:

upload
↓
metadata
↓
storage
↓
download
↓
permission check
↓
delete

Приватный файл не должен становиться публичным по прямой ссылке

Например клиентский договор находится в Object Storage.

Если его можно открыть:

https://storage.example/contract.pdf

без проверки пользователя, permission layer приложения фактически обходится.

Для приватных объектов разумнее:

User
 ↓
Backend
 ↓
Authorization
 ↓
Temporary signed URL

или controlled proxy download.

Нужно проверить реальные ограничения файла

Не только frontend:

Максимум 20 МБ.

Но и:

Nginx;
backend parser;
storage;
quota.

Если frontend разрешает 20 МБ, а Nginx:

client_max_body_size 5M;

функция работает локально и ломается только после deployment.

Восьмой слой — фоновые процессы

Одна из самых коварных production-ошибок:

API работает, значит приложение работает.

Но продукт может иметь:

worker;
scheduler;
cron;
job queue.

Например frontend принимает заявку.

Backend сохраняет её.

А email должен отправить worker.

Если worker не запущен:

заявка создаётся ✓
email             ✗

Пользователь видит лишь половину проблемы.

Нужно тестировать не наличие процесса, а реальную работу

Не достаточно:

worker container = running.

Полезнее создать настоящую тестовую задачу и убедиться:

job создан;
worker взял;
job завершён;
результат появился.

Process health и business health — разные вещи.

То же относится к scheduler

Если система должна:

публиковать статьи;
отправлять напоминания;
выполнять cleanup;
проверять интеграции

по расписанию, нужно убедиться, что production scheduler действительно запускается и использует правильную timezone.

Девятый слой — email и уведомления

Фраза:

SMTP подключён.

недостаточна.

Нужно фактически отправить письмо из production.

Проверить:

From;
Reply-To;
ссылки;
production domain;
кодировку;
верстку.

Особенно часто в письме остаётся:

http://localhost:3000/reset-password/...

потому что application base URL не был переключён.

Восстановление пароля — один из лучших smoke-тестов

Он одновременно проверяет:

frontend;
backend;
database;
token generation;
email;
production URL;
HTTPS.

Поэтому перед запуском полезно реально пройти сценарий:

Забыли пароль
↓
Email
↓
Ссылка
↓
Новый пароль
↓
Login

Десятый слой — authentication и permissions

Проверить:

Я могу войти как администратор.

недостаточно.

Нужно проверить несколько ролей.

Например:

Admin
Manager
Client
Viewer

Особенно важны негативные проверки.

Не:

Admin видит проект?

а:

Client A точно не видит Project B?

Самый ценный access test часто состоит из двух пользователей

Создаём:

Organization A
User A
Project A

и:

Organization B
User B
Project B

Затем User A пытается получить:

/api/projects/B

Меняет ID вручную.

Проверяет файл.

Поиск.

Экспорт.

WebSocket.

Если хоть один маршрут возвращает чужие данные, production запускать рано.

Скрытая кнопка не является проверкой прав

Frontend может не показывать:

[Удалить проект]

обычному пользователю.

Но backend должен самостоятельно запретить:

DELETE /api/projects/1842

Пользователь способен отправить HTTP-запрос без интерфейса.

Production checklist должен проверять реальные permissions API.

Одиннадцатый слой — платежи и webhook

Если продукт принимает оплату, перед запуском мало проверить:

открывается checkout.

Нужно пройти полный lifecycle:

создание платежа
↓
confirmation
↓
webhook
↓
локальный status
↓
business effect

Redirect после оплаты не должен быть единственным подтверждением

Пользователь может:

закрыть браузер;
потерять интернет;
не вернуться на сайт.

Но сервер всё равно должен получить authoritative состояние платежа через предусмотренную интеграцию.

Обязательно нужно проверить повторный webhook

Отправляем одно событие дважды.

Ожидаем:

1 payment transition
1 order
1 license
1 начисление

а не два.

Так проверяется реальная идемпотентность.

Двенадцатый слой — внешние интеграции

Например:

1С;
CRM;
Telegram;
AI API;
SMS;
карты.

На staging мог использоваться:

test API key.

В production уже другой account.

Поэтому интеграцию нужно проверить именно из production environment.

Полезно проверить и failure path

Не только:

API ответил 200.

Но:

Что происходит при 500?

Что происходит при timeout?

Есть retry?

Появляется failed job?

Можно ли безопасно повторить?

Продукт готов к production, когда он умеет переживать не только успех внешней системы.

Тринадцатый слой — кеширование

Особенно важен для:

PWA;
Service Worker;
Nginx static cache;
CDN.

Очень неприятный релиз:

сервер уже обновлён;
пользователь продолжает
видеть старый JS.

Теперь frontend и backend принадлежат разным версиям продукта.

После deployment нужно проверить приложение как новый пользователь

Не только в браузере разработчика, где:

cache;
localStorage;
service worker

существуют месяцами.

Полезны:

incognito;
новый browser profile;
другое устройство.

А затем — отдельно upgrade старого клиента с предыдущей версии.

Для PWA это особенно важно

Нужно проверить:

новый install;
обновление существующей PWA;
offline fallback;
новый Service Worker;
удаление устаревших cache;
поведение после release.

Если новый пользователь работает, а старый остаётся на старой версии, обычный smoke-test это не обнаружит.

Четырнадцатый слой — mobile

Responsive layout, который красиво выглядит на desktop DevTools, ещё не гарантирует нормальную работу на реальном смартфоне.

Проверяются:

маленькая ширина;
touch;
keyboard;
modal windows;
fixed header;
safe areas;
scroll.

Особенно:

360 px

или другая минимальная поддерживаемая ширина проекта.

Модальные окна часто ломаются первыми

Например desktop показывает:

заголовок;
форму;
кнопки.

На мобильном:

крестик оказался за экраном;
последняя кнопка не прокручивается;
keyboard перекрыл input.

До production такие сценарии лучше проверить руками на реальном устройстве или полноценным мобильным E2E.

Пятнадцатый слой — performance

Перед запуском не обязательно добиваться:

100 / 100

по каждой метрике.

Но нужно понимать базовое состояние.

Например:

главная страница;
login;
dashboard;
список проектов;
тяжёлая карточка.

Если один endpoint уже до запуска отвечает:

4 секунды

под реальной нагрузкой он вряд ли станет быстрее сам.

Необходимо различать frontend и backend performance

Страница может медленно открываться из-за:

3 MB JavaScript bundle

или из-за:

SQL query = 2.8 s.

Это совершенно разные проблемы.

Production checklist нужен не для получения одной цифры, а для обнаружения очевидных bottleneck до пользователей.

Шестнадцатый слой — SEO публичной части

Если проект имеет индексируемые страницы, перед запуском нужно убедиться, что production случайно не остался в режиме staging.

Очень неприятная строка:

Disallow: /

в production robots.txt.

Или:

noindex

на всех страницах.

Нужно проверить канонический production URL

Например canonical не должен вести на:

staging.example.ru

Так же проверяются:

sitemap;
robots;
title;
description;
canonical;
HTTP status;
redirect.

Особенно после изменения домена.

Но не все страницы должны индексироваться

Например:

/login
/admin
/account

не являются SEO-страницами.

Production checklist должен проверять не:

Индексируется ли всё?

А:

Индексируется ли только то, что должно быть публичным?

Семнадцатый слой — мониторинг

Запускать production без мониторинга — значит ждать, пока роль системы наблюдения возьмут на себя пользователи.

Минимально хочется понимать:

сайт доступен?
API ready?
ошибки выросли?
диск заканчивается?
backup свежий?
worker работает?

Health-check должен проверять нужный уровень

Endpoint:

/health

который всегда отвечает:

{"ok": true}

пока Node.js process жив, имеет ограниченную ценность.

Более полезно различать:

liveness

и:

readiness.

Приложение может быть живо, но не готово

Например:

Node.js       ✓
PostgreSQL    ✗
Redis         ✓
Storage       ✓

Значит:

Alive: YES
Ready: NO

Это позволяет reverse proxy и monitoring правильно интерпретировать состояние.

Alert должен действительно куда-то приходить

Фраза:

У нас настроен мониторинг.

может означать красивый dashboard, который никто не открывает.

Monitoring становится operational инструментом только если критическое событие создаёт alert.

Например:

Disk < reserve

или:

API unavailable

или:

backup older than expected

должны попасть человеку, способному отреагировать.

Восемнадцатый слой — логи

До запуска нужно убедиться, что при ошибке возможно ответить хотя бы на вопросы:

Когда произошло?

На каком endpoint?

Какой request?

Какая ошибка?

Какая зависимость отказала?

Без этого первая production-проблема превращается в угадывание.

Но логи тоже способны сломать production

Если:

app.log

растёт без ограничений, через несколько месяцев он способен заполнить диск.

Поэтому проверяется:

rotation;
retention;
максимальный размер.

И отдельно — отсутствие:

password;
token;
secret;
полного приватного payload.

Девятнадцатый слой — backup

Это одна из самых важных частей всего checklist.

И одновременно та, которую легко проверить формально:

Backup task configured ✓

Но этот checkbox почти ничего не гарантирует.

Настоящая проверка backup состоит из двух операций

Первая:

BACKUP

Вторая:

RESTORE

Если backup никогда не восстанавливался, мы пока знаем только:

Был создан какой-то файл.

Но не:

Из него можно восстановить рабочую систему.

Что нужно восстанавливать

Зависит от архитектуры.

Например:

PostgreSQL;
user files;
object storage;
critical configuration.

При этом secrets и encryption keys требуют отдельной стратегии.

Можно идеально сохранить encrypted database и потерять единственный ключ расшифровки.

Формально backup есть.

Практически данные потеряны.

Backup на том же VPS — не полноценная защита от потери VPS

Он помогает при:

случайном удалении;
неудачной migration;
повреждении конкретных данных.

Но если исчезает весь сервер, одновременно исчезает:

production
+
backup.

Поэтому серьёзному продукту нужна независимая копия.

Двадцатый слой — rollback

Перед deployment нужно знать:

Если новая версия окажется плохой, как вернуть предыдущую?

Не после инцидента.

До него.

Release лучше считать неизменяемым

Например:

/releases/
  20260928-101500/
  20260920-193000/

current  → 20260928-101500
previous → 20260920-193000

Тогда откат application code может быть быстрым и предсказуемым.

Вместо:

Сейчас попробуем вспомнить, какие файлы были до обновления.

Но база усложняет rollback

Если новый release выполнил:

DROP COLUMN

старое приложение может уже не запуститься.

Поэтому хороший deployment checklist должен задавать вопрос:

Совместима ли новая migration с возможным rollback?

Иногда безопаснее использовать постепенные изменения схемы:

add
↓
migrate
↓
switch
↓
remove later

вместо мгновенного destructive migration.

Двадцать первый слой — финальный smoke test

Когда production уже поднят, нужно пройти реальные критичные сценарии через реальный домен.

Например:

Открыть сайт
↓
Создать пользователя
↓
Подтвердить email
↓
Войти
↓
Выполнить основную операцию
↓
Загрузить файл
↓
Получить уведомление
↓
Выйти
↓
Войти снова

Для конкретного продукта набор будет свой.

Smoke-test должен проверять бизнес, а не страницы

Слабый:

GET / = 200

Сильнее:

Новый клиент действительно способен пройти основную цепочку от первого входа до результата.

Например для CRM:

Login
↓
Create client
↓
Create deal
↓
Change stage
↓
Add document

Для SaaS:

Register
↓
Create workspace
↓
Invite user
↓
Use core function

Для магазина:

Add to cart
↓
Checkout
↓
Payment
↓
Order confirmed

После запуска полезен период усиленного наблюдения

Production deployment закончился не в ту секунду, когда команда:

deploy

вернула success.

Первые реальные пользователи могут открыть сценарии, которых не было в тестах.

Поэтому после запуска особенно полезно следить за:

error rate;
latency;
disk;
jobs;
email;
external integrations.

Если показатели остаются нормальными, release можно считать стабилизированным.

Go / No-Go решение должно приниматься по фактам

Иногда за час до запуска обнаруживается:

backup не проверен.

Команда говорит:

Но всё остальное ведь готово.

И появляется соблазн запустить.

Правильное решение зависит от риска.

Для тестового лендинга отсутствие backup может быть несущественно.

Для CRM с историей клиентов — уже нет.

Production checklist нужен именно затем, чтобы критичные условия не превращались в:

Наверное, ничего не случится.

Практический production checklist

Перед запуском мы бы прошли хотя бы такой набор:

• Release: зафиксированы версия и сборка; тестируется именно тот артефакт, который пойдёт в production; известен предыдущий release и способ отката.
• DNS: основной домен указывает на правильный сервер; проверены www, поддомены, A/AAAA/CNAME; почтовые записи не повреждены.
• HTTPS: сертификат соответствует домену; HTTP перенаправляется на HTTPS; продление автоматизировано; срок сертификата контролируется.
• VPS: достаточно CPU, RAM и свободного диска; настроена синхронизация времени; production-data не лежат внутри временного release-каталога.
• Network: наружу открыты только необходимые порты; PostgreSQL, Redis и служебные API не опубликованы без необходимости.
• Secrets: используются production credentials; отсутствуют development fallback; секреты не попадают во frontend и репозиторий.
• Database: применены миграции; проверены constraints и ключевые индексы; connection pool соответствует количеству процессов; перед опасными изменениями существует backup.
• Files: upload/download/delete работают; приватные файлы требуют authorization; проверены ограничения размера и quota; Object Storage доступен.
• Workers: background worker и scheduler реально выполняют тестовые jobs, а не просто имеют статус running.
• Email: отправлено реальное production-письмо; работают восстановление пароля и ссылки с правильным доменом.
• Access: протестированы разные роли и негативные сценарии доступа к чужим объектам.
• Payments: проверены success, failure, webhook, повторный webhook и идемпотентность бизнес-эффекта.
• Integrations: production API keys корректны; проверены timeout/error/retry, а не только happy path.
• PWA/cache: новый пользователь получает свежую версию; старый клиент корректно обновляется; Service Worker не удерживает устаревший release.
• Mobile: проверена минимальная поддерживаемая ширина и реальные Android/iOS-сценарии, если они входят в продукт.
• Performance: критичные страницы и API не имеют очевидных bottleneck; зафиксировано базовое состояние latency.
• SEO: robots.txt, sitemap, canonical, redirects, title/description и HTTP status соответствуют production.
• Monitoring: настроены liveness/readiness и реальные alerts на критические проблемы.
• Logs: ошибки можно диагностировать; включена rotation/retention; чувствительные данные не записываются без необходимости.
• Backup: резервная копия действительно создаётся; есть независимое хранение там, где оно требуется; выполнен тестовый restore.
• Recovery: документированы rollback, restore и действия при потере критичной зависимости.
• Smoke test: основной пользовательский путь пройден через настоящий production-домен после deployment.

Если несколько пунктов ещё находятся в состоянии:

«потом настроим»

полезно хотя бы осознанно определить их риск.

Но для критичных компонентов:

permissions;
payments;
backup;
secrets;
database;

«потом» может оказаться слишком поздно.

Хороший checklist должен зависеть от самого проекта

У лендинга нет:

PostgreSQL;
worker;
payments;
private files.

Значит половина проверок не нужна.

У SaaS может быть:

organizations;
billing;
webhooks;
file storage;
background jobs.

И checklist становится значительно шире.

Поэтому production readiness — не один универсальный PDF на все проекты.

Это набор общих слоёв плюс проверки конкретной архитектуры.

Что заказчик должен получить после проверки

Результат запуска полезно фиксировать не словами:

Всё вроде работает.

А коротким release report.

Например:

Release:
3.4.0

Production:
https://example.ru

DNS:
PASS

HTTPS:
PASS

Database migrations:
PASS

Critical E2E:
PASS

Backup:
PASS

Restore:
PASS

Monitoring:
PASS

Known issues:
none critical

Rollback:
3.3.2 available

Так запуск становится проверяемым техническим событием.

Особенно полезно фиксировать известные ограничения

Например:

Known limitation:
Safari Push not enabled

Это намного лучше, чем обнаружить через месяц и спорить:

Это баг или мы изначально так запускались?

Production report фиксирует реальное состояние продукта в момент передачи.

Production checklist полезен и через год

Он нужен не только для первого запуска.

Через год происходит:

major update;
смена VPS;
смена домена;
миграция PostgreSQL;
переезд storage.

Большая часть тех же проверок снова становится актуальной.

Поэтому хороший checklist постепенно превращается в release procedure.

Чем зрелее продукт, тем меньше запуск зависит от памяти разработчика

В начале процесс может выглядеть:

Михаил помнит, что после deployment нужно вручную перезапустить worker.

Это хрупко.

Зрелая система:

deploy script
↓
migration
↓
API restart
↓
readiness
↓
worker
↓
smoke tests

делает правильную последовательность автоматически или хотя бы документирует её.

Automation не отменяет checklist

Она превращает его часть в исполняемые проверки.

Например вместо пункта:

Убедиться, что /api/ready работает.

Deployment script самостоятельно проверяет:

GET /api/ready

и останавливается при ошибке.

Вместо:

Не забыть применить migration.

Release process проверяет schema version.

Лучший checklist со временем становится не длиннее, а автоматизированнее.

Но некоторые проверки всё равно остаются человеческими

Например:

Удобно ли пользоваться мобильной модалкой?

Или:

Правильно ли сформулировано письмо?

Или:

Визуально корректно ли выглядит критичный пользовательский сценарий?

E2E не заменяет полностью ручной просмотр.

Автоматизация и человеческая проверка дополняют друг друга.

Самая важная проверка — способность восстановиться

Можно идеально выполнить:

DNS ✓
HTTPS ✓
API ✓
UI ✓

и всё равно иметь хрупкий production.

Представим:

03:20
VPS потерян.

Теперь главный вопрос:

Сколько времени потребуется вернуть сервис?

Если ответ:

Не знаем. Backup вроде есть.

система была не полностью готова к production.

RPO и RTO можно обсуждать даже в небольшом проекте

Не обязательно употреблять сложную терминологию.

Достаточно ответить на два вопроса.

Первый:

Сколько данных мы готовы потерять?

Если backup раз в сутки:

до 24 часов изменений.

Второй:

Сколько времени может занимать восстановление?

30 минут?
4 часа?
сутки?

Эти ответы помогают выбрать реальную backup-стратегию.

Backup без restore — предположение

Это настолько важная мысль, что её стоит повторить.

Можно год видеть:

Backup completed successfully

и только после аварии обнаружить:

архив повреждён;
ключ потерян;
версия несовместима;
инструкция устарела.

Поэтому тест восстановления должен быть частью эксплуатационной культуры, а не аварийным экспериментом.

Когда продукт действительно готов к запуску

Не тогда, когда разработчик говорит:

У меня всё работает.

Не тогда, когда:

npm test

зелёный.

И даже не тогда, когда открывается production URL.

Мы бы считали систему готовой, когда можем ответить «да» на более широкий набор вопросов:

Пользователь способен пройти основной сценарий?

Чужие данные защищены?

Production-конфигурация корректна?

Внешние сервисы действительно работают?

Система переживает повтор webhook и сетевой сбой?

Мы увидим серьёзную проблему автоматически?

У нас есть рабочая резервная копия?

Мы проверили восстановление?

Мы знаем, как откатить неудачный release?

Другой технический специалист сможет понять, как устроен production?

Тогда речь идёт уже не просто о работающем коде.

Речь идёт о готовом к эксплуатации веб-продукте.

Вместо вывода

Перед запуском легко сосредоточиться на том, что видит пользователь:

дизайн;
формы;
кнопки;
страницы.

Но основная часть production readiness находится глубже.

Пользователь никогда не увидит:

backup;
readiness probe;
rollback;
rotation logs;
database migration;
disk reserve.

Именно до того момента, пока одна из этих вещей не окажется настроена неправильно.

Хороший production checklist проверяет сразу несколько слоёв:

Domain
   ↓
DNS
   ↓
HTTPS
   ↓
Infrastructure
   ↓
Configuration
   ↓
Database
   ↓
Application
   ↓
Workers / Integrations
   ↓
Security
   ↓
Monitoring
   ↓
Backup
   ↓
Recovery

Главная идея проста:

готовность к запуску определяется не только способностью продукта работать, но и его способностью контролируемо переживать ошибки.

Если можно:

обнаружить проблему;

понять:

почему она произошла;

вернуть:

рабочую версию;

и при необходимости:

восстановить данные,

значит проект подготовлен к реальной эксплуатации намного лучше, чем система, у которой просто открывается главная страница.

Поэтому финальная проверка перед запуском — не бюрократия и не формальный последний этап разработки.

Это момент, когда готовый код превращается в работающий production-продукт.