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>
108 lines
4.0 KiB
YAML
108 lines
4.0 KiB
YAML
name: "Deploy-Übergabe"
|
|
about: "Ein gebauter, noch nicht ausgerollter Stand wird zum Deploy übergeben"
|
|
title: "[DEPLOY] "
|
|
body:
|
|
- type: markdown
|
|
attributes:
|
|
value: |
|
|
Für die Übergabe „ich habe gebaut — du rollst aus".
|
|
Ausführlich: [verfahren/deploy-uebergabe.md](../src/branch/main/verfahren/deploy-uebergabe.md)
|
|
|
|
Die Felder sind die Punkte, an denen Übergaben real schiefgegangen sind.
|
|
Wo nichts zutrifft, `-` eintragen statt das Feld zu löschen.
|
|
|
|
- type: input
|
|
id: stand
|
|
attributes:
|
|
label: Stand
|
|
description: Repo, Branch und Commit, der ausgerollt werden soll
|
|
placeholder: "sorb/threadnet-operating @ main, b6007c5"
|
|
validations:
|
|
required: true
|
|
|
|
- type: dropdown
|
|
id: testtiefe
|
|
attributes:
|
|
label: Testtiefe
|
|
description: Ehrlich einordnen — „ungetestet" ist eine brauchbare Angabe, „läuft" ohne Beleg nicht
|
|
options:
|
|
- "ungetestet — nur gelintet / statisch geprüft"
|
|
- "teilweise getestet — Details unten"
|
|
- "getestet gegen echte Daten"
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: mengengeruest
|
|
attributes:
|
|
label: Mengengerüst
|
|
description: |
|
|
Wenn der Stand irgendetwas erzeugt (Nachrichten, Alarme, Zeitreihen, Dateien, Requests):
|
|
Wie viel davon beim ersten Lauf? Geschätzt oder gemessen — bitte dazuschreiben, was von beidem.
|
|
Genau hier entstehen die Überraschungen: „ein Alarm pro Fund" ist harmlos bei 5 Funden und ein Ausfall bei 126.
|
|
placeholder: |
|
|
Alarme: ~1 pro CVE pro Image. An 3 von 29 Images gemessen: 27 CRITICAL / 126 HIGH.
|
|
Zeitreihen: ~2000. Matrix-Nachrichten: 1 pro Alarm.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: kommando
|
|
attributes:
|
|
label: Vollständiges Deploy-Kommando
|
|
description: |
|
|
Inklusive aller Reload-, Restart- und Recreate-Schritte.
|
|
Ein `up -d`, das „Running" meldet und nichts tut, ist der häufigste stille Fehlschlag.
|
|
render: bash
|
|
placeholder: |
|
|
cd /opt/<repo> && git pull
|
|
cd <stack> && docker compose up -d
|
|
docker compose up -d --force-recreate <dienste-mit-geaenderter-config>
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: verifikation
|
|
attributes:
|
|
label: Woran erkennt man, dass es wirklich greift
|
|
description: |
|
|
Konkrete Prüfung **dort, wo der Dienst liest** — im Container, in der API, in der laufenden Config.
|
|
Ein grüner Linter belegt, dass die Datei gültig ist, nicht dass sie geladen wurde.
|
|
render: bash
|
|
placeholder: |
|
|
docker exec prometheus grep -c axion-cve /etc/prometheus/alerts.yml # erwartet: 1
|
|
curl -s localhost:9090/api/v1/rules | grep -c axion-cve # erwartet: >0
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: aussenwirkung
|
|
attributes:
|
|
label: Außenwirkung und Not-Aus
|
|
description: |
|
|
Was verlässt beim ersten Lauf das System — Matrix-Räume, Mails, Webhooks, fremde APIs?
|
|
Und wie schaltet man **nur diesen Kanal** stumm, ohne den ganzen Deploy zu verschieben?
|
|
Datensammlung und Zustellung getrennt scharf zu schalten ist fast immer möglich und
|
|
macht aus einer Blockade einen normalen Deploy.
|
|
placeholder: |
|
|
Kanal: Matrix-Raum „Security" über Label room=security.
|
|
Stumm: in alertmanager.yml route room="security" -> receiver "null".
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: rollback
|
|
attributes:
|
|
label: Rollback
|
|
description: Was tun, wenn es schiefgeht — und was davon ist *nicht* zurückholbar (gesendete Nachrichten, externe Writes)?
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: offen
|
|
attributes:
|
|
label: Bewusst offen gelassen
|
|
description: Bekannte Lücken, Nebenfunde, Abgrenzungen. Verhindert, dass die Gegenseite Zeit mit Nachweisen von etwas verbringt, das schon bekannt ist.
|
|
validations:
|
|
required: false
|