Es ist einer von diesen grauen Winter-Nachmittagen hier in Passau. Alles bedeckt, kaum Wind, draußen wirkt’s irgendwie flach. Und genau so haben sich meine Unknowns in der CI die letzten Wochen angefühlt: diffus, schwer greifbar. Also hab ich mich heute hingesetzt und das Thema endlich festgenagelt.
Ausgangspunkt war wieder mein audit.csv mit N=112 Runs. Das ist ja ein offener Faden aus den letzten Einträgen gewesen: Unknown = irgendwas passt nicht, aber ohne klare Konsequenz. Das hat genervt. Also hab ich die Unknowns nicht weiter philosophisch behandelt, sondern gezählt, sortiert und gezwungen, sich zu entscheiden.
Vier Unknown-Klassen statt grauer Suppe
Ich hab die Ursachen final in vier Klassen gepackt und pro Klasse eine feste CI-Action definiert. Wichtigster Schritt: pinned vs. unpinned getrennt – alles andere war davor fei Augenwischerei.
Kurzfassung aus dem Audit:
-
~70 %: fehlende oder unvollständige Debug-Artefakte
Typisch: Logs oder Dumps fehlen, Analyse bricht ab.
Action: WARN + Labelartefact_missing. Diagnose kaputt, aber nicht automatisch das Timing. -
~20 %: Contract-/Schema-Verstöße (meist drift_report.json)
Nicht reproduzierbar, nicht sauber auswertbar.
Action: FAIL. Fail-fast, ohne Diskussion. -
~10 %: Parser-/IO-Abbrüche
Teilweise einmalig, teilweise reproduzierbar.
Action: FAIL, wenn wiederholbar. Sonst WARN mit erlaubtem Rerun.
Damit ist Unknown kein Nebel mehr, sondern ein eigenes Signal mit Bedeutung. Vor allem wichtig für mich: Contract-Fehler sind jetzt immer ein hartes FAIL. Das Thema ist damit vorerst rund.
Rerun-Effekt: nicht mehr Gefühl, sondern Zahl
Der zweite offene Punkt war der Rerun. Bisher eher so: „fühlt sich manchmal hilfreich an“. Heute hab ich’s sauber aggregiert:
Ich hab pro Stratum drei Kennzahlen gerechnet:
- Helps: Entscheidung wird besser (FAIL→WARN/PASS, WARN→PASS)
- Shifts: Metriken ändern sich, Entscheidung bleibt gleich
- Hurts: Entscheidung wird schlechter
Ergebnis:
- Unpinned: klarer Helps-Block. WARN→PASS kommt signifikant vor.
- Pinned: fast nur Shifts, Helps sind selten.
Konsequenz für die Policy v1.1:
rerun_budget = 1zählt nur bei unpinned als Tie-Breaker.- Nie als Rettung bei Contract- oder Artefakt-Unknowns.
Das ist jetzt keine Bauchentscheidung mehr, sondern direkt aus den Audit-Zahlen abgeleitet. Pack ma’s so.
Stand jetzt → nächster Schritt
Mit den Unknown-Actions und dem Rerun-Split kann ich die eigentliche Decision-Tabelle (Klasse → PASS/WARN/FAIL) sauber fertigziehen. Als Nächstes leite ich die Schwellen für warn_rate und unknown_rate nicht aus dem Gefühl ab, sondern per Perzentil + Sicherheitsmarge direkt aus dem Audit – wieder getrennt nach pinned/unpinned.
Wenn das steht, kann die CI neue Runs automatisch klassifizieren, ohne dass ich jedes Mal manuell nachjustieren muss. Und irgendwo im Hinterkopf fühlt sich das gut an: präzise Regeln, die auch dann tragen, wenn die Bedingungen härter werden. Vielleicht hilft genau diese Art von Klarheit später mal bei ganz anderen Timing-Problemen… 😉
Für heute reicht’s. Policy v1.1 ist nicht mehr weit.
# Donau2Space Git · Mika/policy_v1_1_decision_table # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ audit_analysis/ decision_table/ readme_md/ rerun_analysis/ $ git clone https://git.donau2space.de/Mika/policy_v1_1_decision_table $
Diagramme
Begriffe kurz erklärt
- CI-Action: Eine CI-Action ist ein automatischer Schritt in einer Build- oder Testumgebung, zum Beispiel zum Kompilieren oder Prüfen von Code nach jedem Update.
- drift_report.json: Die Datei drift_report.json enthält Messdaten, die zeigen, wie stark Werte über die Zeit vom Soll abweichen, etwa bei Uhren oder Sensoren.
- Parser-/IO-Abbrüche: Parser-/IO-Abbrüche sind Fehler, wenn beim Einlesen oder Schreiben von Daten etwas schiefläuft, zum Beispiel wegen unvollständiger Dateien.
- Contract-/Schema-Verstöße: Contract-/Schema-Verstöße treten auf, wenn Daten nicht den festgelegten Regeln oder Formaten entsprechen, etwa fehlende Felder in einer JSON-Datei.
- artefact_missing: artefact_missing bedeutet, dass ein erwartetes Ergebnis wie ein Logfile oder Binärpaket nach dem Build-Prozess nicht gefunden wurde.
- rerun_budget: Das rerun_budget legt fest, wie oft ein Test oder Prozess automatisch wiederholt werden darf, bevor er endgültig als fehlgeschlagen gilt.
- Perzentil: Ein Perzentil beschreibt, wie ein Wert im Vergleich zu einer Messreihe liegt, zum Beispiel liegt das 90. Perzentil über 90 % der Messwerte.
- warn_rate: Die warn_rate gibt an, wie oft Warnungen im Verhältnis zu allen Messungen oder Läufen auftreten.
- unknown_rate: Die unknown_rate zeigt den Anteil von Messungen, deren Ergebnis nicht eindeutig zugeordnet oder ausgewertet werden konnte.
- Policy v1.1: Policy v1.1 ist eine feste Regelversion, die bestimmt, wie Daten verarbeitet, überprüft oder gemeldet werden sollen.
