Миграция и hardening production-кластера PostgreSQL + Patroni на Ubuntu с восстановлением репликации и настройкой бэкапов

Исходная ситуация
Сейчас используется PostgreSQL 14 в production для SaaS (мультиарендность, до 1200 rps в пике, ~900 ГБ данных). Кластер 3 узла (2x primary/standby + witness) на Ubuntu 20.04 в Hetzner Cloud, управление Patroni+etcd. После серии инцидентов замечены: периодические failover с split-brain, отставание реплики до 20-40 минут, barman-бэкапы иногда битые, а обновления ОС и Postgres откладывались. Планируется переход на Ubuntu 22.04 и PostgreSQL 16 с минимальным простоем, плюс наведение порядка в наблюдаемости и безопасной эксплуатации.

Техническая среда
- 3 VM (Hetzner Cloud), NVMe, сеть 1 Gbps
- Ubuntu 20.04 -> 22.04
- PostgreSQL 14 -> 16
- Patroni, etcd, HAProxy
- barman для PITR
- Prometheus + node_exporter уже есть, postgres_exporter местами настроен
- Доступ: SSH по ключу, ограничение по времени простоя - не более 10 минут на финальном переключении

Задача и ожидаемый результат
1) Провести анализ текущей конфигурации HA (Patroni/etcd/HAProxy/Postgres) и выявить причины split-brain и лагов репликации. Зафиксировать найденные проблемы и предложенные изменения в коротком отчёте.
2) Подготовить план и выполнить миграцию на PostgreSQL 16 и Ubuntu 22.04 с сохранением Patroni-кластера и прозрачным переключением для приложений через HAProxy.
3) Настроить бэкапы и проверку восстановления так, чтобы был гарантирован PITR и регулярная валидация бэкапов.
4) Усилить безопасность и эксплуатационную надёжность: ограничение сетевого доступа, корректные параметры kernel/limits, ротация логов, базовые меры hardening без фанатизма.
5) Привести мониторинг к состоянию, когда можно измеримо видеть lag репликации, состояние failover, заполнение дисков, длительные транзакции и рост WAL.

Ограничения
- Нельзя менять приложение и схему БД (только серверная часть и параметры Postgres/Patroni/HAProxy).
- Нельзя использовать managed DB, всё остаётся на текущем провайдере.
- Доступ к продакшену ограничен: работы в прайм-тайм только чтение и диагностика, изменения и переключения - по согласованному окну.
- Документация должна быть понятной инженеру, который будет сопровождать систему после завершения работ.

Критерии приёмки (измеримые)
- Финальное переключение на новый primary укладывается в 10 минут общего воздействия на сервис.
- Репликация в штатном режиме: lag standby < 5 секунд при средней нагрузке (по метрикам) и без накопления WAL.
- Исключён split-brain: корректная настройка quorum/ttl/loop_wait/retry_timeout и проверка сценария потери сети/узла на стенде или в согласованном окне.
- Бэкапы: ежедневный full или basebackup и непрерывный archiving WAL, успешная тестовая процедура PITR с восстановлением в отдельную VM до заданного времени.
- Мониторинг: в Prometheus доступны метрики Postgres (включая replication lag, WAL, long running queries), есть минимум 5 алертов (диск, лаг, недоступность узла, рост ошибок, остановка бэкапов).
- Передача артефактов: актуальные конфиги Patroni/HAProxy/Postgres, инструкции по обновлению и аварийному восстановлению, список выполненных изменений.

Этапы выполнения
- Аудит и фиксация текущего состояния, сбор метрик и логов, диагностика инцидентов.
- Проектирование целевой схемы и плана миграции с откатом.
- Развёртывание новых VM, перенос конфигураций, настройка Patroni/etcd/HAProxy.
- Миграция данных (pg_basebackup/pg_upgrade или согласованный метод), прогон проверок.
- Настройка barman и тест PITR.
- Настройка мониторинга и алертов, финальная проверка и передача документации.

Профессиональные инструменты, которые понадобятся
- patronictl, etcdctl, psql, pgBackRest или barman, pgbench (или аналог для прогонки), Prometheus exporters, tcpdump/ss, journald/rsyslog, Ansible (желательно) для воспроизводимости.

Важно
Нужна работа именно руками в инфраструктуре, с анализом и аккуратной миграцией, а не общая консультация.