Audit et reconstruction d'une stack Nginx+PHP-FPM+PostgreSQL tolérante aux pannes sur 2 VPS avec des SLO stricts

Situation initiale : il y a 2 VPS dans Hetzner (Ubuntu 22.04) pour le SaaS B2B (charge de pointe jusqu'à 800 utilisateurs simultanés, ~120 req/s). Désormais, tout fonctionne sur un seul serveur : Nginx, PHP-FPM, PostgreSQL 14, Redis, cron, envoi de mail. Aux pics, 502/504 apparaissent, le disque s'encrasse périodiquement, les sauvegardes sont effectuées de manière irrégulière, les mises à jour sont installées manuellement. Le deuxième VPS est vide, nous souhaitons l'utiliser pour la tolérance aux pannes et les sauvegardes sécurisées.

Environnement technique et limites :
- Accès : racine SSH aux serveurs, au domaine et au DNS depuis Cloudflare
- Vous ne pouvez pas modifier le code de l'application et le schéma de la base de données, seules les modifications de la configuration du système d'exploitation et des services sont autorisées.
- Fenêtre de dégradation/commutation autorisée la nuit - jusqu'à 10 minutes, indisponibilité totale - pas plus de 2 minutes
- Vous ne pouvez pas acheter de services gérés supplémentaires, uniquement les capacités de deux VPS et Cloudflare
- Il est nécessaire de laisser la possibilité de maintenir le système sans Docker/Kubernetes (il est permis d'utiliser les packages systemd et standard)

Ce qu'il faut faire par étapes :
1) Diagnostic des problèmes de performances et de fiabilité sur le serveur actuel - analyse des logs Nginx/PHP-FPM/PostgreSQL, goulots d'étranglement de charge, sous-système disque, limites systemd, réseau, délais d'attente, paramètres keepalive, tampons, requêtes lentes
2) Réattribution des rôles sur 2 VPS :
- VPS-1 - frontend : Nginx, PHP-FPM, Redis (si nécessaire localement), cron
- VPS-2 - base de données et sauvegardes : PostgreSQL + réplication/réservation, stockage des sauvegardes, services minimaux
3) Configuration de PostgreSQL en mettant l'accent sur la stabilité - paramètres de mémoire corrects/vide automatique, archivage WAL, contrôle de croissance, renforcement de base, surveillance de la latence
4) Tests de sauvegarde et de récupération - sauvegarde de base quotidienne + WAL (ou autre approche raisonnable), rotation, chiffrement, test de restauration vers une base de données/répertoire séparé, documentation de la procédure de récupération
5) Sécurité et fonctionnement :
- pare-feu (ufw/nftables) avec le minimum de ports requis, restreignant l'accès à PostgreSQL
- Renforcement SSH (clés, désactivation des mots de passe, fail2ban ou similaire)
- mises à jour de sécurité automatiques (mises à niveau sans surveillance) avec redémarrage contrôlé
6) Observabilité :
- métriques et alertes : charge CPU/RAM/disque, attente d'E/S, saturation du disque, nombre 5xx, temps de réponse, réplication/lag, tâches de sauvegarde
- Prometheus node_exporter + alerte simple (par exemple, via Alertmanager/telegram) ou une autre pile est autorisé, mais sans plateformes lourdes
7) Plan de basculement : instructions étape par étape sur la manière de basculer une application vers un serveur de sauvegarde/une base de données de secours dans les délais impartis.

Résultat spécifique :
- Deux serveurs avec des rôles séparés, un schéma documenté, des sauvegardes configurées et une restauration éprouvée
- Les configurations Nginx/PHP-FPM/PostgreSQL et les unités systemd sont mises dans un état où elles peuvent être reproduites (idéalement via Ansible, mais des scripts soignés + README sont également acceptables)
- Un fichier séparé avec une carte des ports/accès et une liste des modifications apportées

Critères d'acceptation mesurables :
- Du côté de Nginx, la part est de 5xx en 24 heures sous charge typique - pas plus de 0,1%
- Temps de réponse P95 basé sur les journaux d'accès Nginx - pas pire que la valeur actuelle et un objectif d'amélioration d'au moins 20 % après réglage (nous fixons la ligne de base au début des travaux)
- La chaîne de sauvegarde s'exécute quotidiennement, au moins 7 points de restauration sont stockés et au moins 1 restauration test avec rapport est effectuée
- En cas d'indisponibilité artificielle du VPS-1 ou du VPS-2, il existe une procédure opératoire de commutation qui s'inscrit dans les limites (jusqu'à 2 minutes d'indisponibilité totale, jusqu'à 10 minutes de dégradation la nuit)
- Tous les services sont automatiquement restaurés après le redémarrage des serveurs sans actions manuelles

Important : le travail comprend l'analyse et la responsabilité des changements dans la production. Avant d'apporter des changements risqués, convenez d'un plan d'action et d'un retour en arrière.