Bereitstellen von Konfigurationen

1) Warum

Die Konfiguration ändert sich häufiger als der Code und wirkt sich direkt auf den Umsatz (PSP-Routing, Limits, Quoten, Front-End-Features) und die Compliance (KYC/AML, RG) aus. Wir brauchen einen wiederholbaren, überprüfbaren und reversiblen Prozess der Lieferung von Configs an Prod, mit strengen Toleranzen und Beobachtbarkeit.

2) Grundsätze

1. Konfiguration als Daten: Configs sind versionierbare Daten (YAML/JSON), keine „manuellen Klicks“.
2. Schema-first: Jeder Eintrag wird gegen das Schema (JSON Schema/Protobuf) validiert.
3. Richtlinien als Code: Gates, Toleranzen, SoD - im Richtlinien-Repository.
4. GitOps: die einzige Quelle der Wahrheit ist Git; Cluster werden durch den Reconsiler auf Linie gebracht.
5. Progressive Lieferung: Kanarienrollen, nach Segment (GEO/Tenant/Bank/Anbieter).
6. Zero-Downtime: Atomic Switches, doppelte Pufferung, Kompatibilität der Formate.
7. Beobachtbarkeit durch Design: Audit, Anwendungsmetriken, Driftdetektor.
8. Sicherheit: Minimale Privilegien, separate Geheimnisse, SoD/4-eyes auf riskante Änderungen.

3) Modell der Konfigurationen

Statisch: ändert sich selten, erfordert eine Freigabe (Ports, Kernel-Timeouts).
Dynamisch: Gelten ohne Restarts (PSP Routing, Fichi, Limits).
Geheimnisse: Schlüssel/Token; separate Schleife (KMS/Secret Manager).
Artefakte: Regeldateien/Mappings (BIN→bank, GEO→PSP, Bonuslimits).

Adressierungsschlüssel: 'tenant', 'region', 'environment', 'service', 'version', 'segment' (psp/bank_group/device).

4) Formate und Schemata

json
{
"$schema": "https://json-schema. org/draft/2020-12/schema",
"title": "pspRouting",
"type": "object",
"properties": {
"version": {"type": "string"},
"rules": {
"type": "array",
"items": {
"type": "object",
"required": ["geo","binGroup","primary","fallback"],
"properties": {
"geo": {"type":"string"},
"binGroup":{"type":"string"},
"primary":{"type":"string"},
"fallback":{"type":"array","items":{"type":"string"}},
"limits":{"type":"object","properties":{"perMinute":{"type":"integer"}}}
}
}
}
},
"required": ["version","rules"]
}

5) Lebenszyklus (GitOps)

1. Authoring: PR zum Config Repository: Daten + Link zum Ticket/Änderung.
2. Lint/Validate: CI: Schemata, Links, Semantik (Konfliktregeln), Dry-Run am Stand.
3. Policy Gates: SoD/4-eyes, Risikoklasse, Freeze-Fenster, Einhaltung des SLO-Status.
4. Staging Apply: Durchführung von Integrationstests/Synthetik, SLI-Validierung.
5. Progressive Lieferung: Prod Kanarienvogel (1-5%) → 25% → Region/Tenant → 100%.
6. Post-Monitoring: 30-60 min Metriken/Alert; Fixierung des Ergebnisses.
7. Promotion/Rollback: Release-Tags, schnelles Rollback über Git revert/„ vorherige Version “.

6) Rolling-Strategien

Kanarische nach Segmenten: 'tenant = A, geo = TR, bank = BIN _ XXXX'.
Nach Regionen: EU→LATAM→APAC unter Berücksichtigung der Stundenspitzen.
Nach Funktionalität: Einschalten der Flagge (Feature Flag) mit Guardrails (TTL, Coverage Limits).
Blau/Grün für die Config-Quelle: Umschalten der Leser auf den neuen Snap-Shot.

7) Dynamisches Laden und Kompatibilität

Heißer Neustart (Watchers/Konsuln/OTel Collector Pipeline Reload).
Doppelformat (v1 + v2): prod liest beides, die Hersteller schreiben in ein neues.
Konsistenz: Version in API-Antworten/Metriken, um zu sehen, wer auf welcher Konfiguration ist.

8) Sicherheit, Geheimnisse, SoD

Secrets separat: Speicherung im KMS/Secret Manager, Verschlüsselung auf Feldebene, Zugriffe über ABAC.
SoD/4-eyes: Änderung des Zahlungsroutings/Bonuslimits/PII-Exports - nur durch doppelte Genehmigung.
JIT-Rechte: temporäre Token für Transaktionen, vollständige Prüfung.
Sicherheitskontrollen: Der Linter verbietet PII/Testschlüssel im prod config.

9) Validierungen vor der Anwendung

Schaltungen (JSON Schema/Protobuf), Linter, Kardinalitätsprüfungen.
Domain-Semantik: keine Schleifen/Duplikate/“ schwarze Löcher“, Kompatibilität mit aktuellen Abhängigkeiten.
Shadow-Traffic/Simulationen: Neues Routing/Regeln auf echtem Stream als Read-No-Write „verjagen“.

SLO-Gate: Rote SLIs → Werbeverbot

10) Beobachtbarkeit und Audit

Einsatzmetriken: Anwendungszeit, Erfolg, Deckungsanteil, Parsingfehler, Rollbacks.
Ereignisse: Wer/Was/Wann/Warum, Diff (einschließlich Geheimhaltung).
Drift-Detektor: Vergleich von „Was ist in Git“ und „Was ist in Rantym“; alert bei Divergenz.
Instanzen (exemplars) - Referenziert 'trace _ id' von Config-Lesevorgängen.

11) Katalog der typischen Config (iGaming)

Zahlungen Routing: PSP durch GEO/BIN/Methode; Retraylimits; fichi 3DS.
KYC/AML: Anbieter, Timeouts, TTL, Fallback/manuelle Verifizierungsregeln.
Risiko & RG: Velocity-Limits, Tages-/Monatscaps, Geo-Ausnahmen.
Spiele/Kern: Cache-Koeffizienten, Poolgrößen, Ficheflags (Wiederholungshistorie, neue Modi).
Ops/Observability: Alert-Schwellenwerte, Sampling-Regeln, Retention-Klassen, Synthetik.
Status/Comms: Meldungsvorlagen, Lokalisierungen, Zeitplan für Aktualisierungen.

12) Beispiel Konfigurationspaket (Manifest)

yaml apiVersion: cfg. platform/v1 kind: ConfigRelease metadata:
id: payments-routing-2025-11-01 change: "RTE-421: reroute TR BIN_4571 → PSP2"
spec:
scope:
tenants: [brandA, brandB]
regions: [EU]
segments:
geo: [TR]
strategy:
steps:
- name: canary coverage: "5%"
duration: "20m"
- name: ramp coverage: "25%"
duration: "30m"
- name: region-full"
coverage: "100%"
gates:
require:
- policy: "slo-green"
- approval: ["Payments Lead","Compliance"]
- freeze: "not-in-effect"
rollback:
to: "payments-routing-2025-10-29"
autoIf:
- metric: "auth_success_rate"
condition: "drop>10% for 10m"

13) Rollbacks (Rollback) und Änderungssicherheit

Reverse via Git: 'revert '/' promote previous'.
Atomschalter: Die Leser schalten auf den einstigen Schnappschuss um.
Auto-Rollback-Kriterien: SLI/KRI-Degradation, Zunahme von Parsing/Validator-Fehlern.
Kommunikation: Der Incident-Bot veröffentlicht den Status beim Auto-Rollback.

14) Multi-Tenant und Geo-Residenz

Namespaces auf Datei-/Ordner- und Schlüsselebene ('tenant/region/env').
Lesepolitiker: Dienste sehen nur ihren Scope.
Geo-Kopien von Config (EU/LATAM/APAC) und verzögerte Replikation mit SLA.
Verschiedene Rollfenster für verschiedene Gerichtsbarkeiten (Compliance/Urlaub).

15) Leistung und Kosten (FinOps)

Snapshot-Cache: lokal/verteilt; TTL/ETag/If-None-Match.
Config Größe: Grenzen für das Volumen und die Tiefe der Strukturen; Aufteilung in Module.
Zugangskarte: Top-Verbraucher von Lesungen; Optimierung der Pullingfrequenz.
Fehlerkosten: Zähler für „teure“ Pullbacks/zusätzliche Kanarienvögel.

16) Integrationen

Alerting/SLO: Aufstiegstor, Auto-Rollbacks.
Release-gates: Blockierung von Code-Releases, wenn das Rollout von Configs nicht abgeschlossen ist.
Incident-Bot: Befehle '/config promote', '/config rollback', Links zu Diffs und Dashboards.
Workflow Engine: Human-Task für risikoreiche Änderungen; Eskalationszeitgeber.

17) KPI/KRI der Funktion

Lead Time Konfiguration: PR→prod.
Change Failure Rate (CFR): Anteil der Änderungen mit Rollback.
MTTR config Vorfall.
Driftrate: Häufigkeit der Diskrepanzen Git↔runtime.
SLO-Gates-Passrate: Der Anteil der Änderungen, die Gates ohne manuelle Ausnahmen durchlaufen haben.
Kosten pro Änderung: CPU/IO, Kanarienvögel, Vorfälle.

18) Umsetzungsfahrplan (6-10 Wochen)

Ned. 1-2: Config-Katalog, Schaltungen, Linter; Git-repo; Basis-CI (Validierung/Diff).
Ned. 3-4: GitOps-Reconsyler, Dry-Run/Staging, Status-Dashboards; Ficheflag mit TTL.
Ned. 5-6: Policy-as-Code (SoD/Windows/Freeze/SLO-Gates), Kanarienrollen, Auto-Rollback.
Ned. 7-8: Driftdetektor, Geheimnisse über KMS, Multi-Tenant und Geo-Kopien, Incident-Bot-Integration.
Ned. 9-10: Last-/Chaos-Rolling-Tests, FinOps-Report, Teamtraining und Templates.

19) Artefaktmuster

PR-Vorlage: Ziel, Risikoklasse, Bereich (tenant/region), Rollout-Plan, Rollback-Plan, Dry-Run-Ergebnisse.
Policy Pack: SLO-Gates, SoD/4-eyes, Freeze-Kalender, Größen-/Kardinalitätsgrenzen.
Runbook: „wie man die aktuelle Version/diff/Status der Kanarienvögel liest“, „wie man manuell die Promotion stoppt“.
Config Katalog: Besitzer, Schema, Leser, Aktualisierungshäufigkeit, Compliance-Hinweise.

20) Antipatterns

Manuelle Bearbeitungen „im Admin-Bereich“ ohne Git/Audit.
Configs gemischt mit Release-Artefakt-Code, ohne Hot-Swap-Fähigkeit.
Keine Schemata/Validierungen → Absturz beim Parsen.
Globales Einwegrollen ohne Kanarienvögel.
Gemeinsame Geheimnisse in config; Geheimnisse in Git.
Keine Pullbacks/TTL/guardrails bei den Ficheflags.
Kein Driftdetektor.
Entfernen von SLO-Gates „per Anruf“ und ohne Aufzeichnung.

Summe

Die Bereitstellung von Konfigurationen ist eine verwaltete Pipeline: Daten mit Schemata → Richtlinien und Gates → GitOps und progressive Bereitstellung → Hot Loading und Reversibilität → Beobachtbarkeit und Audit → Sicherheit und Kosten. Dieser Rahmen ermöglicht es Ihnen, das Verhalten der iGaming-Plattform schnell und sicher zu ändern und gleichzeitig SLO, Umsatz und Compliance zu erhalten.