Observability ohne Cloud-Abhängigkeit

  • OpenTelemetry als neutraler Standard hilft, Vendor-Lock-in zu vermeiden. Sammeln Sie Metriken, Logs, Traces lokal; exportieren Sie nur, was freigegeben ist.

  • Retention differenzieren: Produktionsmetriken kurz (z. B. 7–30 Tage), Auditartefakte lang (Jahre) auf günstigen Speichern.

  • Ohne gute Observability wird Governance zur PowerPoint-Übung. Ohne Governance wird Observability zur Datenhalde. Beide gehören zusammen: klare SLOs, Alarmierung mit Laufzeitbudgets, Ursachenanalyse, und Audit-Ansichten, die regulatorischen Fragen standhalten.

GitOps und Release-Governance

  • Der entscheidende Hebel für „cloud-native ohne Cloud“ ist deklaratives Management. Der Soll-Zustand liegt im Repo, nicht in Chat- oder Runbook-Texten.

  • Der GitOps-Controller läuft am Standort und zieht freigegebene Stände aus einer vertrauenswürdigen Quelle (lokaler Mirror oder signierte Wechselmedien). Kein externer Push in Produktionsnetze.

  • Air-Gap-Bootstrap: Ein dokumentierter, reproduzierbarer Prozess mit deterministischen Artefaktlisten. „Latest“-Tags sind verboten.

  • Progressive Delivery lokal: Blue/Green oder Canary auf dem Standort-Cluster, nicht als globale Schaltung. Failback ist Pflicht, und zwar ohne Internet.

Secrets und Härtung

  • Secret-Management on-prem mit Hardware-Root-of-Trust, wenn verfügbar. Schlüsselrotation muss offline-fähig sein.

  • Build-Pipeline signiert Artefakte; zur Laufzeit wird verifiziert. Laufzeit-Manipulationen müssen scheitern, nicht nur alarmieren.

  • Minimalimages, Kernel-Härtung, Syscalls einschränken, dateibasierte Integritätsprüfungen. Diese Maßnahmen sind langweilig – und wirken.

Upgrade-Strategie

  • Planen Sie Upgrades als Produktfunktion, nicht als Admin-Aufgabe. Versionsfenster, Kompatibilitätsmatrizen, Migrationspfade sind Teil der Architektur.

  • Downtime-Fenster sind real. Designen Sie für geordnete Quiesce-Phasen (Backlog leeren, Checkpoints schreiben) statt „wir hoffen, dass Rolling Update reicht“.

Desaster-Recovery und Standort-Klon

  • „Restore as code“: Die Fähigkeit, eine identische Plattform an einem neuen Standort aufzustellen, ist Ihr härtester Test.

  • Backups sind nur real, wenn Restores getestet werden. Definieren Sie RTO/RPO je Domäne und testen Sie Szenarien (konfigurierbarer Angriffsvektor, Hardwaredefekt, Bedienfehler).

AI-spezifische Besonderheiten in regulierten On-Prem-Umgebungen

Modell-Lebenszyklus und Datenherkunft

  • Jede Modellversion ist ein erstklassiges Artefakt mit: Trainingsdatenhashes, Feature-Pipelines, Hyperparametern, Evaluationsmetriken, Lesezeichen auf Datenfreigaben (DSGVO/Geheimhaltungsstufe).

  • Trainings- und Inferenzumgebungen müssen reproduzierbar sein. „Works on my GPU“ gilt nicht. Containerisierte Runtimes mit klaren Treiber- und CUDA/ROCm-Matrizen sind Pflicht, wo Beschleuniger im Spiel sind.

  • Datenherkunft und Freigaben: Wer hat wann wozu freigegeben? Ohne das wird jede Compliance-Prüfung schmerzhaft.

Edge-Inferenz und Latenz

  • Entkoppeln Sie Erfassung, Vorverarbeitung, Inferenz und Postprocessing über Ereignis- oder Puffergrenzen. So bleibt Inferenz stabil, auch wenn Sensorien kurzzeitig ausfallen oder Backends latent sind.

  • GPU-/NPU-Zuweisung: Planen Sie feste Kontingente für harte Latenzpfade. Mixed workloads (Batch-Training neben Echtzeit-Inferenz) sind selten eine gute Idee auf demselben Gerät.

LLM- und Agentensicherheit

  • LLMs in regulierten Umgebungen sind weniger eine „Modellwahl“-Frage, mehr eine „Kontrollfrage“: Eingabevalidierung (Prompt-Härtung), Ausgabeklassifizierung (PII-/IP-Leaks erkennen), Retrieval-Kapselung (RAG-Indizes unter strikter Datenklassifizierung), und vor allem Observability der Ketten/Agenten.

  • Agenten brauchen Governance: Welche Tools dürfen sie ausführen? Welche Datenräume lesen? Jede Aktion muss nachvollziehbar sein. Ohne diese Leitplanken wird ein Agent zum unkontrollierten Automatisierer.

Drei Referenzmuster im Detail

Pattern 1: Standort-lokale Plattform mit asynchroner Zentralanbindung

  • Aufbau: Pro Standort ein Cluster (oder schlanke Serviceplattform), lokaler Objekt- und Log-Store, GitOps-Controller, interner IdP. Ereignisbus vor Ort (z. B. für Telemetrie und Werkstattaufträge). Ein Replikator transportiert genehmigte Events/Artefakte asynchron in ein zentrales System (pull-basiert, aus dem Standort initiiert).

  • Warum es funktioniert: Lokale Autonomie ist maximal, zentrale Auswertungen sind zeitverzögert, aber verlässlich. Sicherheitsgrenzen sind klar (nur ausgehende Verbindungen).

  • Trade-offs: Zentrale Dashboards sehen nur, was repliziert wurde. Live-Steuerung ist nicht Ziel dieses Musters.

Pattern 2: Föderierte Governance, lokale Datenebene

  • Aufbau: Zentrales, souverän betriebenes Git und Artefaktkatalog mit signierten Releases. Mirroring an Standorte. Policies (z. B. wer was wohin deployen darf) werden zentral versioniert, lokal durchgesetzt. Modelle und Datenkataloge werden ebenfalls gespiegelt; Trainings finden zentral oder standortnah statt – je nach Datenklassifizierung.

  • Warum es funktioniert: Einheitliche Governance über viele Standorte, ohne zentrale Abhängigkeit zur Laufzeit. „Pull, verify, apply“ ist der Pfad jeder Änderung.

  • Trade-offs: Komplexer als rein lokale Lösungen. Erfordert disziplinierte Versionierung und klare Verantwortlichkeiten.

Pattern 3: Getrennte Steuer- und Datenebenen

  • Aufbau: Ein zentrales Steuerungssystem (Policy-Engine, Release-Orchestrierung, globale Flottenansicht) im eigenen Rechenzentrum, Datenverarbeitung verbleibt am Standort. Bi-direktionale, abgesicherte Managementkanäle sind erlaubt. Datenflüsse bleiben lokal oder sind explizit freigegeben.

  • Warum es funktioniert: Global koordinierte Rollouts, gerichtete Steuerung, einheitliche Audits. Gut für Flotten, die aktiv bespielt werden (z. B. Modell-Updates auf Zugflotten).

  • Trade-offs: Abhängigkeit vom Managementkanal – muss hochverfügbar und sicher sein. Fallback-Modi definieren, falls die Steuerung ausfällt.

Konkrete Entscheidungshilfen statt Dogmen

Fragen, die in Architektur-Reviews den Unterschied machen:

  • Was passiert, wenn der Standort 30 Tage offline ist? Welche Funktionen müssen garantiert laufen, welche dürfen degradieren?

  • Welches Subsystem darf auf „latest“ laufen? Wenn die Antwort nicht „keines“ ist, warum nicht?

  • Können wir die Plattform an einem leeren Standort in 24–48 Stunden deterministisch hochziehen? Welche Schritte sind manuell, warum?

  • Wie groß ist das Blast-Radius eines kompromittierten Service? Kann er Daten exfiltrieren oder die Produktion stoppen?

  • Welche Metrik sagt uns, dass unser Observability-Stack nützlich ist, nicht nur vorhanden? (Beispiel: MTTR-Reduktion durch Traces gegenüber Logs-only)

  • Welche Artefakte müssen zehn Jahre aufbewahrt werden? Wie verifizieren wir deren Integrität ohne externen Dienst?

Ein Wort zum Größenmaßstab: Monolith vs. Microservices vs. „verteilter Monolith“