TL;DR

DORA-Metriken (Deployment Frequency, Lead Time, MTTR, Change Failure Rate) sind der Standard, um Developer Experience auf Kubernetes zu messen. Kombiniert mit Zufriedenheitsumfragen und Time-to-First-Deploy ergibt sich ein vollständiges Bild. Prometheus liefert die Daten, Grafana macht sie sichtbar.

Developer Experience auf Kubernetes messen

Wer eine interne Kubernetes-Plattform betreibt, braucht Zahlen. Ohne Metriken weißt du nicht, ob deine Plattform Entwicklern hilft oder sie ausbremst. DORA-Metriken haben sich als Industriestandard etabliert — hier zeige ich, wie du sie auf Kubernetes erhebst.

Die vier DORA-Metriken

Das DORA-Team (DevOps Research and Assessment) definiert vier Schlüsselmetriken:

# DORA Metrics Overview
deployment_frequency:    # Wie oft deployt ein Team?
  elite: "Mehrmals täglich"
  high: "Zwischen einmal pro Tag und einmal pro Woche"
  medium: "Zwischen einmal pro Woche und einmal pro Monat"
  low: "Weniger als einmal pro Monat"

lead_time_for_changes:   # Commit bis Production
  elite: "Weniger als eine Stunde"
  high: "Zwischen einem Tag und einer Woche"

change_failure_rate:     # Prozent fehlgeschlagener Deployments
  elite: "0-15%"
  high: "16-30%"

mean_time_to_restore:    # Ausfallzeit bei Incidents
  elite: "Weniger als eine Stunde"
  high: "Weniger als ein Tag"

Deployment Frequency mit Prometheus messen

Die Deployment Frequency ist die einfachste DORA-Metrik. Jedes kubectl apply oder Helm-Release erzeugt Events, die sich zählen lassen.

Kube-state-metrics liefert bereits die nötigen Daten:

# Deployments pro Tag pro Namespace (letzte 7 Tage)
sum by (namespace) (
  increase(
    kube_deployment_status_observed_generation[7d]
  )
) / 7

# Deployment-Frequenz pro Team (Label-basiert)
sum by (label_team) (
  increase(
    kube_deployment_status_observed_generation{
      namespace=~"team-.*"
    }[30d]
  )
) / 30

Für genauere Werte tracke Deployments über eine Custom Metric. Ein einfacher Admission Webhook oder ein Controller, der Deployment-Events zählt, reicht:

# deploy_tracker.py - Minimaler Deployment-Counter
from prometheus_client import Counter, start_http_server
from kubernetes import client, config, watch

deploy_counter = Counter(
    'platform_deployments_total',
    'Total deployments tracked',
    ['namespace', 'team', 'app']
)

config.load_incluster_config()
v1 = client.AppsV1Api()
w = watch.Watch()

start_http_server(8080)

for event in w.stream(v1.list_deployment_for_all_namespaces):
    if event['type'] == 'MODIFIED':
        dep = event['object']
        labels = dep.metadata.labels or {}
        deploy_counter.labels(
            namespace=dep.metadata.namespace,
            team=labels.get('team', 'unknown'),
            app=labels.get('app', dep.metadata.name)
        ).inc()

Lead Time for Changes

Lead Time misst die Zeit von Commit bis Production. Dafür brauchst du zwei Datenpunkte: den Commit-Timestamp und den Zeitpunkt des erfolgreichen Rollouts.

# Durchschnittliche Lead Time (wenn per Annotation getrackt)
avg by (namespace) (
  kube_deployment_annotation_deploy_timestamp
  - kube_deployment_annotation_commit_timestamp
)

Praktischer ist es, Lead Time in der CI/CD-Pipeline zu messen. ArgoCD und Flux exportieren diese Daten bereits. Bei ArgoCD findest du sie unter:

# ArgoCD Application Sync-Dauer abfragen
kubectl get applications -n argocd -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.operationState.finishedAt}{"\n"}{end}'

Change Failure Rate

Die Change Failure Rate zeigt, wie viele Deployments Rollbacks oder Hotfixes nach sich ziehen. Kubernetes macht das messbar über ReplicaSet-Historien:

# Rollbacks pro Namespace (letzte 30 Tage)
sum by (namespace) (
  increase(
    kube_deployment_status_observed_generation[30d]
  )
  -
  increase(
    kube_deployment_spec_replicas[30d]
  )
)

Eine robustere Methode: Tracke fehlgeschlagene Rollouts über den Deployment-Status.

# Deployments mit Condition "Progressing=False"
count by (namespace) (
  kube_deployment_status_condition{
    condition="Progressing",
    status="false"
  } == 1
)

Mean Time to Restore (MTTR)

MTTR misst, wie schnell dein Team Ausfälle behebt. Alertmanager liefert die Rohdaten:

# Durchschnittliche Alert-Dauer (Proxy für MTTR)
avg(
  alertmanager_alert_duration_seconds{
    alertname=~"KubePod.*|KubeDeployment.*"
  }
)

Time-to-First-Deploy messen

Neben DORA ist Time-to-First-Deploy die wichtigste Platform-Engineering-Metrik. Sie misst, wie lange ein neuer Entwickler vom Onboarding bis zum ersten erfolgreichen Deployment braucht.

Developer Satisfaction Survey

Nicht alles lässt sich automatisch messen. Quartalsweise Surveys ergänzen die harten Metriken:

• Net Promoter Score (NPS): "Würdest du unsere Plattform einem Kollegen empfehlen?"
• Task Completion Time: "Wie lange brauchst du für ein Standard-Deployment?"
• Pain Points: "Was ist dein größtes Hindernis bei der täglichen Arbeit?"
• Toil-Anteil: "Wie viel Prozent deiner Zeit geht für manuelle, repetitive Aufgaben drauf?"

Tracke die Ergebnisse über Zeit. Ein NPS unter 30 signalisiert ernsthaften Handlungsbedarf.

Grafana Dashboard aufsetzen

Ein zentrales Dashboard macht die Metriken für alle Teams sichtbar:

{
  "dashboard": {
    "title": "Platform Engineering - DORA Metrics",
    "panels": [
      {
        "title": "Deployment Frequency (7d avg)",
        "type": "stat",
        "targets": [{
          "expr": "sum(increase(platform_deployments_total[7d])) / 7"
        }]
      },
      {
        "title": "Change Failure Rate",
        "type": "gauge",
        "targets": [{
          "expr": "sum(rate(platform_deployments_failed_total[30d])) / sum(rate(platform_deployments_total[30d])) * 100"
        }],
        "thresholds": [15, 30]
      },
      {
        "title": "MTTR (Hours)",
        "type": "stat",
        "targets": [{
          "expr": "avg(alertmanager_alert_duration_seconds) / 3600"
        }]
      }
    ]
  }
}

Metriken in Plattform-Verbesserungen umsetzen

Zahlen allein ändern nichts. Wichtig ist der Feedback-Loop:

1. Monatliches Review: Geh die Metriken mit den Plattform-Nutzern durch
2. Priorisierung: Metriken mit dem größten Gap zu Elite priorisieren
3. Experimente: Gezielte Verbesserungen mit vorher-nachher Vergleich
4. Transparenz: Dashboard für alle zugänglich machen, nicht nur fürs Management

Wenn deine Deployment Frequency niedrig ist, liegt es oft nicht an der Technik, sondern an zu komplexen Freigabeprozessen. Wenn die Change Failure Rate hoch ist, fehlen Tests oder Canary-Deployments.

FAQ

Brauche ich alle vier DORA-Metriken gleichzeitig?

Nein. Starte mit Deployment Frequency und Change Failure Rate — die sind am einfachsten zu erheben. Lead Time und MTTR erfordern mehr Instrumentierung und können im zweiten Schritt folgen.

Wie oft sollte ich Developer Satisfaction messen?

Quartalsweise ist ein guter Rhythmus. Häufiger führt zu Survey-Fatigue, seltener lässt Probleme zu lange unentdeckt. Halte Surveys kurz — maximal 10 Fragen, 5 Minuten Bearbeitungszeit.

Sind DORA-Metriken auch für kleine Teams relevant?

Ja. Auch bei drei Entwicklern zeigen DORA-Metriken, ob die Plattform gut funktioniert. Die absoluten Zahlen sind weniger wichtig als der Trend über Zeit.

Wie vermeide ich, dass Metriken zu Druck auf Entwickler führen?

Miss Teams, nicht Einzelpersonen. Verwende Metriken als Diagnose-Tool für die Plattform, nicht als Leistungsbewertung. Wenn die Deployment Frequency eines Teams sinkt, frage nach Hindernissen statt nach Produktivität.