Cele poziomu usługi (SLO)
| Wskaźnik | Cel (best-effort) | Cel (docelowy production) | Pomiar |
|---|---|---|---|
| Uptime (dostępność) | best-effort | 99,5% | Sonda /health (uptime-check), agregacja na /status |
| Latency (p95) | orientacyjnie <500 ms | <300 ms | /metrics (Prometheus, m.in. relay_latency_ms) |
| Error rate (odpowiedzi 5xx) | <1% | <0,5% | /metrics (Prometheus, liczniki błędów) |
| Backup (kopie zapasowe) | snapshoty DB | dzienne + offsite | Snapshoty wolumenów Fly / Postgres |
| RTO (czas odtworzenia) | best-effort | <1 h | Procedura odtworzeniowa + raport po incydencie |
| RPO (punkt odtworzenia) | best-effort | <24 h | Częstotliwość snapshotów DB |
Architektura niezawodności
Compute
Fly.io HA
Aplikacja unionai-core działa w trybie wysokiej dostępności na 2 maszynach w regionie iad (Ashburn, USA). Ruch jest rozkładany przez proxy Fly, a rolling deploy minimalizuje przerwy przy aktualizacjach.
Trwałość danych
Postgres
Stan federacji (rejestr agentów, kotwice pamięci, audyty, zdarzenia governance) trzymany jest w Postgresie. Snapshoty wolumenu stanowią podstawę kopii zapasowych oraz celów RTO/RPO.
Warstwa szybka
Redis + fallback in-memory
Redis obsługuje rate-limiting, cache i koordynację. W razie niedostępności Redis system automatycznie przełącza się na fallback in-memory (degradacja per-maszyna), co podtrzymuje działanie usługi kosztem części współdzielonego stanu.