Freigabegenehmigungsprozess
1) Zweck und Verantwortungsbereich
Der Release-Genehmigungsprozess ermöglicht vorhersehbare und sichere Plattformänderungen ohne Verletzung von SLO, Umsatz und Compliance. Es deckt den gesamten Weg ab: von der Pull-Anfrage bis zur vollständigen Promotion in Prod und Post-Monitoring.
2) Grundsätze
1. SLO-first: Freigabe nur bei grünen SLI/ohne Burn-Rate erlaubt.
2. Kleine Chargen und Reversibilität: kanarische/progressive Lieferung, schnelles Rollback.
3. Policy-as-Code: Gates, SoD, Freeze-Fenster und Risikoklassen - automatisch verifiziert.
4. Eine einzige Quelle der Wahrheit: Artefakte/Configs/Flaggen - in Git wird die Umgebung von GitOps-reconsyler bereitgestellt.
5. Auditierung und Nachweisbarkeit: WORM-Logs, Entscheidungsweg, klare Eigentümer.
6. Standard-Sicherheit: Geheimnisse getrennt, minimale Privilegien, Geo-Gates.
7. Kommunikation ohne Überraschungen: Vorbereitete Vorlagen für interne/externe Updates.
3) Rollen und RACI
Release Manager (RM) - Besitzer der Pipeline, Kalender, Tore. A/R
Service Owner (SO) - Domain-Besitzer, nimmt das Risiko, bereitet Artefakte. A/R
SRE/Plattform - SLO-Gates, Rollouts, Auto-Rollbacks. R
QA Lead - Inspektionsstrategie, Testergebnisse. R
Sicherheit/Compliance - Scans, SoD, Regulatoren. C/A
CAB (Change Advisory Board) ist eine Lösung für die normale Klasse. A
On-Call IC/CL - Einsatzbereitschaft und Kommunikation. R/C
Stakeholder (Biz/Support/Partner) - informieren. I
4) Änderungsklassen und Abstimmungspfade
Upgrade - beim Überschreiten der Risikogrenzen (Zahlungen, RG, PII, Limits).
5) Release-Pipeline und Gates (Durchfluss)
Stufe 0. Planung und Kalender
Freeze-Fenster (Feiertage/Spiele), On-Call-Slot und CL, Bereitschaft für Statusvorlagen.
Phase 1. PR → Build
Linters/Lizenzen, SBOM, Unit/Contract Tests, Secret Scan.
Phase 2. Integration/Sicherheit
E2E (virtualisierte PSP/KYC-Anbieter), SAST/DAST, dependency review.
Phase 3. Staging/Probe
Parität mit Verkauf, Migration mit Reversibilität, Ficheflag bei 5-25%, Checkliste „Release Drill“.
Gate A - Qualität und Sicherheit (erforderlich)
+ Alle Tests/Scans sind grün
+ Schemata/Configs sind gültig, keine „roten“ SLI-Staging
+ SoD/4-eyes für High-Risk-Änderungen
Schritt 4. Pre-prod (kanarische Lieferung)
1-5% Traffic nach Segment (tenant/geo/bank), Laufzeitvalidierer, guardrails.
Gate B - SLO/Business Gate
+ keine SLO/KRI-Degradationen (Latenz/Fehler/Zahlung)
+ keine SRM/Anomalien in den Versuchsmetriken
+ Comms bereit: Statusentwurf/Partner
Schritt 5. Rump-up → 25% → 100% (Region/Tenant)
Schritt-für-Schritt-Promotion mit Post-Monitoring-Timern.
Schritt 6. Post-Monitoring (30-60 Min)
Release-Dashboard, Burn-Rate, Beschwerden/Tickets, Auto-Close/Rollback bei Verstößen.
6) Automatisierte Entscheidungen (Policy-Engine)
Pseudo-Regeln:- SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
- PII-export: `require dual_control if config. affects == "PII_EXPORT"`
- Freeze: `deny deploy if calendar. freeze && not emergency`
- Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`
7) Releaseartefakte
Release Manifest (erforderlich): Ziel, Risikoklasse, Bereiche (tenant/region), Flaggen, Migrationen, Rollout-Plan, Rollback-Plan, Eigentümer, Es-Call-Kontakte.
Evidence Pack: Testergebnisse/Scans, Screenshots von Dashboards Staging, Dry-Run Migrationen.
Komms Kit: Statusvorlagen (intern/extern/Partner), ETA/ETR.
Backout-Plan: die genauen Schritte des Rollbacks und die Kriterien, nach denen er ausgelöst wird.
yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"8) Kanarische/Blau-Grün/Feature-Flag Rollen
Canary - Safe Default: kleine Abdeckung, Segmentierung nach GEO/tenant/BIN.
Blau-Grün - für schwere Änderungen: Routenumschaltung, schnelles Rollback.
Flaggen sind für Verhaltensregeln: TTL, Kill-Switch, Guardrails, SoD.
9) Configs und Geheimnisse verwalten
Configs als Daten, Schemata und Validatoren; GitOps-Promotion mit Drift-Detektor.
Geheimnisse - im KMS/Secret Manager, JIT-Zugriff, Audit und Maskierung.
10) Kommunikation und Statusseiten
Intern: Var-Raum/Chat, On-Call-Alarm, Update-Vorlagen.
Extern: Publikationen nur über CL, vorproduzierte Entwürfe.
Partner (PSP/KYC/Studios): Gezielte Benachrichtigungen, wenn Integrationen betroffen sind.
Status: Die Veröffentlichung ist kein Vorfall, sondern hat ein Beobachtungsfenster mit Metriken.
11) Notfallfreigaben (Emergency)
Auslöser: P1-Degradation, Vulnerabilität, PII/RG-Risiken.
Pfad: IC + RM-Lösung → Mindestanzahl von Gates (Linter/Build) → Canary 1-2% → Überwachung → Förderung.
Obligatorisch: Post-Fact-CAB, Post-Mortem ≤ D + 5, Dokumentation von Kompromissen.
12) Audit, SoD und Compliance
SoD/4-eyes: Änderungen des PSP-Routings, Bonuslimits, Datenexporte.
WORM-Magazin: wer/was/wann/warum; Versionen von Richtlinien; Release-Diff/Flags/Config.
Geo/Privacy: Daten und Protokolle in der gewünschten Gerichtsbarkeit; keine PII in Artefakten.
13) Beobachtbarkeit und Nachkontrolle
Release-Dashboard: SLI (auth-success, bet→settle p99), Fehlerrate, Beschwerden, Konvertierung, Warteschlangen-Verzögerungen.
Alerts: Burn-Rate, SRM, 5xx Wachstum, PSP Abbau durch Banken/GEO.
Berichte: CFR, MTTR-Release-Incidents, durchschnittliche Post-Monitoring-Zeit, Auto-Rollback-Rate.
14) Prozess KPI/KRI
Lead Time for Change (PR→prod), Change Failure Rate, MTTR-Release-Vorfälle.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Coverage of Release Drill (Staging-Proben), SoD-Gewalt (Ziel ist 0).
Comms SLA (Verfügbarkeit von Entwürfen, Einhaltung von Timings).
15) Roadmap für die Umsetzung (6-10 Wochen)
Ned. 1-2: Änderungsklassen, Gates und Artefakte definieren; Aktivieren von Lintern, SBOM, Secret-Scan; Veröffentlichungskalender und Freeze.
Ned. 3-4: GitOps für Config, Canary/Blue-Green, SLO Gates, Comms Templates und Var Room.
Ned. 5-6: Policy-Engine (SoD/4-eyes, Risiko-Regeln), Auto-Rollback nach Metriken; dashboard der Releases.
Ned. 7-8: Proben (Stagingbohrungen), Integration mit Ficheflag/Incident Bot, KPI/KRI-Berichte.
Ned. 9-10: WORM-Audit, DR-Release-Übungen, CFR-Optimierung, Rollentraining (RM/SO/CL/IC).
16) Antipatterns
Releases ohne Reversibilität und Canary → massive Vorfälle.
Ignorieren Sie SLO-Gates „für eine Frist“.
Configs/Flags ohne Schaltungen und TTL → „gefrorene“ Zustände.
Manuelle Klicks in der Produktion ohne Git/Audit.
Öffentliche Updates ohne CL-Rolle und Vorlagen.
Geheimnisse im Repository; Zugriffe ohne JIT und Protokollierung.
CAB als Bremse ohne Daten: Entscheidungen müssen mit Release-Metriken untermauert werden.
Summe
Der Release-Genehmigungsprozess ist ein Engineering und Management-Framework, das Qualität, Sicherheit und Geschwindigkeit verbindet: Richtlinien als Code, SLO-Gates, progressive Bereitstellung, transparente Kommunikation und nachweisbares Audit. Dieser Ansatz reduziert CFR und MTTR, schützt Umsatz und Compliance und ermöglicht es Teams, Werte häufig und sicher freizugeben.