Продакшен-инфраструктура: лучшая конфигурация для каждого этапа

01Принципы важнее диаграмм

Хорошая инфраструктура скучна: предсказуемые деплои, понятная зона ответственности и сбои, которые замечают и после которых можно восстановиться. Прежде чем выбирать инструменты, ответьте на четыре вопроса. Какой простой может выдержать бизнес (целевая доступность)? Сколько данных он может потерять (RPO) и как быстро нужно восстановиться (RTO)? Кто будет это обслуживать в 3 часа ночи? Каков месячный бюджет? Затем растите по шагам. Каждый шаг должен устранять реальное узкое место или риск, который вы можете назвать: база данных, отбирающая память у приложения, загрузки, застрявшие на одном диске, единственный сервер как единая точка отказа или команда, деплоящая десятки сервисов. Слишком ранний переход на следующий этап добавляет стоимость и сложность без пользы; слишком поздний означает аварии. На любом этапе описывайте инфраструктуру в коде или хотя бы в письменных runbook, чтобы её можно было пересобрать.

02Этап 1: один правильно настроенный VPS

Для MVP, сайта небольшого бизнеса или внутреннего инструмента один хорошо настроенный сервер (2–8 GB RAM) часто оказывается лучшим выбором: дёшево, быстро, легко понять. nginx терминирует HTTPS и маршрутизирует запросы к приложениям; PHP-FPM и Node работают под собственными пользователями; база данных и Redis слушают localhost; воркеры работают под supervisor или systemd. Docker Compose — хороший вариант, чтобы воспроизводимо упаковать всё это. «Правильно настроенным» его делает всё, что вокруг приложений: базовый набор защиты, Cloudflare впереди, ночные дампы базы, скопированные за пределы сервера, снапшоты провайдера, алерты по доступности и диску и скриптовый деплой с папками релизов. Его слабость — он единая точка отказа, поэтому важна скорость восстановления: вы должны уметь пересобрать его из скриптов и бэкапов за часы и хотя бы раз это отрепетировать.

• Cloudflare (DNS, WAF, CDN) → nginx → процессы приложений → локальные БД/Redis.
• Бэкапы вне площадки, снапшоты включены, восстановление проверено.
• Типичная стоимость: десятки долларов в месяц.

03Этап 2: сервер приложения + управляемая БД + объектное хранилище + CDN

Когда данные становятся ценными или базе нужно больше памяти, вынесите состояние с сервера приложения. Управляемая база данных даёт автоматические бэкапы, восстановление на момент времени и опциональный резервный узел. Пользовательские загрузки уходят в S3-совместимое объектное хранилище вместо локального диска и отдаются через CDN. Сессии и кэш уходят в Redis — управляемый или на приватном сервере. Теперь сервер приложения не хранит уникальных данных, и это ключевое изменение: его можно пересобрать или заменить в любой момент, изменить размер с минимальным риском, а позже добавить второй. Конфигурация и секреты приходят из переменных окружения, а деплой собирает один и тот же артефакт для staging и продакшена. Этот этап — золотая середина для многих прибыльных продуктов, и при хорошем кэшировании и индексах он выдерживает удивительно большой трафик.

• Сервер приложения без состояния: только код и конфигурация.
• База данных: управляемая, доступ только из частной сети, PITR включён.
• Файлы: объектное хранилище + CDN; никаких загрузок на диске сервера.

04Этап 3: балансировщик, несколько серверов приложений, реплики и очереди

Когда одного сервера приложения уже не хватает или бизнесу нужно переживать отказ сервера, поставьте балансировщик нагрузки перед двумя или более одинаковыми серверами приложений, в идеале в разных зонах доступности. Балансировщик проверяет их health checks и перестаёт отправлять трафик на сломанный. Деплой прокатывается по серверам по одному. База данных получает реплики для чтения под тяжёлый трафик на чтение и отчёты, а также резервный узел для failover. Медленная работа (письма, PDF, обработка изображений, вебхуки, импорты) уходит в фоновые очереди с выделенными серверами-воркерами, чтобы веб-запросы оставались быстрыми, а пики сглаживались. Следите за скрытым состоянием: загрузки файлов, сессии, задачи по расписанию (запускайте планировщик только на одном узле или используйте блокировку) и кэши в памяти — всё это должно быть общим или согласованным. Отставание репликации также означает, что пользователь может не сразу прочитать с реплики то, что только что записал.

05Этап 4: контейнеры и Kubernetes

Контейнеры упаковывают каждый сервис вместе с его зависимостями, так что один и тот же образ работает на ноутбуке, в CI и в продакшене. Docker Compose на одном или нескольких серверах покрывает очень многое. Kubernetes (или управляемая альтернатива вроде ECS, Cloud Run или управляемого сервиса Kubernetes) добавляет планирование по множеству машин, самовосстановление, rolling updates, автомасштабирование и обнаружение сервисов. Он окупается, когда вы запускаете много сервисов, несколько команд деплоят независимо или трафик сильно колеблется. Цена реальна: платформа, которую нужно изучить и эксплуатировать, больше YAML, больше способов ошибиться в настройке сети и безопасности и обычно более высокий счёт. Управляемый control plane снимает часть боли, но не сложность самих нагрузок. Многим успешным продуктам он так и не понадобился; переходите на него, когда цена координации без него явно выше.

06Окружения, секреты, DR, мониторинг и стоимость

Каждому этапу нужно как минимум staging-окружение, повторяющее продакшен по версиям и конфигурации, со своей базой данных и учётными данными, чтобы изменения проверялись до того, как их увидят клиенты. Секреты подставляются для каждого окружения из env-файлов или менеджера секретов, никогда не делятся между staging и продакшеном и никогда не попадают в Git. Аварийное восстановление (DR) — это записанные и отрепетированные шаги: где лежат бэкапы, как пересобрать сервер, как переключить базу данных на резерв, кто принимает решения. Мониторинг состоит из трёх частей: метрики (CPU, память, диск, задержки, доля ошибок, длина очередей, например через Prometheus и Grafana), централизованно собираемые логи (Loki или облачный сервис) и алерты, которые будят человека только при реальном влиянии на пользователей, плюс внешние проверки доступности. Пересматривайте расходы ежемесячно: неиспользуемые серверы, завышенные инстансы, старые снапшоты и плата за egress тихо накапливаются.

• dev → staging → production, и дальше продвигается один и тот же артефакт сборки.
• Алерты по симптомам (ошибки, задержки, простой), расследование по метрикам и логам.
• Помечайте ресурсы тегами проекта и окружения, чтобы видеть, куда уходят деньги.

07Миграция или объединение серверов без потери данных

Перенос сайтов на новый сервер или объединение нескольких серверов в меньшее число — это в основном аккуратный учёт. Сначала инвентаризация: каждый домен, приложение, база данных, cron-задача, воркер, сертификат, почтовый ящик, env-файл и папка загрузок на старом сервере. Соберите новый сервер по базовому набору, затем скопируйте код, файлы и базы данных и проверьте: запустите приложения через переопределение в hosts-файле, сравните число строк и файлов, посмотрите логи. За день до переключения уменьшите TTL в DNS. В момент переключения ненадолго переведите старое приложение в режим обслуживания, выполните финальную инкрементальную синхронизацию файлов и свежий дамп базы, импортируйте его, затем переключите DNS (с прокси Cloudflare это мгновенно). Оставьте старый сервер работающим и нетронутым, пока трафик, данные и бэкапы на новом не будут проверены в течение нескольких дней; только после этого, сделав финальный бэкап, выводите его из эксплуатации.

1# 1. Initial copy of code and uploads (preserves owners, permissions, links)
2rsync -aHAX --info=progress2 [email protected]:/var/www/shop/ /var/www/shop/
3 
4# 2. At cutover: maintenance mode on the old server, then final delta sync
5ssh [email protected] 'cd /var/www/shop && php artisan down'
6rsync -aHAX --delete [email protected]:/var/www/shop/storage/ /var/www/shop/storage/
7 
8# 3. Fresh database copy streamed directly to the new server
9ssh [email protected] 'mysqldump --single-transaction --routines --triggers shop_db' | mysql shop_db
10 
11# 4. Verify before switching DNS
12mysql -e "SELECT COUNT(*) FROM shop_db.orders;"
13ssh [email protected] "mysql -e 'SELECT COUNT(*) FROM shop_db.orders;'"
14curl -sI --resolve example.com:443:127.0.0.1 https://example.com | head -1

08Математика доступности: «девятки», зависимости и error budget

Цель по доступности превращается в конкретный допустимый объём простоя. За 30-дневный месяц 99.5 процента дают около 3.6 часа, 99.9 процента — около 43 минут, а 99.99 процента — около 4.3 минуты, чего не выдержит ни один процесс дежурств с людьми без автоматического failover. Последовательные зависимости перемножаются: если приложению нужны сервер, база и платёжный API, каждый с 99.9 процента, весь путь — примерно 99.7 процента. Параллельное резервирование её повышает: два независимых сервера приложения, каждый из которых недоступен 0.1 процента времени, лежат одновременно лишь около 0.0001 процента — если их отказы действительно независимы, а общая база, регион или деплой часто эту независимость ломают. Разница между вашим SLO и 100 процентами — это error budget. Когда он в порядке, выпускайте фичи быстрее; когда исчерпан — притормозите и вкладывайтесь в надёжность. Так споры о надёжности превращаются в число, с которым согласны и бизнес, и инженеры.

09Стратегии деплоя и миграции expand-contract

Rolling deploy заменяет инстансы за балансировщиком по одному: дёшево, но какое-то время старая и новая версии обслуживают трафик вместе. Blue-green поднимает полное второе окружение и переключает трафик сразу, с мгновенным откатом обратным переключением, но на время релиза стоимость удваивается. Canary отправляет на новую версию небольшую долю трафика, скажем 5 процентов, и расширяет её, только если доля ошибок и задержка остаются в норме. Все три подхода требуют, чтобы две версии кода могли работать с одной и той же базой. Это делает возможным паттерн expand-contract: сначала expand (добавить новую колонку или таблицу, nullable, ничего не удаляя), задеплоить код, который пишет в обе и читает новую, сделать backfill пачками и только в одном из следующих релизов выполнить contract — удалить старую колонку. Никогда не переименовывайте и не удаляйте колонку в том же релизе, который перестаёт её использовать. Именно эта дисциплина, а не инструмент деплоя, делает релизы без простоя реальностью.

• Релиз 1: добавить nullable-колонку, задеплоить код, который пишет в старую и новую.
• Backfill небольшими пачками, вне пиковых часов, с логированием прогресса.
• Релиз 2: читать только новую колонку. Релиз 3: удалить старую.

10Алерты на то, что чувствуют пользователи: SLO и burn rate

Алерты на CPU или память создают шум: сервер с CPU на 90 процентах, который быстро обслуживает каждый запрос, — это нормально. Будите людей по симптомам, а при диагностике используйте метод RED для сервисов (rate, errors, duration) и USE для ресурсов (utilisation, saturation, errors). Самый надёжный паттерн — burn-rate алерт из Google SRE workbook: алерт срабатывает, когда error budget расходуется намного быстрее, чем позволяет SLO, с проверкой по длинному и короткому окну, чтобы он быстро срабатывал при реальных инцидентах и быстро гас после них. Burn rate 14.4, державшийся час, съедает 2 процента 30-дневного бюджета — ради этого стоит кого-то разбудить. Более медленный расход превращается в тикеты, а не в пейджи. Держите под контролем кардинальность меток Prometheus: ID пользователей или полные URL в качестве меток создают миллионы рядов и могут положить систему мониторинга ровно тогда, когда она нужна.

1groups:
2  - name: slo
3    rules:
4      - alert: ErrorBudgetFastBurn
5        expr: |
6          (sum(rate(http_requests_total{status=~"5.."}[1h]))
7            / sum(rate(http_requests_total[1h]))) > (14.4 * 0.001)
8          and
9          (sum(rate(http_requests_total{status=~"5.."}[5m]))
10            / sum(rate(http_requests_total[5m]))) > (14.4 * 0.001)
11        for: 2m
12        labels:
13          severity: page
14        annotations:
15          summary: "99.9% SLO error budget burning 14x too fast"

11Планирование мощностей по закону Литтла

Закон Литтла гласит: среднее число запросов в системе равно скорости поступления, умноженной на время пребывания в ней. При 200 запросах в секунду и среднем времени ответа 250 ms в каждый момент обрабатывается около 50 запросов, значит, нужно минимум 50 воркеров PHP-FPM или эквивалентная параллельность плюс запас. Если задержка удвоится из-за замедления базы, тому же трафику понадобится 100 воркеров — вот почему медленные зависимости так внезапно исчерпывают пулы воркеров. Планируйте под пики, а не под средние значения: у многих продуктов в часы пик или во время кампаний трафик в три–десять раз выше среднего. Держите загрузку в стабильном режиме около 50–70 процентов, чтобы отказ узла или всплеск не опрокинули остальные. Перед запусками проводите нагрузочное тестирование инструментом вроде k6, наращивая нагрузку, пока задержка не начнёт расти, и запишите, где это происходит: это и есть ваша реальная мощность. Стоимость подчиняется той же логике: подбирайте размер по измеренным пикам и следите за egress и хранилищем, которые растут незаметно.