在具有严格 SLO 的 2 个 VPS 上审核和重建容错 Nginx+PHP-FPM+PostgreSQL 堆栈

初始情况：Hetzner (Ubuntu 22.04) 有 2 个 VPS 用于 B2B SaaS（峰值负载高达 800 个并发用户，约 120 个请求/秒）。现在一切都在一台服务器上运行：Nginx、PHP-FPM、PostgreSQL 14、Redis、cron、发送邮件。在高峰期，会出现 502/504，磁盘会定期堵塞，不定期进行备份，手动安装更新。第二个VPS是空的，我们想用它来容错和安全备份。

技术环境和限制：
- 访问：从 Cloudflare 访问服务器、域和 DNS 的 SSH 根目录
- 您不能更改应用程序代码和数据库架构，只允许更改操作系统配置和服务
- 夜间允许降级/切换窗口 - 最多 10 分钟，完全不可用 - 不超过 2 分钟
- 您无法购买额外的托管服务，只能购买两个 VPS 和 Cloudflare 的功能
- 需要保留在没有Docker/Kubernetes的情况下维护系统的能力（允许使用systemd和标准包）

需要分阶段做的事情：
1) 诊断当前服务器的性能和可靠性问题 - 分析Nginx/PHP-FPM/PostgreSQL日志、负载瓶颈、磁盘子系统、systemd限制、网络、超时、keepalive设置、缓冲区、慢查询
2) 2 个 VPS 上的角色重新分配：
- VPS-1 - 前端：Nginx、PHP-FPM、Redis（如果本地需要）、cron
- VPS-2 - 数据库和备份：PostgreSQL + 复制/预留、备份存储、最少服务
3）设置PostgreSQL，重点是稳定性——正确的内存参数/autovacuum、WAL归档、增长控制、基本强化、延迟监控
4) 备份和恢复测试 - 每日基础备份 + WAL（或其他合理方法）、轮换、加密、测试恢复到单独的数据库/目录、恢复过程的文档
5）安全与操作：
- 具有最少所需端口的防火墙（ufw/nftables），限制对 PostgreSQL 的访问
- SSH 强化（密钥、禁用密码、fail2ban 或类似）
- 带受控重启的自动安全更新（无人值守升级）
6）可观测性：
- 指标和警报：CPU/RAM/磁盘负载、I/O 等待、磁盘满度、5xx 计数、响应时间、复制/滞后、备份作业
- 允许 Prometheus node_exporter + 简单警报（例如，通过 Alertmanager/telegram）或其他堆栈，但不支持重型平台
7) 故障转移计划 - 有关如何在时间限制内将应用程序切换到备份服务器/备用数据库的分步说明

具体结果：
- 两台具有独立角色的服务器、记录的方案、配置的备份和经过验证的恢复
- Nginx/PHP-FPM/PostgreSQL 配置和 systemd 单元进入可以复制的状态（最好通过 Ansible，但整洁的脚本 + README 也是可以接受的）
- 包含端口/访问映射和所做更改列表的单独文件

可衡量的验收标准：
- Nginx 端，典型负载下 24 小时内份额为 5xx - 不超过 0.1%
- 基于 Nginx 访问日志的 P95 响应时间 - 不比当前值差，并且调整后目标改进至少 20%（我们在工作开始时修复基线）
- 备份链每天运行，至少存储 7 个还原点，并完成至少 1 个带有报告的测试还原
- 在 VPS-1 或 VPS-2 人为不可用的情况下，有一个适合限制的切换操作程序（最多 2 分钟完全不可用，最多 10 分钟夜间降级）
- 重启服务器后所有服务自动恢复，无需手动操作

重要提示：工作包括对生产变化的分析和责任。在进行有风险的更改之前，请就行动计划和回滚达成一致。