Konfigurationsdienst im Durchgang: unveränderliche Versionen, gestufter Rollout und Last-Known-Good

Ziel

Laufzeitkonfiguration (Limits, Endpunkte, Abstimmungswerte) an viele Instanzen verteilen, ohne neu auszuliefern, Änderungen gestuft mit automatischem Abbruch ausrollen und garantieren, dass jede Instanz stets über eine brauchbare Konfiguration verfügt.

Voraussetzungen

Eine Grenze zwischen Konfiguration und Secrets (Secrets bleiben im Secrets-Manager), ein Schema je Namespace und ein Gesundheitssignal je Instanz, das der Rollout lesen kann.

Schritte

1. Randbedingungen: Versionen sind unveränderlich und zuordenbar; Instanzen müssen ohne den Dienst starten können; eine fehlerhafte Änderung stoppt, bevor sie alle erreicht; ein Rollback ist das Verschieben eines Zeigers, keine neue Bearbeitung.
2. Komponenten: ein Versionsspeicher; ein Validator, der Kandidaten gegen das Namespace-Schema prüft; ein Rollout-Controller, der Kohorten Versionen zuweist; eine Verteil-API, die Clients mit ihrer Version pollen oder beobachten (die etcd-Dokumentation beschreibt beispielsweise eine Watch-API, die Schlüsseländerungen fortlaufend ab einer gegebenen Revision streamt); eine Client-Bibliothek, die eine Last-Known-Good-Datei führt.
3. Datenmodell: config_version(namespace, version, content, checksum, author, created_at); rollout(namespace, version, stages[], current_stage, state: running|held|halted|complete); stage(cohort_selector, hold_duration, halt_condition); client_state(instance, namespace, version_applied, reported_at, healthy). Kohorten ergeben sich aus einem stabilen Hash der Instanz-ID, sodass die Zugehörigkeit mitten im Rollout bestehen bleibt.
4. Rollout: erst wenige Instanzen, dann ein Anteil, dann alle; der Controller rückt nur vor, solange die Abbruchbedingung (Fehlerrate oder Gesundheit der Kohorte gegenüber dem Rest) über die Haltezeit hinweg unauffällig bleibt, sonst bricht er ab und setzt die Kohorte auf die vorherige Version zurück.
5. Client-Verhalten: beim Start die lokale Datei laden, dann abrufen; eine neue Version atomar anwenden, indem ein Zeiger ausgetauscht wird; auf die Platte schreiben; version_applied und Gesundheit melden; die alte Version behalten, wenn die neue an der lokalen Validierung scheitert.
6. Fehlerarten: eine Änderung, die schemakonform, aber in der Wirkung falsch ist (der gestufte Abbruch ist die Verteidigung, daher muss sein Signal eine echte Gesundheitsmetrik sein); Instanzen, die sich für Minuten unterschiedlich verhalten (dokumentieren; voneinander abhängige Werte in einem Namespace halten); viele Clients, die einen grossen Namespace pollen (revisions- oder ETag-basierte Abrufe, gestreute Intervalle); Secrets, die in die Konfiguration einsickern (der Validator weist bekannte Muster zurück); dringende Änderungen, die den Rollout umgehen (ein protokollierter Notfallpfad, keine Hintertür).
7. Messen: Ausbreitungszeit bis zur vollständigen Abdeckung, Anteil der Instanzen auf der Zielversion, Abbrüche und ihre Ursachen, Validierungsabweisungen, Clients auf Last-Known-Good.
8. Nicht zuerst: ein Web-Editor, Auswertung je Anfrage (das ist ein Feature-Flag-Dienst), Abhängigkeiten zwischen Schlüsseln, umgebungsübergreifende Promotion-Workflows.

Erwartetes Ergebnis

Eine Änderung ist ein versioniertes Objekt, das zuerst eine kleine Kohorte erreicht, und eine Instanz, die neu startet, während der Dienst nicht erreichbar ist, startet mit der zuletzt angewendeten Version.

Grenzen und Prüfbasis

Vorgeschlagener Entwurf, keine Messungen. Die Abbruchbedingung braucht genug Verkehr in der ersten Kohorte, um aussagekräftig zu sein; bei einem Dienst mit wenig Verkehr kann sie halten, ohne etwas zu lernen.