Аудит и перестройка отказоустойчивого Nginx+PHP-FPM+PostgreSQL стека на 2 VPS с жесткими SLO

Исходная ситуация: есть 2 VPS в Hetzner (Ubuntu 22.04) для B2B SaaS (пиковая нагрузка до 800 одновременных пользователей, ~120 req/s). Сейчас все крутится на одном сервере: Nginx, PHP-FPM, PostgreSQL 14, Redis, cron, отправка почты. При пиках появляются 502/504, периодически забивается диск, бэкапы делаются нерегулярно, обновления ставятся руками. Второй VPS пустой, хотим использовать его для отказоустойчивости и безопасных бэкапов.

Техническая среда и ограничения:
- Доступ: SSH root на оба сервера, домен и DNS у Cloudflare
- Нельзя менять код приложения и схему БД, допускаются только изменения конфигурации ОС и сервисов
- Допустимое окно деградации/переключения ночью - до 10 минут, полная недоступность - не более 2 минут
- Нельзя покупать дополнительные managed-сервисы, только возможности двух VPS и Cloudflare
- Нужно оставить возможность обслуживать систему без Docker/Kubernetes (разрешено использовать systemd и стандартные пакеты)

Что нужно сделать по этапам:
1) Диагностика проблем производительности и надежности на текущем сервере - анализ логов Nginx/PHP-FPM/PostgreSQL, нагрузочные узкие места, дисковая подсистема, лимиты systemd, сеть, таймауты, настройки keepalive, буферы, slow queries
2) Переразметка ролей на 2 VPS:
- VPS-1 - frontend: Nginx, PHP-FPM, Redis (если нужен локально), cron
- VPS-2 - база и бэкапы: PostgreSQL + репликация/резервирование, хранение бэкапов, минимальные сервисы
3) Настройка PostgreSQL с акцентом на стабильность - корректные параметры памяти/автовакуум, архивирование WAL, контроль роста, базовый hardening, мониторинг задержек
4) Резервное копирование и проверка восстановления - ежедневные base backup + WAL (или иной обоснованный подход), ротация, шифрование, тестовый restore в отдельную БД/каталог, документация процедуры восстановления
5) Безопасность и эксплуатация:
- firewall (ufw/nftables) с минимально необходимыми портами, ограничение доступа к PostgreSQL
- SSH hardening (ключи, отключение паролей, fail2ban или аналог)
- автоматические обновления безопасности (unattended-upgrades) с контролируемой перезагрузкой
6) Наблюдаемость:
- метрики и алерты: загрузка CPU/RAM/disk, I/O wait, заполнение диска, количество 5xx, время ответа, репликация/лаг, бэкап-джобы
- допускается Prometheus node_exporter + simple alerting (например, через Alertmanager/telegram) или иной стек, но без тяжелых платформ
7) План переключения при аварии - пошаговая инструкция, как переключить приложение на резервный сервер/резервную БД в пределах ограничений по времени

Конкретный результат:
- Два сервера с разделенными ролями, документированной схемой, с настроенными бэкапами и проверенным восстановлением
- Конфиги Nginx/PHP-FPM/PostgreSQL и systemd-юниты приведены в состояние, где их можно воспроизвести (в идеале - через Ansible, но допустимы и аккуратные скрипты + README)
- Отдельный файл с картой портов/доступов и списком внесенных изменений

Измеримые критерии приемки:
- На стороне Nginx доля 5xx за 24 часа под типичной нагрузкой - не более 0.1%
- P95 времени ответа по access-логам Nginx - не хуже текущего значения и целевое улучшение минимум на 20% после тюнинга (фиксируем базовую линию в начале работ)
- Бэкап-цепочка проходит ежедневно, хранится минимум 7 точек восстановления, и выполнен хотя бы 1 тестовый restore с отчетом
- При искусственной недоступности VPS-1 или VPS-2 есть рабочая процедура переключения, укладывающаяся в ограничения (до 2 минут полной недоступности, до 10 минут деградации ночью)
- Все сервисы после перезагрузки серверов автоматически поднимаются без ручных действий

Важно: работа включает анализ и ответственность за изменения на проде. Перед внесением рискованных изменений - согласование плана действий и отката.