Thore CimbalandClaude Opus 5
3e81f40178
Nach dem Deploy der CVE-Pipeline (gitops#47) als Verfahren festgehalten. Der Stand war korrekt und gelintet; der Blocker entstand erst aus der Datenmenge, gegen die er lief -- eine Alarm-Instanz pro CVE, real 126 CRITICAL und 1222 HIGH. So etwas faellt in keinem Diff auf, nur beim Messen vor dem Deploy. Neu: - .gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml -- Uebergabe-Issue mit Pflichtfeldern Mengengeruest, vollstaendiges Deploy-Kommando, Verifikation im laufenden Dienst, Aussenwirkung samt Not-Aus, Rollback - verfahren/deploy-uebergabe.md -- Ablauf und Pruefliste - verfahren/aar-vorlage.md -- AAR-Vorlage - verfahren/aar/2026-08-01-cve-pipeline-gitops47.md -- der ausloesende AAR Abgrenzung im README ergaenzt: hosts/ und shared/ halten offene Punkte, verfahren/ haelt, wie wir arbeiten. Die Uebergabe-Issues laufen bewusst hier statt im Projekt-Repo, weil das Verfahren repo-uebergreifend gilt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.6 KiB
Verfahren: Deploy-Übergabe
Für die Konstellation „einer baut, ein anderer rollt aus". Zweck ist nicht mehr Prozess, sondern weniger Rückfragen und weniger stille Fehlschläge.
Eingeführt am 2026-08-01 nach dem Deploy der CVE-Pipeline (gitops#47), siehe
aar/2026-08-01-cve-pipeline-gitops47.md.
Ablauf
- Wer baut, öffnet ein Issue aus der Vorlage Deploy-Übergabe
(
.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml). - Wer ausrollt, arbeitet die Prüfliste unten ab und deployt.
- Wer ausrollt, hängt den AAR als Kommentar an dasselbe Issue (Vorlage: aar-vorlage.md). Bei Befunden ab MEDIUM zusätzlich als Datei unter aar/.
Die vier Punkte, die den Unterschied machen
1. Mengengerüst vor dem Deploy
Bei allem, was etwas erzeugt — Nachrichten, Alarme, Zeitreihen, Requests — gehört die erwartete Anzahl beim ersten Lauf in die Übergabe. Geschätzt ist in Ordnung, gemessen ist besser; welches von beidem, muss dabeistehen.
Der Grund: „ein Alarm pro Fund" ist eine völlig unauffällige Zeile im Code und harmlos bei 5 Funden. Bei 126 ist es ein Ausfall. Der Unterschied steht nirgends im Diff — er ergibt sich erst aus den Daten, gegen die das Ding läuft.
Eine Stichprobe reicht: drei repräsentative Elemente von 29 messen und hochrechnen kostet Minuten und liefert die Größenordnung.
2. Verifikation dort, wo der Dienst liest
Ein grüner Linter belegt, dass eine Datei gültig ist — nicht, dass sie geladen wurde. Diese beiden Aussagen sind bei Bind-Mounts, Caches und Reload-Semantiken regelmäßig verschieden.
Also im Container prüfen, in der laufenden API, im tatsächlich geladenen Regelwerk. Ein Blick auf die Platte beweist nichts über den Prozess.
3. Deploy-Kommando vollständig übergeben
Inklusive Reload-, Restart- und Recreate-Schritten. Ein docker compose up -d,
das Running meldet und dabei nichts aktiviert, ist der häufigste stille
Fehlschlag: kein Fehler, kein Log, falscher Zustand.
Konkret auf dem Monitoring-Stack (CFGMON): Einzeldatei-Mounts hängen am Inode,
git pull benennt beim Schreiben um und erzeugt damit einen neuen — der
Container zeigt danach weiter auf die alte Datei. Es braucht
--force-recreate. Details: gitops#52.
4. Zustellwege stumm schalten statt Deploy verschieben
Datensammlung und Außenwirkung lassen sich fast immer getrennt scharf schalten. Wenn der Zustellweg das Risiko ist, wird er abgeklemmt — nicht der ganze Deploy verschoben.
So läuft die Datensammlung ab sofort, das Dashboard steht, echte Zahlen ersetzen die Schätzung, und die Entscheidung über die Zustellung fällt auf Basis von Messwerten statt Vermutungen. Wichtig: die Stummschaltung gehört committet und dokumentiert, sonst ist sie in zwei Wochen ein Rätsel.
Prüfliste für den Ausrollenden
- Diff gelesen, nicht nur die Beschreibung
- Mengengerüst plausibel? Bei Zweifel an einer Stichprobe selbst messen
- Configs mit den jeweiligen Werkzeugen validiert (
promtool,amtool,compose config,py_compile…) - Außenwirkung identifiziert — was verlässt beim ersten Lauf das System?
- Nach dem Deploy im Container verifiziert, dass die neue Config aktiv ist
- Geprüft, ob vorher gesunde Dinge noch gesund sind (keine stille Regression)
- AAR geschrieben, Folge-Issues angelegt, Stummschaltungen dokumentiert
Abgrenzung
Das Verfahren gilt für Übergaben zwischen Personen. Wer baut und ausrollt, braucht kein Issue — der AAR lohnt trotzdem, sobald es Befunde ab MEDIUM gab.