153 lines
4.4 KiB
Markdown
153 lines
4.4 KiB
Markdown
# Go/No-Go-Kriterien für Replikationsruns #15–#16
|
||
|
||
## Purpose
|
||
|
||
Dokumentation der Go/No-Go-Entscheidungslogik auf Basis der stabilen Latenz- und Heilungsmetriken aus Runs #14–#16.
|
||
|
||
**Problemstellung:** Bestimmen, ob die beobachtete Performance und Heilungsstabilität der near-expiry-unpinned-Fälle konsistent genug ist, um als Freigabekriterium zu dienen.
|
||
|
||
**Ziele:**
|
||
- Definieren reproduzierbarer Grenzwerte für Latenzverhalten
|
||
- Formalisieren der Go/No-Go-Regel zur Produktionsfreigabe
|
||
- Evaluieren der Stabilität von Heilungsraten
|
||
|
||
## Kontext & Hintergrund
|
||
|
||
Metriken der Runs #14–#16 mit identischem Setup (near-expiry-unpinned, Δt<0, fixed delay, 1 Retry).
|
||
|
||
**Gruppierung:**
|
||
- Run #14
|
||
- Run #15
|
||
- Run #16
|
||
|
||
**Trace-Metadaten / zusätzliche Tags:**
|
||
- retry_total_overhead_ms
|
||
- warn_rate
|
||
- unknown_rate
|
||
- healing_rate
|
||
|
||
**Domänenkontext:**
|
||
- Backend-Latenzmessung
|
||
- Retry-Mechanismusüberwachung
|
||
- Replikationsvalidierung
|
||
|
||
**Motivation:**
|
||
- Sicherstellen der Reproduzierbarkeit vorheriger Verbesserungen (#13/#14)
|
||
- Überführen experimenteller Resultate in belastbare Release-Kriterien
|
||
|
||
## Methode / Spezifikation
|
||
|
||
**Übersicht:**
|
||
- Analyse der Δt<0-Fälle und Heilungsraten pro Run.
|
||
- Berechnung von Latenzquantilen (p50, p95, p99, min, max).
|
||
- Aggregierte Auswertung der Runs #14–#16 zur Stabilitätsprüfung.
|
||
- Herleitung einer quantitativen Go/No-Go-Regel (Gate V1).
|
||
|
||
**Algorithmen / Verfahren:**
|
||
- Zähle alle Fälle mit Δt<0 pro Run.
|
||
- Berechne p50, p95, p99, min, max aus retry_total_overhead_ms.
|
||
- Berechne warn_rate, unknown_rate und Heilungsrate.
|
||
- Vergleiche die Kennzahlen über Runs hinweg.
|
||
- Prüfe die definierten Grenzwerte gemäß Go/No-Go-Regel.
|
||
|
||
## Input / Output
|
||
|
||
### Erwartete Rohdaten
|
||
|
||
**Felder pro Run:**
|
||
- run_id
|
||
- delta_t
|
||
- retry_total_overhead_ms
|
||
- warn_rate
|
||
- unknown_rate
|
||
- healing_rate
|
||
|
||
**Formatbeispiele:**
|
||
- {run_id:15, delta_t:-3.2, retry_total_overhead_ms:44, warn_rate:0.061, unknown_rate:0.00, healing_rate:1.00}
|
||
|
||
### Analyse-Ausgaben
|
||
|
||
**Pro Gruppe / pro Governor:**
|
||
- p50_overhead_ms
|
||
- p95_overhead_ms
|
||
- p99_overhead_ms
|
||
- min_overhead_ms
|
||
- max_overhead_ms
|
||
- healing_rate
|
||
- warn_rate
|
||
- unknown_rate
|
||
|
||
**Vergleichsausgaben:**
|
||
- Run #15 vs Run #16
|
||
- Δ: warn_rate_diff=0.002
|
||
|
||
## Workflow / Nutzung
|
||
|
||
**Analyse-Workflow:**
|
||
- Runs laden (#14–#16).
|
||
- Relevante Metriken extrahieren (Δt<0, retry_total_overhead_ms, warn_rate, ...) pro Run.
|
||
- Quantile über retry_total_overhead_ms berechnen.
|
||
- Vergleichstabellen erstellen und aggregiert auswerten.
|
||
- Validierung gegen definierte Go/No-Go-Kriterien durchführen.
|
||
|
||
### Trace-Template-Anforderungen
|
||
|
||
**Ziel:** Gleichbleibende Messstruktur zur Replikationsvalidierung.
|
||
|
||
**Erforderliche Tags & Metadaten:**
|
||
- run_id
|
||
- delta_t
|
||
- retry_total_overhead_ms
|
||
- warning_class
|
||
- retry_success_flag
|
||
|
||
**trace-cmd-Setup:**
|
||
- Alle Runs mit identischem Retry-Setup und fixer Delay-Konfiguration ausführen.
|
||
- Keine Änderungen an Kontrollparametern zwischen Runs #14–#16.
|
||
|
||
## Interpretation & erwartete Ergebnisse
|
||
|
||
**Kernbefunde:**
|
||
- Δt<0 tritt nur im near-expiry-unpinned-Stratum auf.
|
||
- Heilungsrate in allen Runs 100%.
|
||
- warn_rate bleibt stabil (≈0.06).
|
||
- Overhead-Verteilung eng und unter 80 ms (p95/p99).
|
||
|
||
**Implikationen für Experimente:**
|
||
- Reproduzierbarkeit der Abhilfe bestätigt.
|
||
- Definierte Grenzen für Produktionsfreigabe belastbar.
|
||
|
||
**Planungsziel:**
|
||
- Ziel: Einheitliche Freigabekriterien (Gate V1).
|
||
- Vorgehen:
|
||
- Festlegung quantitativer Latenzschwellen (p95≤80 ms, p99≤90 ms).
|
||
- Toleranzprüfung gegen warn_rate und unknown_rate.
|
||
- Validierung der Heilungsrate ≥99%.
|
||
|
||
## Limitationen & Fallstricke
|
||
|
||
**Datenbezogene Limitationen:**
|
||
- Nur drei Runs betrachtet; keine Langzeitvalidierung.
|
||
- Keine Variation anderer Strata oder Parameter.
|
||
|
||
**Kausalität & Generalisierbarkeit:**
|
||
- Resultate nur für near-expiry-unpinned-Kontext gültig.
|
||
- Keine Aussage zu anderen Retry-Strategien.
|
||
|
||
**Praktische Fallstricke:**
|
||
- Zu knappe Schwellen könnten bei Systemlast ungewollte No-Go-Ergebnisse erzeugen.
|
||
- Messrauschen bei Latenzen <50 ms kann Einfluss auf p95/p99 haben.
|
||
|
||
## Nächste Schritte & Erweiterungen
|
||
|
||
**Geplante Experimente:**
|
||
- Run #17 mit veränderter Delay-Strategie für Belastungstest.
|
||
- Langzeitserie über 10 Replikationen zur Stabilitätsmessung.
|
||
|
||
**Analyseziele:**
|
||
- Bootstrap-Konfidenzintervalle für Latenzquantile berechnen.
|
||
- Variabilität der warn_rate unter Produktionslast prüfen.
|
||
|
||
**Community-Beiträge:**
|
||
- Diskussion optimaler Schwellenwerte (80/90 vs. 70/80 ms).
|
||
- Integration der Go/No-Go-Regel in CI-Pipeline.
|