quick reference - smart-village-solutions/sva-studio GitHub Wiki
Zielgruppe: On-Call Engineer um 3 Uhr nachts Zweck: Schnelle Entscheidungshilfe — ist dieses PR betriebsreif?
Frage: Können wir PR #45 (Monitoring Stack) in Production deployen?
Antwort:
❌ NEIN – nicht ohne diese 5 Sachen:
1. Alerting konfigurieren (AlertManager + Slack)
2. Backup-Script testen
3. Container Resource Limits setzen
4. Disaster Recovery Runbooks schreiben
5. Redis zum docker-compose hinzufügen
| Gap | Impact | Fix-Zeit |
|---|---|---|
| ❌ Keine Alerting | Nobody gets paged at 3am | 1-2 Tage |
| ❌ Keine Backup-Strategie | 7 Tage Datenverlust möglich | 2-3 Tage |
| ❌ Keine Resource Limits | OOMKiller kann Container töten | 0.5 Tag |
| ❌ Keine DR-Runbooks | Blind debugging bei Incident | 1-2 Tage |
| ❌ Kein Redis in Compose | Sessions verloren nach Restart | 0.5 Tag |
| Gap | Impact | Fix-Zeit |
|---|---|---|
| Updates können schiefgehen | 1 Tag | |
| Stille Fehler möglich | 1 Tag | |
| Daten-Loss bei Restarts | 0.5 Tag |
| Feature | Status | Nutzen |
|---|---|---|
| Health Checks alle Services | ✅ OK | Docker kann Container neu starten |
| Pinned Image Versions | ✅ OK | Keine Überraschungen durch Auto-Updates |
| PII-Redaction | ✅ OK | Logs sind DSGVO-sicher |
| Workspace Context | ✅ OK | Multi-Tenancy-Isolation |
| Retention Policies (7d) | ✅ OK | Datenschutz + Kostenersparnis |
Symptom: Metriken-Abfragen werden immer langsamer
Diagnose: df -h | grep prometheus
Lösung: Kein Alert → Dienstleister schläft
Impact: 🔴 KRITISCH
Symptom: Alle Benutzer werden plötzlich abgemeldet
Diagnose: docker logs sva-studio-redis | grep error
Lösung: Kein Backup → Manueller Recovery nötig
Impact: 🔴 KRITISCH
Symptom: Container wird nach 4h neu gestartet, Logs weg
Diagnose: docker logs sva-studio-otel-collector (ephemeralisch!)
Lösung: Kein Resource Limit → OOMKiller tötet Container
Impact: 🔴 KRITISCH
Symptom: Neue Logs landen nicht in Loki
Diagnose: curl http://localhost:3100/loki/api/v1/ready
Lösung: Kein Alert → Error unbemerkt
Impact: 🟠 HOCH
- Alerting (AlertManager + Slack) implementieren
- Container Resource Limits setzen
- Redis zu docker-compose hinzufügen
- Backup-Script schreiben + testen
- Disaster-Recovery-Runbooks schreiben
- Alerting getestet (fake page test)
- Backup-Restore-Prozedur getestet
- Upgrade/Rollback-Prozedur dokumentiert
- Load test mit 10x normalen traffic durchgeführt
- Post-mortem für Failure-Szenarien geschrieben
- docker-compose.yml vorhanden
- Alle Services haben healthchecks
- .env Handling dokumentiert
- Init-Scripts für Datenbank-Migration vorhanden
- Startup-Logs hilfreich für Troubleshooting
- Image-Versionen sind pinned
- Einzelne Service-Updates möglich
- Rollback-Plan dokumentiert
- Backward Compatibility tested
- Upgrade-Runbook vorhanden
- Prometheus-Backup-Strategie
- Loki-Backup-Strategie
- Redis-Session-Backup
- RTO/RPO definiert
- Restore-Test durchgeführt
- DR-Plan vorhanden
- AlertManager konfiguriert
- Alert Rules definiert
- Notification Channels (Slack/Email)
- Alert-Test durchgeführt
- Escalation Policy definiert
- Health Checks auf alle Services
- Self-Monitoring (wer monitort das Monitoring?)
- Memory/CPU Limits gesetzt
- Graceful Shutdown dokumentiert
- Circuit Breaker konfiguriert
- Load Balancer / Reverse Proxy Setup
- OTLP Protocol-Versionierung
- Blue/Green Deployment möglich
- Canary Release möglich
- Memory Limits pro Service
- CPU Limits pro Service
- Disk I/O IOPS requirements dokumentiert
- Performance Baselines vorhanden
- Auto-Scaling Policies definiert
-
Kein Alerting
- Team schläft, während Fehler passiert
- Fix: Slack integration für kritische Alerts
-
Keine Backups
- Daten weg, Wiederherstellung dauert Stunden
- Fix: Automatisches tägliches Backup-Testing
-
Keine Resource Limits
- OOMKiller tötet Container unerwartet
- Fix: Limits setzen, Monitoring für approaching limits
-
Keine Runbooks
- Debugging statt Ops
- Fix: Vorgebahnte Recover-Prozeduren schreiben
-
Keine Graceful Shutdown
- Updates = Datenverlust
- Fix: stop_grace_period + drain time
- ❌ 2 Stunden Debugging um 3 Uhr
- ❌ 4 Stunden RCA am nächsten Morgen
- ❌ Geschäftsauswirkungen (Benutzer können nicht loggen)
| Szenario | Wahrscheinlichkeit | Datenverlust | Recovery-Zeit | User Impact |
|---|---|---|---|---|
| Prometheus Disk voll | 🟠 Medium | Metriken | 1-2 Stunden | Dashboard kaputt |
| Redis Crash | 🔴 Hoch | 7 Tage Sessions | 2-3 Stunden | Alle abgemeldet |
| OTEL Memory Leak | 🟡 Niedrig | Logs | 30 Min | Logs fehlen |
| Loki Log-Fehler | 🟡 Niedrig | Logs | 1 Stunde | Logs in Loki fehlen |
Mit implementierten Fixes:
- Alert @ Minute 1 → Response @ Minute 5 → Gelöst @ Minute 20
- Vs. ohne Fixes: Alert @ Minute 90 (Customer anruft) → Response @ Minute 100 → Debugging bis 5am
#monitoring-alerts:
[3:05 AM] 🔴 CRITICAL: Prometheus disk usage > 95%
Action: Run recovery-steps/clean-prometheus-disk.md
Runbook: https://...
[3:10 AM] 🟠 WARNING: OTEL Collector memory approaching limit
Action: Monitor or restart
Runbook: https://...
[3:15 AM] 🔴 CRITICAL: Redis offline, sessions at risk
Action: Check health, restart if needed
Runbook: https://...
[3:20 AM] 🟠 WARNING: Metrics not flowing to Prometheus (5m stale)
Action: Diagnose Prometheus scrape issues
Runbook: https://...
Situation 1: PR Review Meeting
- Zeige diese Card dem Team
- Erkläre die 5 Blocker
- Agree auf Sprint-Plan
Situation 2: Staging-Approval
- Prüfe "Vor Staging" Checklist
- Gib conditional approval
- Markiere P0 Tasks
Situation 3: Incident um 3am
- Konsultiere "Top-Szenarien" Tabelle
- Folge dem Runbook
- Schreibe Incident Log mit dieser Card
Version: v1.0 Last Updated: 2026-02-08 Audience: Engineering + Operations Teams