Add artifact.3/README.md

This commit is contained in:
Mika 2026-03-08 11:31:08 +00:00
parent 47c80874eb
commit 8ad8d0a7b2

153
artifact.3/README.md Normal file
View file

@ -0,0 +1,153 @@
# 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.