Verkehrsflugzeuge starten öfter mit nicht funktionsfähigen Teilen, als Passagiere ahnen. Nicht, weil die Wartung schlampig wäre, sondern weil die Luftfahrt zwischen „kaputt“ und „mit Einschränkungen freigegeben“ unterscheidet. Diese Trennung steckt in der Minimum Equipment List — der MEL — und im Urteil des Kapitäns, bezogen auf Wetter, Strecke und Erfahrung der Crew.
Foto von Pixabay auf Pexels
Kubernetes-Cluster haben selten ein formales MEL-Dokument. Sie haben READMEs, mündliches Wissen und ein Grafana-Board, das jemand während einer Störung gebaut hat. Wenn ein Node-Pool eingeschränkt ist, die Backup-Region hinterherhinkt oder der Observability-Stack halb ausfällt, während die Anwendungen noch antworten, ist man bereits im eingeschränkten Betrieb. Die Frage ist, ob man mit MEL-Disziplin arbeitet oder so tut, als sei alles voll verfügbar, bis das Gegenteil bewiesen ist.
Mit militärischen Metaphern in Ops-Texten bin ich vorsichtig. MEL-Denken ist kein Heldentum. Es ist Papierkram und Ehrlichkeit: Worauf verzichten wir gerade, unter welchen Grenzen, wie lange, mit welchen Ausgleichsmaßnahmen, und wer hat das freigegeben?
Komplett grün oder einsatzfähig
In der Wartung kann ein Flugzeug einen Fehler haben und trotzdem legal starten, wenn die MEL einen Aufschub erlaubt — oft mit Hinweisschildern, betrieblichen Grenzen oder reduzierter, aber nicht verlorener Redundanz. Betriebsvorgaben und Freigabe definieren, was „go“ heute bedeutet.
Im Cluster verwechseln wir technisch laufend mit voll leistungsfähig:
- Eine AZ ausgefallen, Datenverkehr umgeleitet — einsatzfähig mit Einschränkungen
- Metrik-Pipeline zehn Minuten verzögert — einsatzfähig, wenn man sie nicht für automatischen Rollback braucht
- Ein etcd-Mitglied in einem Dreier-Cluster ungesund — nicht einsatzfähig; jetzt landen
- HPA kaputt, feste Replica-Zahl trägt die aktuelle Last — einsatzfähig, bis Marketing eine Mail verschickt
- Backup-Restore seit neunzig Tagen ungetestet — einsatzfähig, bis es nicht mehr reicht; andere Risikokategorie
Der häufigste Fehler, den ich sehe: Teams liefern weiter Features aus und tragen bekannte Aufschübe mit sich herum, ohne sie aufzuschreiben. Das ist Fliegen mit überklebter Warnleuchte und ohne Eintrag im Logbuch.
Eine Cluster-MEL bauen (ohne FAA-Papierwerk zu spielen)
Man braucht keinen Lederordner. Man braucht eine lebende Liste — Wiki, Markdown im Repo, irgendetwas, das Menschen tatsächlich öffnen — ungefähr in der Struktur einer MEL-Zeile:
| Item | Eingeschränkter Zustand | Erlaubter Betrieb | Ausgleichende Kontrollen | Max. Aufschub | Verantwortlicher |
|---|---|---|---|---|---|
| Ingress Controller | Eine von zwei Replicas | Keine Config-Änderungen | Manueller Failover-Runbook | 24h | platform |
| Vault | Seal unreachable, Cache warm | Keine Secret-Rotation | Statische Creds eingefroren | 4h | security |
| Observability | Metriken verzögert | Kein automatisches Rollback | Manuelle Dashboard-Überwachung | 72h | SRE |
Nicht jede Zeile braucht am ersten Tag Zahlen. Beginnen kann man mit was bei einem Teilausfall weiterlaufen darf und was einen Stopp auslöst.
Unser erster Entwurf war hässlich — eine Stichpunktliste in einem Google Doc — und verhinderte trotzdem einen schlechten Freitag-Deploy, weil jemand fragte: „Ist Tracing noch aufgeschoben?“ Die Antwort war ja, also rollten wir keine Änderung aus, die Trace-IDs in der Produktionsumgebung brauchte.
Kubernetes-Komponenten durch die MEL-Brille
Verschiedene Schichten verschlechtern sich auf unterschiedliche Weise. Das hier sind bescheidene Notizen aus Dingen, die ich gesehen habe, kein vollständiger Katalog.
Control Plane und etcd
Quorum-Verlust ist keine Diskussion über eingeschränkten Betrieb; das ist sofortiges Ausweichen. Teilweise Latenz oder ein ungesundes Mitglied kann nur dann aufschiebbar sein, wenn Monitoring stabile Quorum-Verhältnisse belegt und ein Wartungsfenster geplant ist.
Ich habe Teams gesehen, die tagelang mit einer wackeligen Control Plane liefen, weil kubectl „manchmal noch ging“. Das ist kein MEL-Denken, das ist Glücksspiel. MEL-Denken heißt: Aufschub dokumentieren, Dauer begrenzen, häufiger prüfen, riskante Änderungen einfrieren.
Nodes und Kapazität
Eine Node in einem Pool mit Reserve verlieren — klassischer aufschiebbarer Punkt, wenn PodDisruptionBudgets und Surge-Kapazität das Neuplanen abfangen. Die Hälfte des Pools verlieren, während der HPA am Anschlag ist — betriebliche Grenze: keine Deploys, keine freiwilligen Disruptions, vielleicht Datenverkehr am Rand reduzieren.
Cordonierte Nodes ohne Drain-Plan sind Hinweisschilder, die niemand liest. Label setzen, im Ops-Kanal ankündigen, Kalendererinnerung zum Beheben oder Entfernen setzen.
Netzwerk und Ingress
Eine einzelne Ingress-Controller-Replica in einem kleinen Cluster — viele Teams laufen so, bis der erste OOM während der Zertifikatserneuerung passiert. MEL-Eintrag: maximaler Aufschub bis zum nächsten Werktag, Ausgleichsmaßnahme ist ein manuelles, in diesem Quartal getestetes Restart-Runbook.
Service-Mesh-Control-Plane eingeschränkt, während die Data-Plane-Proxies noch laufen — ein erstaunlich häufiger Zustand. Einsatzfähig für leselastigen Datenverkehr; nicht einsatzfähig für Änderungen an mTLS-Policies oder neue Routes, bis die Control Plane gesund ist.
DNS im Cluster: Wenn CoreDNS nur eine Replica hat und in CrashLooping hängt, ist das kein eingeschränkter Betrieb, sondern Feuer. Wenn externes DNS langsam ist, kube-dns aber funktioniert, ist das eine andere Tabellenzeile.
Data Plane: Datenbanken, Queues, Caches
Hier trifft MEL-Disziplin auf CAP-Theorem, ohne die Vorlesung. Primary läuft, asynchrone Replica hinkt hinterher — einsatzfähig mit keinen Schema-Migrationen und erhöhter Überwachung des Replication Lag. Cache-Cluster ohne eine Node — einsatzfähig, wenn Trefferquote und Latenz im SLO bleiben.
Die Ausgleichsmaßnahme ist oft menschlich: Jemand beobachtet während Deploys die Lag-Grafik, weil automatisierte Prüfungen im Aufschubzustand nicht vertrauenswürdig genug sind.
Observability-Stack
Teilweise ausgefallene Metriken oder Logs sind der gefährlichste Aufschub, weil es sich einsatzfähig anfühlt und gleichzeitig blind für den nächsten Fehler macht. Unsere MEL-Zeilen sind hier streng: Wenn automatischer Rollback von einer Metrik abhängt, muss dieser Metrikpfad grün sein, sonst wird Rollback manuell.
Tracing aufgeschoben — viele Teams leben wochenlang so. In Ordnung, wenn niemand bei Produktionsstörungen allein auf Traces angewiesen ist. Weniger in Ordnung, wenn Schritt drei im Runbook für den Bereitschaftsdienst „Jaeger öffnen“ lautet.
Warnhinweise: Einschränkungen sichtbar machen
Airlines kennzeichnen nicht funktionsfähige Ausrüstung im Cockpit — eine physische Erinnerung daran, dass Fähigkeiten reduziert sind. Kubernetes-Entsprechungen:
- Cluster-Annotations oder ConfigMaps —
degraded-mode: observability-lag, von Deploy-Pipelines gelesen, um riskante Jobs zu blockieren - Interner Statusseiten-Abschnitt — „bekannte Aufschübe“ für Ingenieure, nicht nur für Kunden
- Admission Policy — Deploys in bestimmte Namespaces ablehnen, solange Plattform-MEL-Punkte offen sind (schweres Werkzeug; sparsam einsetzen)
- Dashboard-Banner — einfacher Text: „Backup-Region-Übung Sonntag fehlgeschlagen; Failback ungetestet“
Es geht nicht um Beschämung. Es geht um gemeinsame Lagewahrnehmung. CRM zerfällt, wenn die halbe Crew weiß, dass der Autopilot eingeschränkt ist, und die andere Hälfte volle Automatisierung annimmt.
Wer freigibt: Verantwortung und Fristen
In der Luftfahrt gibt die Wartung das Flugzeug frei; der Kapitän akzeptiert es für den konkreten Flug. In Ops muss jemand den eingeschränkten Zustand für ein zeitlich begrenztes Fenster akzeptieren.
Vage Verantwortung erzeugt ewige Aufschübe. „etcd machen wir irgendwann“ heißt: nie.
Wir versuchen — nicht immer erfolgreich — Folgendes festzuhalten:
- Benannter Verantwortlicher — Team oder Person in der Bereitschaftsrotation
- Prüfdatum — Kalendereintrag, nicht „irgendwann“
- Ausstiegskriterien — was „behoben“ technisch bedeutet
- Eskalation — wer entscheidet, wenn der maximale Aufschub überschritten wird
Bei Kubernetes-Plattformarbeit kann „stop the line“ einen Deploy-Freeze bedeuten, eine Störungserklärung oder Failover in eine zweite Region, auch wenn diese Region weniger beliebt ist. Der maximale MEL-Aufschub existiert, damit dieses Gespräch passiert, bevor das Glück aufgebraucht ist.
Ausgleichsmaßnahmen, die keine Fantasie sind
MEL-Punkte brauchen Ausgleichsmaßnahmen, die tatsächlich durchgeführt werden, nicht nur theoretisch verfügbar sind.
Schlecht: „Wir können aus dem Backup wiederherstellen“, wenn seit dem Wechsel des Backup-Werkzeugs kein Restore getestet wurde.
Besser: „Restore in Q3 getestet; letzte Übung 34 Minuten bis RPO; Runbook Abschnitt 4.2; Bereitschaftsdienst geschult.“
Schlecht: „Wir haben zwei Ingress-Replicas“, wenn beide im selben Node-Pool ohne PDB laufen.
Besser: PDB verifiziert; Anti-Affinity bestätigt; Drain-Simulation letzten Monat durchgeführt.
In Kubernetes vertraue ich diesen Ausgleichsmaßnahmen häufiger:
- Manuelle Runbooks in Staging geübt (der Simulator-Bezug)
- Geringere Änderungsgeschwindigkeit — weniger parallele Deploys
- Menschliche Prüfpunkte — Zwei-Personen-Regel für Applies in der Produktionsumgebung, solange Automatisierung blind ist
- Grenzen für Datenverkehr — Rate Limit am Rand, solange das Backend fragil ist
- Feature Flags für nicht wesentliche Pfade deaktiviert
Jede davon kostet betrieblich etwas. MEL-Disziplin gibt diese Kosten zu, statt sie in technischer Schuld zu verstecken.
Wann eingeschränkt nicht mehr einsatzfähig ist
Manche Aufschübe verstärken sich gegenseitig. Eine AZ weg plus Observability-Lag plus festhängender HPA kann einzeln akzeptabel und zusammen katastrophal sein — man sieht die Lastspitze nicht, die den Rest erledigt.
Vor großen Ereignissen machen wir gelegentlich eine Kombinationsprüfung: offene MEL-Zeilen plus „was passiert, wenn noch eine Sache ausfällt?“ Keine formale FMEA; dreißig Minuten mit Kaffee.
Rote Linien, die uns meist auf nicht einsatzfähig drehen:
- Kunden-SLO-Burn ohne funktionierenden Rollback-Pfad
- Aufgeschobene Sicherheitskontrolle, die Secret- oder Zertifikatslebenszyklen während einer geplanten Rotation betrifft
- Frage zur Datenhaltbarkeit — Replication Lag über RPO, während der Schreibpfad offen bleibt
- Control-Plane-Instabilität wird schlechter statt stabil zu bleiben
Nicht einsatzfähig zu sagen, ist kein Scheitern. Es ist die MEL, die sagt: Dieser Flug geht nicht raus, bis die Wartung aufgeholt hat.
Verhältnis zu Störungsreaktion und Runbooks
Runbooks beschreiben Abläufe, wenn etwas unerwartet bricht. MEL beschreibt bekannte reduzierte Fähigkeit, die man bewusst trägt.
Sie treffen sich, wenn ein Aufschub zur Störung wird — die aufgeschobene Ingress-Replica fällt komplett aus — oder wenn die Störungsreaktion temporäre MEL-Einträge öffnet: „Autoscaling im Feuerwehreinsatz manuell deaktiviert; jetzt dokumentiert.“
Nach Störungen frage ich gern: Hätte das ein offen getragener Aufschub sein müssen statt einer Überraschung? Manchmal lautet die Antwort nein: echte unbekannte Unbekannte. Oft lautet sie ja: Wir wussten es und haben es nicht festgehalten.
Erste Schritte, wenn heute nichts existiert
Nicht den Ozean zum Kochen bringen.
- Drei Dinge auflisten, die in prod/staging gerade eingeschränkt sind und von denen „alle wissen“.
- Für jedes: erlaubter Betrieb, eine Ausgleichsmaßnahme und ein Prüfdatum.
- Einen Automatisierungshaken wählen — selbst ein Deploy-Script, das nach einer Env-Var sucht — der die riskanteste Aktion blockiert, solange der Punkt offen ist.
- Im wöchentlichen Ops-Standup prüfen, bis geschlossen oder bewusst verlängert.
Die erste MEL wird falsch sein. MELs in der Luftfahrt ändern sich durch Bulletins. Die eigene Liste sollte sich ändern, wenn die Architektur sich ändert.
Was ich falsch mache
Ich schiebe Dinge im Kopf auf, ohne sie aufzuschreiben. Ich nehme an, jeder auf der Plattformseite wisse, dass die Backup-Region nur als Read-only-Übung existiert. Ich lasse „temporäre“ Abhilfen dauerhaft werden, weil das Ticket an Priorität verliert. Ich liefere trotzdem aus, wenn ich müde bin, und rede mir ein, dass wir es Montag beheben.
MEL-Denken macht mich bei Innovation nicht konservativer. Es macht mich ehrlicher darüber, was wir eintauschen. Kubernetes will Ausfälle abstrahieren; Betreiber müssen sie trotzdem benennen.
Nicht jede Warnleuchte muss dunkelgrün sein, um zu operieren. Man muss wissen, welche überklebt sind, was das begrenzt und wann der Flug nicht starten darf. Das ist die ganze Denkweise. Der Rest sind Wartungseinträge und das Erscheinen zum Prüfdatum.
