Zeiss verknüpft DORA-Metriken und FinOps über Backstage und Argo CD

Cloud-Plattformen produzieren Telemetrie, Logs, Metriken und Kostendaten im Überfluss. Ohne klare Zuordnung zu Teams, Systemen, Umgebungen und Kostenstellen lassen sich daraus aber weder verlässliche DORA-Metriken (DevOps Research and Assessment) für die Bewertung der Software-Delivery-Performance noch belastbare FinOps-Analysen ableiten. Die entscheidende Herausforderung liegt darin, die richtigen Attribute zuzuweisen, wie Alexander Troppmann in seinem Vortrag „Meta Data Matters: Wie ZEISS Backstage und Argo CD für DORA-Metriken und Cost-Clustering einsetzt“ im Rahmen der Online-Konferenz Mastering GitOps am 25. Juni 2026 dargelegt hat.

Die Kernbotschaft: Wer Deployment-Performance und Kostentransparenz ernst nimmt, braucht zuerst eine saubere Zuweisung von Attributen – also eine eindeutige Zuordnung von Deployments, Services und Kosten zu Verantwortlichen und organisatorischen Einheiten. Bei Zeiss existierten dafür zunächst drei getrennte Welten: das Developer-Portal Backstage als Servicekatalog mit Ownership-Informationen, die GitOps-Repositories mit dem gewünschten Deployment-Zustand sowie Kubernetes und Argo CD mit dem tatsächlichen Runtime-Zustand. Werden Metadaten nicht durchgängig über diese Ebenen propagiert, entsteht Drift. Die Folge: DORA-Metriken verlieren ihre Aussagekraft, und Kostenreports lassen sich nicht mehr eindeutig den einzelnen Tenants, Teams oder Systemen zuordnen.

Zeiss nutzt Backstage bewusst als Single Source of Truth für Attribution. Dort gepflegte Dimensionen wie Owner beziehungsweise Team, System und Domain, einzelne Komponenten, die Umgebung (DEV – Development, STG – Staging, PRD – Production) sowie Cost User (Kostenverursacher) und Kostenstelle bilden das Rückgrat der gesamten Auswertung. Perspektivisch sollen SRE-Owner (Site Reliability Engineering), eine Kritikalitätsangabe und Skalierungsprofile hinzukommen. Nicht alle diese Metadaten wiegen für beide Auswertungsbereiche gleich schwer: Team- und Komponenten-Zuordnung sowie die Umgebung sind primär für DORA relevant, weil ohne sie kein Vergleich zwischen Teams und kein sauberes Trennen von Produktions- und Test-Failures gelingt. Cost User, Kostenstelle und Tenant hingegen sind vor allem für FinOps kritisch – sie bilden die Grundlage für interne Verrechnung, die Budgetierung und das Kostenclustering.

Um die Brücke zwischen diesen Welten zu schlagen, hat Zeiss auch individuelles Tooling entwickelt. Der Argo CD Annotator läuft als Kubernetes-CronJob, klont die GitOps-Repositories, erkennt darin die Argo-CD-Application-Manifeste, holt die Metadaten aus Backstage und schreibt sie als Annotationen zurück. Die Injektion erfolgt über Kustomize Components und JSON-Patches, sodass bestehende YAML-Dateien nicht direkt angefasst werden. So bleibt die fachliche GitOps-Konfiguration strikt von der Plattform-Attribution getrennt, und die Git-Historie wird nicht durch manuelle Annotation-Commits unübersichtlich.

Wann ein Deployment wirklich zählt

Ein weiteres Werkzeug, der DORA Metrics Collector for Argo CD, läuft als Go-Microservice in der Cloud-Umgebung. Er beobachtet die Application-CRDs (Custom Resource Definitions) von Argo CD über Kubernetes Informer. Der Collector klassifiziert zudem Deployments, Failures und Recoveries deterministisch, exportiert Prometheus-Metriken und liefert REST-Reports für Backstage, Grafana und die Management-Dashboards. Der Umfang: rund 15.000 Zeilen Produktionscode, fast ebenso viel Testcode, über 600 Testfunktionen, 13 Architecture Decision Records (ADRs) und neun Spezifikationen. Die Runtime bleibt vollständig deterministisch und ohne KI-Abhängigkeiten.

Besonders präzise fällt die Definition eines erfolgreichen Deployments aus. Bei Zeiss zählt ein Rollout erst dann als erfolgreich, wenn eine neue Revision gleichzeitig die Zustände „succeeded“, „synced“ und „healthy“ erreicht. Das ist deutlich robuster als ein reines Sync-Event: Argo CD kann den Sync-Status bereits auf synchron setzen, während die Anwendung im Cluster noch gar nicht „gesund“ läuft – etwa weil Pods erst nach dem Apply in einen CrashLoopBackOff geraten. Erst die dreifache Bedingung stellt sicher, dass die Operation abgeschlossen ist, der Cluster-Zustand dem Git entspricht und alle relevanten Objekte als „gesund“ eingestuft sind. Fehlversuche, Rollbacks oder halb fertige Deployments landen dadurch nicht fälschlich in der Deployment-Pipeline.

Ähnlich sorgfältig sind die übrigen DORA-Metriken definiert. Ein Failure gilt erst als bestätigt, wenn eine Applikation mindestens 60 Sekunden (individuell konfigurierbar) in einem Fehlerzustand wie „degraded“ oder „unknown“ verharrt. Kurze transiente Flaps, die sich durch Self-Healing sofort lösen, werden bewusst verworfen, damit die Change Failure Rate nur substanzielle Störungen misst. Die Mean Time to Recovery misst die Dauer vom bestätigten Failure bis zur Rückkehr in den Zustand „healthy“ und wird als Histogramm mit Perzentilen wie p50, p75 und p95 ausgewertet – ein Durchschnitt würde die aussagekräftigen Long-Tail-Probleme verschleiern. Die komplexeste Metrik ist die Lead Time for Changes, die das Deployment mit dem Source-Commit verknüpft. Sie lässt sich nur mit funktionierenden CI-Tag-Konventionen und gepflegten Backstage-Daten sinnvoll nutzen.

Dieselben Metadaten für die Kostenanalyse

Die Metadaten, die Zeiss für DORA nutzt – unter anderem Tenant, Owner, Team, System und Kostenstelle – fließen zugleich in die FinOps-Analyse ein. Dazu annotiert Zeiss die Kubernetes-Namespaces, sodass sich etwa Azure-Kosten im Portal auf Tenant-Ebene auswerten lassen. GitOps propagiert diese Informationen kontrolliert von Backstage über die Repositories und Argo CD bis in die Namespaces und schließlich ins Cloud-Kostenreporting. Weil dieser Weg deterministisch ist und Änderungen an Tenants oder Kostenstellen versioniert erfolgen, sinkt das Risiko, dass Drift zwischen Git, Backstage und Runtime die Zahlen unbrauchbar macht. Ergänzend hilft die GitOps-Strictness: Out-of-Band-Änderungen direkt im Cluster werden eingeschränkt, und Argo CD erkennt und korrigiert Abweichungen.

Bei der Entwicklung setzt Zeiss KI-Werkzeuge wie Claude Code und GitHub Copilot ein – allerdings ausschließlich als Beschleuniger für Spezifikationen, Refactoring und Coding. Die Runtime bleibt frei von KI-Abhängigkeiten. Zeiss arbeitet Spec-driven, mit reviewpflichtigem Code, dokumentierten Architekturentscheidungen und gelebten Spezifikationen; auf freies Vibe Coding verzichtet das Team bewusst. Dieser Ansatz harmoniert mit den Dokumentationspflichten, die etwa der EU AI Act für KI-gestützte Entwicklungsprozesse vorsieht.

Als zentrale Lehre betont Troppmann, dass Datenqualität eine Governance-Aufgabe bleibt. Ohne klare Verantwortlichkeiten für Backstage-Einträge kippt die gesamte Auswertbarkeit, denn Tooling allein reicht nicht. YAML-Kommentar-Direktiven seien zwar einfach einzuführen, aber anfällig gegenüber Formatierern und Lintern – deshalb bevorzugt Zeiss den Weg über Kustomize und JSON-Patch. Automatisierte GitOps-Pipelines benötigen zudem starke Credentials, deren Rechte möglichst streng eingeschränkt werden sollten. Troppmanns Fazit lässt sich sinngemäß so zusammenfassen: Wer DORA und FinOps ernst nimmt, muss nicht nur messen, sondern zuerst wissen, wem die Dinge gehören. GitOps liefert den Zustand, Backstage den Kontext, und erst beides zusammen verschafft belastbare Transparenz.

Alexander Troppmann ist seit fast 30 Jahren in der IT und ein erfahrener Cloud-Architekt mit Hintergrund im Full-Stack Programming. Er verfügt über mehrere Jahre Erfahrung mit der Kubernetes-Plattform und ist Spezialist für das API-Management-System Tyk. Mit großer Leidenschaft beschäftigt er sich außerdem mit den Themen Mentorship und Teambuilding.

(map)