Thore CimbalandClaude Fable 5
3fe05e7bd1
Die letzte Ausnahme von ADR-0002 ist erledigt. Sie bestand, weil CFGMON git.lab nicht erreichte; mit dem Site-to-Site-Tunnel (ADR-0004) ist der Grund weg. Umgezogen mit dem Werkzeug der ersten Migration (verfahren/issue-migration/ migrate.py), damit derselbe Fusstext und dieselbe Idempotenz gelten: - sorb/management#1 (offen) -> management#25 - sorb/management#2 (geschlossen) -> management#26, mit allen 11 Kommentaren Original-Autor und -Zeitstempel sind erhalten (der Admin-Token darf created_at setzen); die Gitea-Issues sind geschlossen und verweisen auf ihr Gegenstueck. Der Gitea-Tracker ist damit leer. Issue-Vorlage konvertiert statt kopiert: Gitea nutzt YAML-Issue-Forms, GitLab Markdown-Templates. Die Feld-Begruendungen - der eigentliche Wert der Vorlage, weil jedes Feld fuer eine real schiefgegangene Uebergabe steht - sind als Kommentare erhalten. .gitea/ ist entfernt, damit dort keine neuen Uebergaben mehr angelegt werden koennen. Nachgezogen: README, roadmap, CLAUDE.md, ADR-0002 (Ausnahme durchgestrichen + als zurueckgebaut markiert), ADR-0004 (Ernte eingeloest), hosts/overmind.md, hosts/cfgmon.md, verfahren/README.md, verfahren/deploy-uebergabe.md. 55 relative Links geprueft, keiner tot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
4.5 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 auf git.lab ein Issue aus der Vorlage Deploy-Übergabe
(
.gitlab/issue_templates/Deploy-Übergabe.md, im Feld Description template). - 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.
Kanonisierung nach CFGMON-Deploys (Topologie-Pflichtschritt)
CFGMON erreicht git.lab nicht — Commits aus Deploy-Sessions landen zwangsläufig direkt auf dem Gitea-Mirror und werden vom nächsten Mirror-Lauf kommentarlos überschrieben (zweimal passiert: dfe04c4→6ffab68 am 01.08. nachts, 2b715ca→0bd77e2 am 01.08. nachmittags). Deshalb gehört zu jeder Übergabe:
- CFGMON-Seite vermerkt den Commit-Hash im Übergabe-Issue (Feld „Stand").
- Mac-Seite kanonisiert zeitnah: Patch per
https://rohana.axion1337.de/sorb/<repo>/commit/<sha>.patchziehen (verwaiste Objekte bleiben eine Weile abrufbar),git am, Push nach git.lab. Der Hash ändert sich dabei — Autorschaft und Inhalt bleiben erhalten. - CFGMON vor dem nächsten Pull:
git fetch && git reset --hard origin/main(inhaltsgleich, nur neuer Hash).