73 lines
4.8 KiB
Markdown
73 lines
4.8 KiB
Markdown
|
# 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)
|