Auditul și reconstrucția unei stive Nginx+PHP-FPM+PostgreSQL tolerante la erori pe 2 VPS cu SLO-uri stricte

Situație inițială: există 2 VPS în Hetzner (Ubuntu 22.04) pentru B2B SaaS (încărcare maximă până la 800 de utilizatori simultani, ~120 req/s). Acum totul rulează pe un singur server: Nginx, PHP-FPM, PostgreSQL 14, Redis, cron, trimiterea de mail. La vârfuri, apar 502/504, discul se înfundă periodic, backup-urile se fac neregulat, actualizările sunt instalate manual. Al doilea VPS este gol, vrem să-l folosim pentru toleranță la erori și copii de siguranță sigure.

Mediu tehnic și limitări:
- Acces: SSH root la ambele servere, domeniu și DNS de la Cloudflare
- Nu puteți modifica codul aplicației și schema bazei de date, sunt permise doar modificări ale configurației sistemului de operare și ale serviciilor
- Fereastra de degradare/comutare permisă pe timp de noapte - până la 10 minute, indisponibilitate completă - nu mai mult de 2 minute
- Nu puteți cumpăra servicii suplimentare gestionate, ci doar capabilitățile a două VPS și Cloudflare
- Este necesar să lăsați capacitatea de a menține sistemul fără Docker/Kubernetes (este permisă utilizarea pachetelor systemd și standard)

Ce trebuie făcut în etape:
1) Diagnosticarea problemelor de performanță și fiabilitate pe serverul curent - analiza log-urilor Nginx/PHP-FPM/PostgreSQL, blocajele de încărcare, subsistemul discului, limitele systemd, rețea, timeout-uri, setări keepalive, buffer-uri, interogări lente
2) Reatribuirea rolurilor pe 2 VPS:
- VPS-1 - frontend: Nginx, PHP-FPM, Redis (dacă este necesar local), cron
- VPS-2 - baza de date si backup: PostgreSQL + replicare/rezervare, stocare backup-uri, servicii minime
3) Configurarea PostgreSQL cu accent pe stabilitate - corectarea parametrilor de memorie/autovacuum, arhivare WAL, controlul creșterii, întărirea de bază, monitorizarea latenței
4) Testare de backup și recuperare - backup zilnic de bază + WAL (sau altă abordare rezonabilă), rotație, criptare, restaurare de testare într-o bază de date/director separat, documentare a procedurii de recuperare
5) Siguranță și funcționare:
- firewall (ufw/nftables) cu porturile minime necesare, restricționând accesul la PostgreSQL
- Hardening SSH (chei, dezactivare parole, fail2ban sau similar)
- actualizări automate de securitate (actualizări nesupravegheate) cu repornire controlată
6) Observabilitate:
- metrici și alerte: încărcare procesor/RAM/disc, așteptare I/O, umplere a discului, număr de 5xx, timp de răspuns, replicare/lag, joburi de rezervă
- Prometheus node_exporter + alertă simplă (de exemplu, prin Alertmanager/telegramă) sau alt stivă este permisă, dar fără platforme grele
7) Plan de failover - instrucțiuni pas cu pas despre cum să comutați o aplicație la un server de rezervă/bază de date de rezervă în limite de timp

Rezultat specific:
- Două servere cu roluri separate, o schemă documentată, copii de rezervă configurate și recuperare dovedită
- Configurațiile Nginx/PHP-FPM/PostgreSQL și unitățile systemd sunt aduse într-o stare în care pot fi reproduse (în mod ideal prin Ansible, dar sunt acceptate și scripturi ordonate + README)
- Un fișier separat cu o hartă a porturilor/accesurilor și o listă a modificărilor efectuate

Criterii de acceptare măsurabile:
- Pe partea Nginx, cota este de 5xx în 24 de ore sub sarcină tipică - nu mai mult de 0,1%
- Timp de răspuns P95 bazat pe jurnalele de acces Nginx - nu mai rău decât valoarea actuală și o îmbunătățire țintă de cel puțin 20% după reglare (fixăm linia de bază la începutul lucrării)
- Lanțul de backup rulează zilnic, sunt stocate cel puțin 7 puncte de restaurare și este finalizată cel puțin 1 restaurare de test cu un raport
- În cazul indisponibilității artificiale a VPS-1 sau VPS-2, există o procedură de operare de comutare care se încadrează în limite (până la 2 minute de indisponibilitate completă, până la 10 minute de degradare pe timp de noapte)
- Toate serviciile sunt restaurate automat după repornirea serverelor fără acțiuni manuale

Important: munca include analiza și responsabilitatea pentru schimbările în producție. Înainte de a face schimbări riscante, convineți asupra unui plan de acțiune și anulați.