# ENTERPRISE-RESILIENS AUDIT (2026-06-04 23:xx UTC)
> Erik: "Tänk om vi har 10 000 betalande kunder och api-anrop går ner — förödande. Utvärdera vad mer vi kan göra för enterprisedrift."

## FAKTISKA FYND (inspekterat, ej antaget)

### 🔴 KRITISKA SINGLE POINTS OF FAILURE
1. **EN host kör ALLT** — server-2: ~9 PM2 Node-tjänster + 27 Rust-mikrotjänster + amos-core (AI-kärna). Servern dör → hela plattformen dör. Ingen LB, ingen auto-scaling, ingen hot standby för prod.
2. **RDS single-AZ** — `platform-identity-core` db.t4g.small, **MultiAZ=FALSE**. ALL affärsdata + quiXzoom + ledger. DB-failure → total otillgänglighet tills manuell snapshot-restore (timmar). Detta är farligast NU.
3. **db.t4g.small** — pytteliten DB-klass för 27+ tjänster. Klarar absolut INTE 10 000 betalande kunder.
4. **AI-provider kredit kan ta slut tyst** — hände med Grok idag. Ingen auto-failover på kredit/kvot-fel i model-router.

### 🟡 FINNS MEN OVERIFIERAT/OFULLSTÄNDIGT
- circuit-breaker.mjs finns (3 varianter) — oklart om aktivt överallt
- model-router fallbackChain finns för compliance-modeller — men INTE kredit-failover
- rate-limit-middleware finns, Redis-cache finns, RabbitMQ kör
- RDS backup retention 35 dagar + daglig auto-snapshot ✅ (bra!)
- quiXzoom foton på S3 (durable) ✅
- K8s-kluster finns (buildkit/kong/platform LBs) men prod-tjänster körs EJ i k8s

### ✅ AI-PROVIDERS KREDIT (live-testat)
Anthropic/OpenAI/Perplexity/Groq/Gemini/DeepSeek = OK. xAI/Grok = TOM (ticket skapad).

## ÅTGÄRDSPLAN (prio efter risk × enkelhet)

### P0 — GÖR FÖRST (farligast, relativt enkelt)
1. **RDS Multi-AZ ON** — enda kommando/konsol-toggle, AWS sköter synkron replikering + auto-failover. Eliminerar #2. RTO från timmar → ~60-120s. (Winston godkänner kostnad, Johan kör.)
2. **AI-provider auto-failover** i model-router — vid 429/quota/credit-fel → nästa provider i kedjan. Aldrig hårt fel. (Johan, PROV-002 redan skickad.)
3. **Uppgradera RDS-klass** — db.t4g.small → minst db.r6g.large/xlarge. Kapacitet för skala.

### P1 — NÄSTA (host-redundans)
4. **Andra host + load balancer** — minst 2 EC2 bakom ALB över olika AZ. Stateless Node/Rust-tjänster replikeras. En host dör → andra tar över.
5. **Health-checks + auto-restart** — ALB health-probes, auto-replace döda instanser.
6. **Observability-stack** — central strukturerad logg (correlation IDs, tenant-tag), distributed tracing, per-provider AI-metrics (qps/felrate/latens/kostnad), SLO-dashboards.
7. **Graceful degradation** — definiera core vs nice-to-have per domän. AI-fel → deterministisk fallback. DB-skrivfel → read-only-läge. Integration nere → köa i RabbitMQ (outbox-pattern), visa "pending" ej hårt fel.

### P2 — MOGNAD (enterprise-grade)
8. **Multi-region DR** — async-replikerad standby i annan region. Offsite-backup utanför primär AWS (WORM/air-gapped).
9. **SLA-formalisering** — internt SLO 99,95%, sälj 99,9%. Definiera "downtime" per tenant. Koppla breach till krediter.
10. **Failover-/restore-ÖVNING** — kvartalsvis. (Bara 25% av SaaS testar faktiskt — vi ska vara i de 25%.)
11. **Load-test** — simulera 10 000 kunders last innan vi har dem.
12. **Idempotenta writes + spend caps** på AI-lagret.

## BENCHMARK (Perplexity, källor [1][2])
- 99,9% = 43 min nedtid/mån (de flesta B2B-SaaS). 99,99% = 4,3 min (kräver multi-region + 24/7 on-call).
- Vanligaste misstag: lovar 99,99% utan multi-region; har DR-dok men övar aldrig (75% övar ej); hårdkodar OpenAI-direkt utan adapter/failover.
- Vi har RÄTT byggstenar (circuit-breaker, queue, cache) men de är inte satta i system för failover.

## TICKETS: skickade till Johan (teknisk) + Winston (kostnad/godkännande)

---

## ✅ EXEKVERAT (Erik godkände kostnad 2026-06-04 23:25 UTC)

### RES-001 Multi-AZ — KLART ✅
- Säkerhetssnapshot tagen (pre-multiaz) + 3 dagliga auto-snapshots som återställningspunkter
- `aws rds modify-db-instance --multi-az --apply-immediately`
- MultiAZ: false → **true**. Synkron standby i annan AZ. RTO timmar → ~60-120s.
- NOLL nedtid under konvertering — alla appar (quixzoom/ledger/amos-core) online + DB-anslutna hela tiden. Verifierat.

### RES-003 Klassuppgradering — PÅGÅR ⏳
- t4g.small (2GB RAM) → **r6g.large (16GB RAM)**, `apply-immediately`
- Multi-AZ ger standby-först-uppgradering = minimal nedtid (sekunder vid failover istället för minuter)
- Cron-vakt (5min) verifierar slutförande + bekräftar till Erik + self-cleanup
- App online under hela processen (verifierat löpande)

### Resultat
Värsta single point of failure (single-AZ DB) ELIMINERAD inför lansering.
DB-kapacitet 8x (2→16GB) för 10k kunder.

### Kvar (ticketat)
- RES-004 Andra host + ALB (Winston godkänt kostnad — kan köras härnäst)
- PROV-W1..6 provider-kort (Winston)