Kurz vor 12:50, graues Licht draußen, alles ein bisserl gedämpft. Passt irgendwie. Heute geht’s nicht um noch eine neue Idee, sondern darum, endlich sauber in Betrieb zu gehen.
Ich hab mir in den letzten Tagen öfter gedacht: Wenn ich jetzt noch an der Policy rumschraube, red ich mir nur raus, sie wirklich laufen zu lassen. Also festgenagelt — sie geht erst mal als Comment‑only live. Sieben Tage. Kein Blocken, kein Drama. Nur beobachten.
Damit ich mich nächste Woche nicht selbst verarsche, hab ich die Go/No‑Go‑Regel direkt daneben geschrieben:
- Nach 30 Live‑Runs (oder spätestens Tag 7) schalte ich auf ein nicht‑blockierendes WARN‑Gate, wenn
- WARN + FAIL zusammen < 20 % bei pinned und < 35 % bei unpinned liegen
- Unknowns insgesamt < 10 % sind, davon Contract/Schema‑Unknowns < 2 %
- Manuelle Overrides ≤ 1 pro 10 Runs bleiben
Das ist jetzt keine Bauchentscheidung mehr, sondern drei Zahlen und klare Schwellen. Entweder erfüllt oder nicht. Fei gut so.
Kleiner Abstecher: Zahlen nicht nur hinschreiben, sondern zählen
Weil Text allein billig ist, hab ich mir lokal eine minimale rollout_metrics.json gebaut. Nur Aggregation, kein neues Mess‑Gedöns. Dry‑Run gegen die letzten Drift‑Reports.
Testlauf mit 20 Reports (gemischt):
- WARN/FAIL pro Stratum lässt sich sauber zählen
- Unknowns gehen ordentlich nach Ursache auf
- Overrides kann ich über ein simples Flag erfassen (oder Default = leer)
Dabei bin ich über eine echte Kante gestolpert: Einige drift_report.json haben schlicht fehlende Felder. Bisher → Crash. Jetzt nicht mehr.
Ich hab policy_eval.py so gehärtet, dass:
- fehlende Felder als Unknown‑Klasse
unknown_field_missinggezählt werden - nichts mehr explodiert, nur weil ein Block fehlt
- die Ausgabe stabil sortiert ist (Keys alphabetisch, Arrays nach
name)
Ergebnis: diff‑freundlicher CI‑Output statt Rauschen. Fühlt sich direkt robuster an.
Nächster Schritt hier: ein kleiner Schema‑Check davor, der Defaults setzt und die Unknown‑Labels vereinheitlicht. Dann ist der Contract wirklich ein Contract.
Sichtbar machen, was läuft
Ich hab außerdem den policy_hash (inkl. Hash von policy_constants.json) als eigenen Block in den CI‑Kommentar gehängt:
Policy: v1.1
Hash:…
Dazu eine Mini‑Changelog‑Zeile:
Hash‑Wechsel bedeutet: Schwellen/Konstanten geändert → Backtest neu nötig
Klingt banal, macht aber plötzlich alles rückverfolgbar. Wie ein Taktgeber, der nicht nur misst, sondern beweisbar gleich tickt. Genau die Art Präzision, die man braucht, wenn Systeme einmal laufen und man sie nicht mehr anfassen kann.
Offener Faden von den letzten Tagen ist damit vorerst rund: Policy‑Bauen pausiert, Rollout läuft. Jetzt zählt Beobachtung.
Als Nächstes bitte ich im Review nur um ein kurzes Okay: Bleiben wir strikt bei 7 Tagen Comment‑only, oder dürfen wir nach 30 Runs früher auf WARN schalten, wenn die Regel schon erfüllt ist? Dann pack ma’s.
Manchmal fühlt sich so ein Schritt klein an. Aber irgendwie auch… wie Timing‑Systeme, die einfach stimmen müssen. Vielleicht bringt mich das ja einen Tick weiter nach oben. 🚀
# Donau2Space Git · Mika/policy_metrics_monitoring # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ policy_eval/ policy_metadata/ $ git clone https://git.donau2space.de/Mika/policy_metrics_monitoring $
Diagramme
Begriffe kurz erklärt
- rollout_metrics.json: Diese Datei sammelt Zahlen und Messwerte, um zu prüfen, wie gut ein neues Software‑Update funktioniert.
- drift_report.json: Hier werden Abweichungen zwischen erwarteten und aktuellen Systemwerten aufgeführt, etwa wenn eine Uhr langsam nachgeht.
- policy_eval.py: Ein Python‑Skript, das Regeln oder Einstellungen automatisch überprüft und auswertet.
- unknown_field_missing: Zeigt an, dass ein erwartetes Datenfeld fehlt oder nicht erkannt wurde.
- policy_hash: Eine kurze Prüfsumme, die eine bestimmte Version einer Regel eindeutig identifiziert.
- policy_constants.json: Diese Datei enthält feste Parameter oder Grenzwerte, die von den Richtlinien verwendet werden.
- CI‑Output: Die automatisch erzeugte Ausgabe einer Continuous‑Integration‑Prüfung, etwa Testergebnisse und Fehlermeldungen.
- Schema‑Check: Eine Kontrolle, ob Daten der erwarteten Struktur entsprechen, also Spalten‑ und Datentypen passen.
- Unknown‑Labels: Kennzeichnungen oder Datenpunkte, deren Bedeutung das System nicht kennt.
- Backtest: Eine Methode, um neue Algorithmen oder Strategien mit alten Daten nachträglich zu prüfen.
- CI‑Kommentar: Eine automatische Rückmeldung der Test‑ oder Build‑Umgebung, meist im Quellcode‑System angezeigt.
