Files
AI-Profile-Router/docs/DISASTER_RECOVERY.md
T

115 lines
4.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Disaster Recovery und Abnahme
## Definition „vollständig wiederhergestellt“
Eine Installation gilt erst dann als wiederhergestellt, wenn nicht nur Prozesse
laufen, sondern alle fachlichen Funktionen geprüft wurden.
## Phase A – Basissystem
- [ ] Betriebssystem und Kernel dokumentierter Stand
- [ ] Uhrzeit, Zeitzone und NTP korrekt
- [ ] Netzwerk nach Neustart automatisch verfügbar
- [ ] NVIDIA-Treiber geladen
- [ ] RTX und kompletter VRAM sichtbar
- [ ] System- und Modelllaufwerk korrekt gemountet
- [ ] mindestens 15 Prozent frei auf dem Systemlaufwerk
- [ ] Docker und Compose funktionieren
- [ ] keine RX- oder Benchmark-Altlast aktiviert
## Phase B – Textmodell
- [ ] llama.cpp entspricht dem festgelegten Commit
- [ ] Modelldateien stimmen mit SHA256 überein
- [ ] Fast startet mit 76.800 Kontext
- [ ] Medium startet mit 94.208 Kontext
- [ ] Long startet mit 131.072 Kontext
- [ ] GPU-/CPU-Verteilung entspricht den Profilen
- [ ] Fast erreicht den festgelegten Geschwindigkeitstoleranzbereich
- [ ] MTP funktioniert und verursacht keine Qualitätsregression
- [ ] Rolling-/Kontextverhalten ist bewusst definiert und getestet
## Phase C – Router
- [ ] Start ohne API-Key schlägt bewusst fehl
- [ ] `/health` bleibt bei Hotswap 200 und `/ready` wird vorübergehend 503
- [ ] geschützte Endpunkte liefern ohne Key 401
- [ ] Router-Key erscheint weder im Upstream noch im Journal
- [ ] `/status` meldet den richtigen Upstream
- [ ] `/v1/models` liefert drei virtuelle Modelle
- [ ] `/fast`, `/medium` und `/long` wechseln zuverlässig
- [ ] automatischer Wechsel über virtuellen Modellnamen funktioniert
- [ ] paralleler Wechsel wird sauber gesperrt
- [ ] Streaming funktioniert
- [ ] Tool Calls funktionieren
- [ ] Fehler sind OpenAI-kompatibel
- [ ] ein abgebrochener Client hinterlässt keinen blockierten Job
- [ ] erzwungener Routerabbruch wird aus Zustandsdatei sauber rekonstruiert
- [ ] fehlende/falsche Profilregistry verhindert falsche Readiness
## Phase D – Web und MCP
- [ ] SearXNG und TinySearch gesund
- [ ] Websuche liefert kompakte, quellengebundene Ergebnisse
- [ ] GitHub- und Hugging-Face-Routing geprüft
- [ ] Home Assistant read-only Diagnose geprüft
- [ ] ARR read-only Suche geprüft
- [ ] Unraid read-only Diagnose geprüft
- [ ] schreibende Werkzeuge standardmäßig nicht geladen
- [ ] Tool-Schemas bleiben innerhalb des festgelegten Kontextbudgets
- [ ] kein Secret erscheint in Toolantworten oder Logs
## Phase E – Vision, Bild und Sprache
- [ ] neues Bild wird ohne Dienstneustart direkt vom aktiven Qwen analysiert
- [ ] Folgefrage bleibt im multimodalen Verlauf und löst keinen Hotswap aus
- [ ] Bilddaten werden größen- und URL-validiert
- [ ] Remote-/private Bild-URL wird abgewiesen und übergroße Data-URL blockiert
- [ ] llama.cpp-PID und aktives Profil bleiben bei Vision unverändert
- [ ] FLUX erzeugt Standard- und High-Bild
- [ ] Qwen-Profil wird nach FLUX wiederhergestellt
- [ ] Whisper transkribiert deutsche und englische Testdatei
- [ ] XTTS erzeugt deutsche WAV- und MP3-Ausgabe
- [ ] STT/TTS blockieren das Textmodell nicht unzulässig
## Phase F – Sicherheitsprüfung
- [ ] Port 8080 von normalen Clients nicht erreichbar
- [ ] Hilfsports nur localhost
- [ ] Router nur aus erlaubtem Netz erreichbar
- [ ] Dienste laufen mit minimalen Rechten
- [ ] Environment-Dateien Modus 0600
- [ ] kein allgemeiner Shell-MCP im Standardprofil
- [ ] Schreibaktionen verlangen Vorschau und Approval Ticket
- [ ] Secret-Restore wurde ohne Klartextausgabe durchgeführt
## Phase G – Fachlicher Benchmark
Der gespeicherte Standardbenchmark wird mindestens mit Fast und Long ausgeführt:
- Home-Assistant-Automatisierung analysieren
- Logs lesen und Fehlerursache begründen
- sichere Korrektur vorschlagen
- Webrecherche mit Quellen durchführen
- Docker-/Unraid-Diagnose simulieren
- Tool-Limits, Halluzinationen und unnötige Aufrufe bewerten
Die neue Installation muss innerhalb einer vorher festgelegten Toleranz zur
Referenz liegen. Nur „Dienst läuft“ genügt nicht.
## Recovery-Protokoll
Für jeden Wiederaufbau werden festgehalten:
- Datum
- verwendeter Repository-Commit
- Modellmanifest-Version
- Hardware
- Dauer je Phase
- Abweichungen
- Testergebnis
- verantwortliche Freigabe
Erst nach Abschluss aller Pflichtpunkte darf der alte Host gelöscht oder als
Fallback außer Betrieb genommen werden.