Versionskontrolle von Konfigurationen

1) Warum versionieren Konfigurationen

Die Konfiguration ist eine ausführbare Richtlinie: Sie definiert Routing, Limits, Fich-Flags, Zugriffe, Datenschemata. Die Versionskontrolle macht Änderungen wiederholbar, vorhersehbar und reversibel: reduziert die MTTR und die Änderungsfehlerrate, beseitigt die „Magie in der Produktion“, gibt ein Audit für Sicherheit und Compliance.

2) Taxonomie der Konfigurationen

Infrastruktur (IaC): Cluster, Netzwerke, LB, DB, Warteschlangen.
Service: Anwendungsparameter, Ressourcen, Limits, Timeouts, Retrays.
Produkt-/Geschäftslogik: Tarife, AB-Experimente, Content-Regeln.
Daten/DataOps: Verträge von Schaltungen, SLA Frische, Transformation.
Sicherheit: Zugriffsrichtlinien, Rollen, Schlüssel/Zertifikate (die Geheimnisse selbst sind außerhalb des Repos).
Beobachtbarkeit: SLI/SLO, Alerts, Dashboards.

Regel: Alles, was das Verhalten des Systems beeinflusst, ist die Konfiguration und muss unter Versionierung leben.

3) Grundsätze der Versionierung

1. GitOps: die einzige Quelle der Wahrheit ist das Repository; Änderungen durch PR und automatische Pipelines.
2. Deklarativität: Beschreibung des Zielzustands, nicht Schrittskripte.
3. Die Unbeweglichkeit von Artefakten: config → eindeutig materialisierender Snap-Shot.
4. Schemata und Validierung: JSON/YAML-Schema, strikte Typanpassung, Pflichtfelder.
5. Umgebungen als Code: 'env' - Ordner/Overlays (dev/stage/prod), die Unterschiede sind minimal und offensichtlich.
6. Idempotenz und Rollbacks: Jede Konfigurationsfreigabe ist reversibel (revert/rollback).
7. Audit und Traceability: Autor, Grund, Ticket/RFC, Änderungsunterschriften.

4) Versionsstrategien

• MAJOR - inkompatible Schema-/Richtlinienänderungen.
• MINOR - neue Felder/Regeln, Abwärtskompatibilität.
• PATCH - Korrigiert Werte, ohne die Schemata zu ändern.
• Tag-Releases und Release Notes: Was wird geändert, wie rollt man zurück, Checkpoints.
• Pinning/Lock-Dateien: Wir erfassen Abhängigkeitsversionen (Module, Charts).
• Matrix-Versionen: Das App-Artefakt X ist kompatibel mit config Y (Matrix im Service-Verzeichnis).

5) Organisation des Repositorys

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

Zweig: trunk-based (main) + kurze Feature-Zweige. Merge - nur über PR mit obligatorischem CI.

6) Validierung und Prüfung

Schema: Jede Änderung wird einer Schemaüberprüfung unterzogen (erforderlich, enum, ranges).
Statische Linter: Format, Schlüssel, Takte, verbotene Felder.
Kompatibilitätstests: config + Service/Chart-Version steigt im Sandkasten.
Kontrollläufe: Dry-Run-Anwendungen, „what-if“ -Diff des Zielzustands.
Policies-as-Code: Zulassungsregeln (Rego/CEL) - wer kann was ändern.

7) Rollover und Rollback von Konfigurationen

Progressive Lieferung: Kanarienvogel 1%→5%→25% mit SLO-Gardrails.
Gate Deploy: Es gibt keine aktiven SEV-1, Alerts sind grün, Signaturen sind gültig, Rollback ist bereit.
Rollback: 'revert tag vX. Y.Z 'oder Umschalten auf den vorherigen Snapshot; Rollback-Befehle werden im Runbook dokumentiert.
Release Annotation: Die config-Version wird in Metriken/Protokollen veröffentlicht, um schnell mit Vorfällen zu korrelieren.

8) Dynamische und Remote-Konfiguration

Remote config/feature flags: Parameter ohne Neustarts ändern; alle Flaggen - auch unter GitOps.
Grenzen: Welche Parameter dynamisch geändert werden dürfen (Whitelist-Liste).
Cache und Konsistenz: TTL, Versionen, atomare Ersatzsätze (zweiphasige Veröffentlichung).
Sicheres Geländer: Grenzen und Bereiche für Laufzeitänderungen, Auto-Rollback beim Verlassen des SLO.

9) Geheimnisse und sensible Daten

Wir bewahren niemals Geheimnisse in Repos auf. In Konfigurationen - nur Links/Platzhalter.
Verschlüsselung von Config-Dateien bei Bedarf: Integration mit dem Secret/Key Manager.
Rotation und JIT: Zugriffe werden für die Dauer der Operationen ausgegeben; Die Spur des Handelns ist unveränderlich.
Feldmaskierung: Die Validierung verbietet das Eindringen von PII/Secrets in config.

10) Umweltmanagement

Base + overlays: Die Unterschiede zwischen dev/stage/prod sind minimal und transparent.
Förderung durch Artefakte: Der gleiche Snap-Shot, der die Bühne passiert hat, wird in prod gefördert.
Zeitfenster: Config-Änderungen treten zum Zeitpunkt des Dienstwechsels nicht auf; für risk-high - RFC und Wartungsfenster.

11) Erkennung und Beseitigung von Drift

Der Controller vergleicht den Zielzustand mit dem Ist-Zustand und meldet den Diff.
Drift-Warnungen: Seite nur bei kritischen Diskrepanzen; der Rest ist Ticket.
Auto-Remediation: Bei Auflösung - Rückkehr zum Zielzustand.
Manuelle Revisionsaudits: Alle „kubectl edit/ssh“ → Prozessvorfall und CAPA.

12) Konfigurationskatalog und Besitz

Service-Verzeichnis: Eigentümer, SLO, zugehörige Richtlinien, Schemata, Versionen, Kompatibilität.
RACI: Wer bietet, wer Revuit, wer genehmigt; CAB für hohes Risiko.
Transparenz: Jeder Eintrag hat einen Versionsverlauf und Links zu PR/Tickets/AAR.

13) Reifegradkennzahlen

Coverage:% der Dienste/Richtlinien unter GitOps (Ziel ≥ 95%).
Lead time config change: Median von PR bis prod.
Änderungsfehlerrate: Anteil der Config-Releases mit Rollback/Incident.
Driftrate: Anzahl der Unstimmigkeiten/Woche und Zeitpunkt der Beseitigung.
Rollback-Zeit: Median der Wiederherstellung zur vorherigen Version.
Audit completeness: Anteil der Änderungen mit voller evidence (Validatoren, Dry-Run, Bewertungen).

14) Checklisten

Vor dem Ändern der Konfiguration

• Es gibt ein Ticket/RFC und den Besitzer der Änderung.
• Validierung von Schemata und Lintern bestanden.
• Es gibt einen Rollback-Plan und Befehle im Runbook.
• Gate: Tests sind grün, Signaturen sind gültig, es gibt keine aktiven SEV-1.
• Für hohes Risiko - Ein Wartungsfenster ist zugewiesen.

Während des Rollens

• Kanarienvogel und SLO-Gardrails sind aktiv.
• Versionsanmerkungen werden veröffentlicht.
• Es gibt Echos zum Kanal; alert-Rauschen wird nach MW-Regeln unterdrückt.

Nach

• Beobachtungsfenster bestanden, SLO grün.
• Summen und Evidence (Vorher/Nachher-Grafiken, Dry-Run-Berichte) sind dem Ticket beigefügt.
• Diagramme/Dokumentation bei Bedarf aktualisiert.

15) Mini-Vorlagen

15. 1 Konfigurationsschema (YAML-Schema, Fragment)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15. 2 Basic config + overlay prod

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15. 3 Zulassungspolitik (Idee)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15. 4 Freigabekarte config

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) Anti-Muster

Bearbeitungen im Angebot an GitOps vorbei („schnell verdreht“).
Geheimnisse/PII im Konfig-Repository.
Keine Schemata und statische Inspektionen.
Starke Divergenz der Umgebung (base≠prod).
„Live“ Fitch Flaggen ohne Versionen und Geschichte.
Ignorieren Sie Drift und manuelle Bearbeitungen auf Servern.
Tags ohne Release Notes und Rollback-Plan.

17) Umsetzungsfahrplan (4-6 Wochen)

1. Ned. 1: Config Inventar; getrennte Verzeichnisse, Schemata für die Top-10-Dienste.
2. Ned. 2: Einbeziehung von Lintern/Validierung und Dry-Run in CI; Verbot von Merge ohne grüne Schecks.
3. Ned. 3: GitOps rollen + Kanarienvögel; Versionsanmerkungen in der Telemetrie.
4. Ned. 4: Eingabe von Toleranzrichtlinien (Policy-as-Code) und Rollback-Templates; Alertas auf Drift.
5. Ned. 5-6: 90% der Dienstleistungen abdecken; reduzieren Sie die Unterschiede env zu overlays; Fügen Sie Reifegradmetriken und eine wöchentliche Überprüfung der Config-Änderungen hinzu.

18) Ergebnis

Die Versionskontrolle von Konfigurationen ist ein System, nicht nur Git. Schemata und Validierung, GitOps und Zugriffsrichtlinien, Kanarienvögel und Rollbacks, Drifterkennung und vollständiges Audit machen config zu einem überschaubaren Artefakt. Das Ergebnis sind schnelle und sichere Änderungen, die Vorhersagbarkeit von SLO und das Vertrauen des Teams in jede Veröffentlichung.