24/7 Kubernetes-Betrieb: Warum Ihr Admin nicht immer erreichbar sein kann

TL;DR

• 24/7 Kubernetes-Betrieb mit 1-2 Personen ist mathematisch unmoeglich -- selbst mit Rufbereitschaft erreichen Sie maximal 95% Abdeckung.
• On-Call-Burnout ist real: Nach 6 Monaten Dauer-Rufbereitschaft suchen sich gute Engineers einen neuen Job.
• Fuer 99,9% Availability (8,7 Stunden Downtime/Jahr) brauchen Sie mindestens 4-5 Personen in Rotation.
• Ein Managed Service mit Team-Rotation kostet weniger als eine zweite DevOps-Stelle und liefert echte 24/7-Abdeckung.
• Die Frage ist nicht "ob" ein Ausfall nachts passiert, sondern "wann" -- und ob dann jemand ans Telefon geht.

Das Szenario, das jeder IT-Leiter kennt

Freitagabend, 22:30 Uhr. Ihr Kubernetes-Cluster hat ein Problem. Die Monitoring-Alerts feuern, Kunden sehen Fehlerseiten, der Umsatz laeuft gegen Null. Ihr Admin? Im Urlaub. Sein Vertreter? Hat das Firmenhandy auf lautlos gestellt, weil er seit drei Wochen jede zweite Nacht rausgeklingelt wird.

Das ist kein hypothetisches Szenario. Das ist der Alltag im Kubernetes 24/7 Betrieb im Mittelstand. Und es ist kein Versagen des Admins -- es ist ein systemisches Problem.

Die Mathematik der Verfuegbarkeit

Rechnen wir durch, was "24/7" tatsaechlich bedeutet:

Ein Jahr hat:           8.760 Stunden
Ein Arbeitnehmer hat:   1.720 Netto-Arbeitsstunden
                        (abzgl. Urlaub, Feiertage, Krankheit, Schulungen)

Abdeckung durch 1 Person (nur Arbeitszeit):
1.720 / 8.760 = 19,6% der Gesamtzeit

Mit Rufbereitschaft (Mo-Fr 18-08 + Wochenende):
Erreichbar: ~6.000 Stunden/Jahr
Effektive Abdeckung: ~68% (Schlaf, Ablenkung, Reaktionszeit)

Realistisch mit 1 Admin:
├── Buerozeit (Mo-Fr, 08-18):       2.600 h  = abgedeckt
├── Rufbereitschaft (wenn wach):     ~3.000 h = bedingt abgedeckt
├── Urlaub + Krankheit + Feiertage:  ~1.160 h = NICHT abgedeckt
└── Schlaf + Erholung:               ~2.000 h = NICHT abgedeckt
──────────────────────────────────────────────────────────────
Effektive 24/7-Abdeckung:           ~64%

64% sind keine 24/7-Abdeckung. Das sind 3.154 Stunden im Jahr, in denen niemand reagieren kann. Bei einer zweiten Person verbessert sich die Lage -- aber nicht genug.

Was SLAs wirklich bedeuten

Viele Mittelstaendler haben SLAs mit ihren Kunden oder internen Fachabteilungen vereinbart, ohne die Konsequenzen durchzurechnen:

Die meisten Kundenvertraege im Mittelstand verlangen mindestens 99,5%. Schauen Sie in Ihre eigenen Vertraege: Wenn dort "Verfuegbarkeit 99,9%" steht, haben Sie maximal 43 Minuten pro Monat fuer Ausfaelle. Das schliesst geplante Wartung ein.

Mit zwei Admins und Rufbereitschaft schaffen Sie im besten Fall 99,0-99,5%. Jede Nacht ohne Abdeckung, jeder Urlaub, jede Krankheitswoche drueckt die Zahl nach unten.

On-Call-Burnout: Das verschwiegene Problem

Rufbereitschaft klingt in der Theorie machbar. In der Praxis zerstoert sie Teams.

Was Rufbereitschaft wirklich bedeutet

Typische On-Call-Woche fuer einen K8s-Admin:

Montag:     08:00-18:00 Buero + 18:00-08:00 On-Call
Dienstag:   08:00-18:00 Buero + 18:00-08:00 On-Call
Mittwoch:   08:00-18:00 Buero + 18:00-08:00 On-Call
Donnerstag: 08:00-18:00 Buero + 18:00-08:00 On-Call
Freitag:    08:00-18:00 Buero + 18:00-00:00 On-Call
Samstag:    00:00-24:00 On-Call (ganzer Tag)
Sonntag:    00:00-24:00 On-Call (ganzer Tag)
───────────────────────────────────────────────────
Theoretische Erreichbarkeit: 168 von 168 Stunden
Tatsaechliche Lebensqualitaet: nahe Null

Wenn Sie nur einen Admin haben, sieht jede Woche so aus. Bei zwei Admins wechseln sie sich ab -- aber jeder Zweite ist trotzdem eine On-Call-Woche.

Die Folgen sind messbar

Die Forschung zu On-Call-Belastung ist eindeutig:

• Schlafqualitaet: On-Call reduziert die Schlafeffizienz um 20-30%, selbst wenn kein Alert kommt (Quelle: Journal of Occupational Health Psychology).
• Kuendigungsrate: DevOps-Engineers mit Dauer-On-Call haben eine 2,5x hoehere Fluktuation als solche ohne. Im aktuellen Arbeitsmarkt fuer Kubernetes-Spezialisten bedeutet das: Ihr Admin geht, wenn er eine Stelle ohne Rufbereitschaft findet.
• Fehlerrate: Muede Engineers machen mehr Fehler. Ein falscher kubectl delete um 3 Uhr morgens richtet mehr Schaden an als der urspruengliche Alert.
• Recruiting-Kosten: Eine DevOps-Neubesetzung kostet 15.000-25.000 EUR und dauert 3-6 Monate. Waehrend dieser Zeit haben Sie null Redundanz.

Mehr zu den versteckten Personalkosten lesen Sie im Managed Service vs. Inhouse Vergleich.

Was nachts tatsaechlich passiert

Kubernetes-Cluster fallen nicht nur waehrend der Buerozeiten aus. Die haeufigsten Nacht-Incidents:

Kubernetes hat zwar Self-Healing-Mechanismen (Pod-Restart, Node-Drain). Aber diese greifen nicht bei allen Problemen. Wenn etcd voll laeuft, ein Node dauerhaft ausfaellt oder ein Certificate abgelaufen ist, braucht es menschliches Eingreifen.

Fuer eine systematische Herangehensweise an Cluster-Ausfaelle empfehlen wir den Backup und Disaster Recovery Guide.

Die drei Optionen -- ehrlich bewertet

Option 1: Mehr Personal einstellen

Die offensichtliche Loesung -- und die teuerste.

Kosten fuer echte 24/7-Abdeckung (internes Team):

4 Senior DevOps Engineers (Rotation):
├── 4x Gehalt + AG-Anteil:           340.000 EUR/Jahr
├── 4x On-Call-Zulagen:               24.000 EUR/Jahr
├── Schulungen/Zertifizierungen:       16.000 EUR/Jahr
├── Tools und Lizenzen:                20.000 EUR/Jahr
└── Management-Overhead:               30.000 EUR/Jahr
────────────────────────────────────────────────────────
Jahreskosten:                         430.000 EUR/Jahr
Monatskosten:                          ~35.800 EUR/Monat

Fuer einen Mittelstaendler mit 300-1.000 Mitarbeitern ist ein 4-koepfiges DevOps-Team selten wirtschaftlich zu rechtfertigen -- vor allem wenn Kubernetes nicht das Kerngeschaeft ist.

Ausserdem: Vier Kubernetes-Spezialisten im deutschen Arbeitsmarkt zu finden und zu halten, ist aktuell eine Herausforderung fuer sich.

Option 2: Automatisierung maximieren

Mehr Automation reduziert die Haeufigkeit menschlicher Eingriffe, aber eliminiert sie nicht.

Was Automatisierung loesen kann:

• Pod-Restarts bei CrashLoopBackoff (Kubernetes nativ)
• Node-Drain und -Replacement (Cluster Autoscaler, Karpenter)
• Certificate Renewal (cert-manager)
• Alerting und Eskalation (Alertmanager, PagerDuty)
• Automatische Skalierung (HPA, VPA)

Was Automatisierung nicht loesen kann:

• Architekturentscheidungen unter Druck
• Debugging von unbekannten Fehlern
• Kommunikation mit Cloud-Provider-Support
• Post-Mortem und nachhaltige Fixes
• Entscheidung: Rollback oder Weiterfahren?

Automatisierung ist die notwendige Basis -- aber kein Ersatz fuer menschliche Bereitschaft. Mehr dazu in unserem Autoscaling Guide.

Option 3: Managed Service mit Team-Rotation

Die wirtschaftlichste Loesung fuer die meisten Mittelstaendler: Den Kubernetes 24/7 Betrieb an ein spezialisiertes Team auslagern, das bereits eine Rotation hat.

Der Managed Service funktioniert, weil der Anbieter die Kosten auf mehrere Kunden verteilt. Ihr Cluster braucht vielleicht 2-3 Stunden Aufmerksamkeit pro Woche im Normalbetrieb -- aber 24/7 Erreichbarkeit fuer den Ernstfall. Genau das liefert ein Team mit 5-8 Engineers in Rotation.

Die On-Call-Checkliste: Was Sie jetzt pruefen sollten

Unabhaengig von Ihrer Entscheidung -- pruefen Sie diese Punkte fuer Ihren aktuellen Betrieb:

Monitoring und Alerting:

• Sind Alerts konfiguriert fuer alle kritischen Komponenten (etcd, API-Server, Ingress)?
• Gibt es eine Eskalationskette (L1 -> L2 -> L3)?
• Werden Alerts dedupliziert, damit On-Call nicht 50 Messages gleichzeitig bekommt?

Runbooks:

• Existieren Runbooks fuer die 10 haeufigsten Incidents?
• Sind sie aktuell und von jemandem getestet, der sie nicht geschrieben hat?
• Koennen sie auch um 3 Uhr morgens von einem mueden Engineer befolgt werden?

Backup und Recovery:

• Werden Backups taeglich getestet (nicht nur erstellt)?
• Wie lange dauert ein Full-Cluster-Recovery?
• Ist das dokumentiert und geuebt?

Eine umfassende Monitoring-Strategie beschreiben wir im Observability Stack Guide.

Praxis: Automatisierung als erste Verteidigungslinie

Bevor Sie ueber mehr Personal oder einen Managed Service nachdenken, sollten Sie die Automatisierung maximieren. Das reduziert die Anzahl der Alerts, die nachts bei einem Menschen landen, auf die wirklich kritischen.

Alertmanager richtig konfigurieren

Das haeufigste Problem: Zu viele Alerts, zu wenig Signal. Ein Admin, der pro Nacht 15 Alerts bekommt, stumpft ab. Konfigurieren Sie Alertmanager so, dass nur wirklich handlungsrelevante Alerts die On-Call-Person erreichen:

# alertmanager-config.yaml
# Nur kritische Alerts nachts eskalieren
apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager-config
  namespace: monitoring
data:
  alertmanager.yml: |
    global:
      resolve_timeout: 5m

    route:
      receiver: 'default'
      group_by: ['alertname', 'namespace']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      routes:
        # Kritische Alerts: sofort eskalieren, Tag und Nacht
        - match:
            severity: critical
          receiver: 'oncall-pagerduty'
          group_wait: 10s
          repeat_interval: 1h
        # Warnungen: nur waehrend Buerozeiten
        - match:
            severity: warning
          receiver: 'slack-team'
          active_time_intervals:
            - business-hours
        # Info: nur ins Dashboard, keine Notification
        - match:
            severity: info
          receiver: 'default'

    time_intervals:
      - name: business-hours
        time_intervals:
          - weekdays: ['monday:friday']
            times:
              - start_time: '08:00'
                end_time: '18:00'

    receivers:
      - name: 'default'
        # Nur Dashboard, keine aktive Benachrichtigung
      - name: 'oncall-pagerduty'
        pagerduty_configs:
          - service_key: '<your-integration-key>'
            severity: critical
      - name: 'slack-team'
        slack_configs:
          - channel: '#k8s-alerts'
            send_resolved: true

Das Ziel: Maximal 2-3 kritische Alerts pro Woche sollten die On-Call-Person nachts erreichen. Alles andere ist entweder automatisiert loesbar oder kann bis zum naechsten Morgen warten.

Self-Healing automatisieren

Kubernetes hat eingebaute Self-Healing-Mechanismen, aber die muessen aktiv konfiguriert werden:

Fuer jeden dieser Faelle sollte ein Runbook existieren, das beschreibt, was passiert wenn die Automatisierung versagt und menschliches Eingreifen noetig wird. Mehr zum Thema Troubleshooting bietet unser CrashLoopBackoff Guide.

Das hybride Modell: Interner Engineer + externer 24/7-Service

Fuer die meisten Mittelstaendler ist das hybride Modell der Sweet Spot. Es kombiniert internes Wissen mit externer Abdeckung:

Hybrides Betriebsmodell:

Interner Engineer (1 Person):
├── Architekturentscheidungen
├── Applikations-nahe Themen
├── Kommunikation mit Entwickler-Teams
├── Strategische Planung
└── Buerozeiten Mo-Fr, kein On-Call

Managed Service Partner:
├── 24/7 Monitoring und Alerting
├── On-Call-Rotation (Team aus 5-8 Engineers)
├── Incident Response und Eskalation
├── Cluster-Updates und Patching
├── Backup-Verifizierung
└── Compliance-Reporting

Der interne Engineer bleibt der Ansprechpartner fuer das Unternehmen und steuert die Zusammenarbeit mit dem Managed Service. Aber er geht um 18 Uhr nach Hause und schlaeft durch. Nachts kuemmert sich ein professionelles Team mit echten SLAs.

Rechnung fuer den Geschaeftsfuehrer

Wenn Sie dem Management die Situation erklaeren muessen, nutzen Sie diese Zahlen:

Kosten einer Stunde Downtime (Mittelstand, E-Commerce/SaaS):
├── Entgangener Umsatz:              500 - 5.000 EUR/h
├── SLA-Penalties:                   200 - 2.000 EUR/h
├── Produktivitaetsverlust intern:   300 - 1.000 EUR/h
├── Reputationsschaden:              schwer bezifferbar
└── Incident-Response-Kosten:        500 - 1.500 EUR/h
────────────────────────────────────────────────────────
Gesamt pro Stunde Ausfall:         1.500 - 9.500 EUR

Bei 4 ungeplanten Ausfaellen/Jahr (je 2h):
Jaehrliche Ausfallkosten:          12.000 - 76.000 EUR

Managed Service Jahreskosten:       36.000 - 72.000 EUR

Die Rechnung geht fast immer auf. Und dabei ist der Reputationsschaden noch nicht eingepreist -- ein mehrstuendiger Ausfall waehrend der Geschaeftszeiten kann Kundenbeziehungen nachhaltig beschaedigen.

Fazit

24/7 Kubernetes-Betrieb im Mittelstand mit 1-2 Admins ist ein Mythos, der Teams verschleisst und Unternehmen gefaehrdet. Die Mathematik ist eindeutig: Fuer echte Rund-um-die-Uhr-Abdeckung brauchen Sie entweder ein internes Team von mindestens 4 Personen oder einen externen Partner mit bestehender Rotation.

Die meisten Mittelstaendler fahren mit einem hybriden Modell am besten: Ein interner Engineer, der die Architektur versteht und das Tagesgeschaeft steuert, kombiniert mit einem Managed Service fuer 24/7-Monitoring, Incident Response und On-Call.

Ihr Admin wird es Ihnen danken. Und er bleibt laenger.

Wollen Sie wissen, wie ein 24/7 Managed Service konkret fuer Ihre Infrastruktur aussehen wuerde? Wir zeigen Ihnen in einem 30-minuetigen Gespraech, was realistisch ist -- Termin vereinbaren.