Konfiguration als Daten

(Abschnitt: Architektur und Protokolle)

1) Idee und Unterschied zu „Konfiguration als Code“

Configuration as Data (CaD) ist die Darstellung einer Konfiguration als typisiertes, deklaratives, validiertes Modell, unabhängig vom ausführbaren Code und verwaltet als Geschäftsdaten: mit Versionen, Diagrammen, Migrationen, Audits und Tests.
Im Gegensatz zur „Konfiguration als Code“, bei der die Logik der Config-Erzeugung in Mustern/Skripten lebt, schließt CaD Imperativität aus der Quelle der Wahrheit aus: keine Schleifen, Bedingungen und versteckte Logik innerhalb der Config. Alles - reine Daten + striktes Schema + Richtlinien.

Die Hauptziele sind: Vorhersehbarkeit, Diff-Fähigkeit, Änderungssicherheit, schnelle Pullbacks, progressive Lieferfähigkeit und automatische Compliance-Kontrolle.

2) Prinzipien von „config as data“

1. Deklarativität und Eindeutigkeit: Wir beschreiben den gewünschten Zustand, nicht die Schritte der Erreichung.
2. Typsicherheit und Schemata: JSON Schema/Protobuf/Avro/OpenAPI für strenge Verträge.
3. Unbeweglichkeit des Artefakts: Config-Bilder werden versioniert und signiert (Provenance).
4. Validierung und Politik: In der Pipeline - Syntax → Semantik → Policy-as-Code (OPA, Regeln).
5. Beobachtbarkeit von Config: Versionsabdruck in Logs/Metriken/Traces.
6. Verantwortungsteilung: Daten (config), Schema (Vertrag), Politik (Einschränkungen), Controller (Umsetzung).
7. Modularität und Schichten: Global, Regional, Tenant-, Produkt-, Fiche-Ebenen, mit vorhersehbarem Merge und Prioritäten.

3) Konfigurationssimulation: Schema als Vertrag

Entity-Familien: Routing, Limits, Ficheflags, Tarife, AB-Segmente, Kontingente, Risikoregeln, Finnkonfigurationen usw.
Typen: explizites enum/oneOf, Bereiche, Regex, referenzielle Integrität (ref/ID).
Versionierung von Schemata: „v1 → v1beta2 → v2“ (deprecation-plan, Migrationen).
Defaulting/Mutation: Sicheres Stillschweigen in der Validierungsphase; deterministische Reihenfolge der Anwendung.
Constraint-s: Geschäftsbeschränkungen (z.B. 'rateLimit <= 2000 rps' pro Tenant).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) Schichten, Vererbung und Konfliktlösung

Иерархия: `global → region → environment → tenant → product → cohort → user`.
Merge-Regeln: deklarativ - „zuletzt gewonnen“ (override) oder strategisch (merge/patch/replace per field).
Validierung an Kreuzungen: Wir verbieten widersprüchliche Schlüssel, wir fordern eine explizite Override.
Die Visualisierung des endgültigen effective-config ist obligatorisch (deterministische Diffuse).

5) Konfigurationslebenszyklus (GitOps-Paradigma)

1. Die Quelle der Wahrheit: ein Repository mit Daten + Diagrammen + Richtlinien.

• syntaktische Prüfung (lint),
• Validierung nach dem Schema,
• semantische Prüfungen/Tests,
• policy-as-code (z.B. OPA/Rego),
• sichere Migrationen (siehe § 7),
• Unterschrift und Veröffentlichung des Schnappschusses.
• 3. Promotion: PR-Adressen zwischen den Verzeichnissen 'dev/qa/staging/prod' oder den Ringen' ring-0/.../ring-N'.
• 4. Lieferung: Controller/Operatoren ziehen frische Snap-Shots auf, die über einen Reconcile-Zyklus angewendet werden.
• 5. Audit und Reversibilität: Alle Änderungen werden nachverfolgt; Rollback - revert commit/rollback snapshot.

6) Lieferung und Verteilung von Config

Statisch (Pull-on-Start): Wir laden den Snap-Shot am Start, Neustart zum Update.
Dynamisch (watch/stream): etcd/Consul/ZooKeeper, Kubernetes API/CRD, eigener Config Service.
Protokolle: gRPC/REST mit ETag/If-None-Match, Long-Poll/Watch, Snapshots + inkrementelle Diffs.
Caching: lokale Snapshots mit TTL und Signatur; Atomwechsel (Doppelpufferung).
Sequenz: strong (leader/quorum) vs eventual (edge/IoT). Für kritische Systeme - Quorum + RA.
Globale Rollouts: nach Regionen/Ringen (Ring-Deploy), mit einer Grenze von gleichzeitigen Zonen.

7) Migration von Konfigurationsdaten

• Expand: Wir führen neue Felder mit Auslassungen ein, ohne die Verbraucher zu brechen.
• Migrate: Backfills/Konverter (Migrations-Skriptanbieter, Idempotenz).
• Vertrag: Entfernen Sie veraltet, wenn alle Controller auf einer neuen Version des Schemas sind.
• Kompatibilitätsregel: Die alte Logik versteht das Neue, die neue das Alte in der Übergangszeit.

8) Politik, Compliance und Sicherheit

Policy-as-code: Rego/Conftest/OPA Gatekeeper - Verbote gefährlicher Werte (z.B. 'timeout = 0', TLS-Abschaltung, unbegrenzte Kontingente).
RBAC/ABAC: Wer welche Abschnitte und auf welchen Schichten wechseln kann.
Multilaterale Zulassung (vier Augen) für sensible Segmente (Zahlungen/Limits).
Geheimnisse: Wir speichern außerhalb der allgemeinen Config (KMS, Vault, SOPS), in Config - nur Links/Referenzen.
Signaturen und Vertrauen: Überprüfung von Lieferungen (Attestationen), Verbot von unsignierten Snapshots.
Desinfektion: Schutz vor Injection in Templates und beim Rendern.

9) Beobachtbarkeit, SLO und Risikomanagement

Config-Tags in der Telemetrie:'{config _ digest, config_version, ring, scope} 'in Protokollen/Metriken/Traces.
Golden-Metriken von Config-Flusen: Anwendungszeit, Erfolgsquote, Anzahl der Pullbacks, Konsistenzzeit.
Tore beim Rollen von Konfigs: Wie für den Code - kanarische Schritte und Auto-Stop für den Abbau von SLO.
Dogfooding: zunächst intern/beta-kohorta.

10) Hot-Reload, Transaktionalität und Anwendungssicherheit

Atomic Switch: Die neue Konfiguration wird im Speicher → eine einzige atomare Schaltung vorbereitet.
Dry-run: Validieren und simulieren Sie die Anwendung (einschließlich Feldkonflikt/Richtlinien).
Partieller Ausfall: Eine Alles-oder-Nichts-Strategie für verwandte Komponenten oder eine klare Beschreibung von Degradationen.
Backoff/Retry: Bei Anwendungsfehler - Sicheres Rollback und Wiederholung mit exponentieller Verzögerung.

11) Ficheflagi als Teilmenge der Config

Ficheflags sind Config-Daten mit speziellen Richtlinien: Segment-Targeting, Einschaltradius-Beschränkungen, Kill-Switch.
Anforderungen: deterministische Targeting-Semantik, Audit, Safe Defaults, Client/Server-Versionskompatibilität.

12) Instrumente und Medien

Medien: JSON/YAML/TOML/Protobuf/Avro (für Netzwerkzustellung - häufiger Protobuf/JSON).
Render/Komposition: Kustomize/Helm/Jsonnet (als Generatoren, aber unter dem Strich reine Daten).
Speicher/Busse: Git, OCI-Register (als Artefakte), S3-konforme Speicher, etcd/Consul/KV.
Controller: eigene Betreiber, GitOps-Agenten, Sidecar-Config-Anbieter.
Politik: OPA/Rego, Kyverno-ähnliche Mechanismen.

13) Checklisten

Projektierung

• Schema an erster Stelle (JSON Schema/Proto), Typen/Einschränkungen/Ausfälle beschrieben.
• Die Versionierung und Migration von Schemata ist dokumentiert.
• Schichtenhierarchie und Merge-Strategie definiert und getestet.

Pipeline

• Lint → schema-validate → semantic tests → policy-check → sign → publish.
• Dry-run und effective-config Visualisierung für Rezensenten.
• Canary Roll Config mit Auto-Gates durch SLO.

Prod

• Es gibt 'config _ digest' in den Protokollen/Metriken.
• Konfiguration zurücksetzen - mit der gleichen Schaltfläche wie das Code Deplet.
• Snap Shots/Config Backups und Audit History sind verfügbar und verifiziert.

14) Häufige Anti-Muster

Der Imperativ im Config: Bedingungen/Skripte/Muster mit Logik - unbelehrbar und unberechenbar.
Mischen Sie Geheimnisse und allgemeine Einstellungen in einer Datei/einem Repository.
Undurchsichtige Merge: Unklar, woher der endgültige Wert stammt.
Das Fehlen eines Schemas: „Alles ist gültig“ ⇒ Bugs auf dem Produkt.
Globale Bearbeitungen ohne Ringe/Kanarienvögel: sofortige Degradierung für alle.
Das Treiben der Umgebungen: Manuelle Bearbeitungen im Rantayme an der Quelle der Wahrheit vorbei.
Lange TTL im Config-Cache ohne Zwangsinvalidenmechanismus.

15) Szenarien (Skizzen)

A. Feinabstimmung der Verkehrslimits nach Regionen

1. PR mit den Änderungen 'RateLimitPolicy' zu 'ring-0' (interne Clients).
2. Auto-Checks: Schema/Politik (Limit ≤ 2k rps).
3. Promotion auf 'ring-1' (5% der Nutzer), Überwachung p95/Fehlerrate.
4. Erweiterung auf 'Ring-N', Fixieren des Schnappschusses, Schließen der Aufgabe.

B. Aktualisierung des Tarifs (finnische Anpassungen)

starke Semantik und Geschäftspolitik: doppelte Überprüfung, zweistufige Werbung, Zeitfenster für die Einführung, Audit und die Möglichkeit des sofortigen Rollbacks.

C. Global Ficheflag Payments Config Flag mit Kill-Switch: Targeting „employees → beta → 10% → 100%“, automatischer Stopp, wenn die erfolgreiche Zahlungsrate unter die Schwelle fällt.

16) Integration mit Zero-Downtime und progressiver Lieferung

Die Config-Kanarienvögel sind mit den Release-Ringen synchronisiert.
Versionskompatibilität: erst Erweiterungsfelder, dann Code, dann Verschärfungen.
Schatten-Configs: parallele Berechnung von Entscheidungen (z.B. Limiting) zum Vergleich mit dem Kampf.

17) Zusammenfassung

Der Ansatz „Konfiguration als Daten“ verwandelt Einstellungen von fragilen Dateien in robuste Domänenmodelle mit klaren Verträgen, Validierung und Richtlinien. Es ist die Grundlage für vorhersehbare Rollouts, sichere Experimente und schnelle Reaktionen auf Vorfälle. Formalisieren Sie Schemata, trennen Sie Geheimnisse, implementieren Sie GitOps und kanarische Config-Pushes - und die Konfiguration ist kein Risiko mehr, indem Sie ein verwaltetes Plattformvermögen werden.