Viele stellen sich den Wechsel vom Cockpit in die Technik erstaunlich glatt vor: Disziplin lässt sich übertragen, Cloud ist leicht, und spätestens Dienstag ist man Thought Leader. Meine Erfahrung war anders. Ich bin für Lufthansa geflogen. Ich habe diesen Beruf aus persönlichen Gründen verlassen, nicht weil ich einen Masterplan für Vorträge oder Selbstvermarktung hatte. In DevOps bin ich gelandet, weil sich der Betrieb vom Temperament her vertraut anfühlte und die Werkzeuge gleichzeitig völlig fremd waren.
Foto von fauxels auf Pexels
Ich lerne Kubernetes immer noch. Wahrscheinlich werde ich es noch jahrelang lernen. Dieser Beitrag ist das, was ich am Anfang gern gelesen hätte: ehrlich, technisch und ohne diesen LinkedIn-Tonfall von „du schaffst alles, Krieger“.
Was sich übertragen ließ (weniger als die Poster versprechen)
Das Fliegen hat mir Gewohnheiten mitgegeben, die an schlechten Tagen helfen:
Erst besprechen, dann handeln. Was ändern wir, was kann schiefgehen, wie sieht der Rollback aus?
Ein Hebel nach dem anderen. Eine Variable ändern, beobachten und dem Drang widerstehen, drei Dinge gleichzeitig heldenhaft zu „reparieren“.
Checklisten unter Stress. Struktur bewahren, wenn Adrenalin zur Improvisation drängt.
Crew Resource Management. Sich melden, zuhören, Rollen klären und der Person, die gerade ausführt, nicht ins Wort fallen.
Respekt vor Verfahren, ohne sie anzubeten. Handbücher helfen, bis die Wirklichkeit abweicht. Dann muss man denken.
Was sich nicht übertragen ließ:
Die Tiefe des Fachwissens. In der Luftfahrt hatte ich Jahre mit Flugzeugsystemen, Vorschriften und Unternehmensverfahren verbracht. Bei Kubernetes war ich wieder Anfänger am Fuß einer steilen Lernkurve.
Die Karriereleiter. In der Luftfahrt war der Weg klar. In der Technik bedeuten Titel je nach Firma etwas anderes.
Selbstvertrauen durch Wiederholung. Ich hatte tausende Flugstunden. Meine ersten Fehler mit kubectl waren auf langweilige Weise peinlich: falscher Namespace, Tippfehler im Label-Selector.
Wenn man aus einem anderen Beruf wechselt, ist der alte Job ein Ausgangspunkt, keine Marke. Der nützliche Teil zeigt sich in der Arbeitsweise, nicht in Metaphern auf Folien.
Das erste Jahr fühlte sich an wie Instrumententraining im Nebel
Alles bestand aus Zeichen ohne Kontext.
Pods, Deployments, Services — ich konnte Definitionen auswendig lernen und trotzdem nicht verstehen, warum meine App nicht erreichbar war. CRDs tauchten auf wie neue Kartensymbole mitten auf der Strecke. Helm fühlte sich an wie ein Flugmanagementsystem, das ich zwar bedienen durfte, das mir aber niemand vollständig erklärt hatte.
Ich lernte ähnlich wie für Musterberechtigungen: strukturiert, wiederholend und mit Prüfungen, die ich mir selbst setzte.
Was technisch half:
Ein kleines Heimlabor. Erst minikube, dann kind, dann ein günstiger Cloud-Cluster, den ich ohne schlechtes Gewissen kaputt machen konnte. Beim Kaputtmachen lernt man schneller als beim Lesen.
Ein Buch von Anfang bis Ende. Ich habe mir ein Kubernetes-Buch ausgesucht und es beendet, statt nur Tabs zu sammeln. Welches Buch es ist, zählt weniger als das Durcharbeiten.
Offizielle Dokumentation für Konzepte, nicht Blogposts für Standardeinstellungen. Blogs altern. Die Kern-Dokumentation zu Pods, Services und Controllern erdet mich immer noch.
kubectl explain. Unterschätzt. Nutze ich weiterhin.
Was psychologisch half:
Im Standup sagen: „Ich weiß es nicht.“ Das ist schneller als sich durch eine Retrospektive zu bluffen.
Einen geduldigen Mentor finden. Kein Guru, sondern ein Kollege, der einfache Fragen beantwortete, ohne mich einfach wirken zu lassen.
Notizen in eigenen Worten schreiben. Wenn ich ein ReplicaSet nicht ohne Jargon erklären konnte, hatte ich es noch nicht verstanden.
Im zweiten Jahr kamen OpenShift und echte Produktionsumgebungen
Lehrbuch-Cluster lügen höflich. Produktionscluster haben Quotas, Network Policies, alte Ingress-Regeln, verzögerte Secret-Synchronisierung und Diskussionen darüber, wem der Plattform-Namespace gehört.
Bei der Arbeit kam ich mit OpenShift in Berührung: Routes statt nur Ingress, SCCs, operatorgesteuerte Installationen. Der Kubernetes-Kern war derselbe, die Leitplanken waren anders. Das verwirrte mich, bis ich anfing, zwischen „Upstream-Konzept“ und „Herstellerpaket“ zu unterscheiden.
Produktionsumgebungen lehren Dinge, die kein Labor lehrt:
Readiness und Liveness sind nicht akademisch. Falsche Probes nehmen Services bei langsamen Starts aus dem Verkehr oder lassen kaputte Pods weiter Anfragen bekommen.
Resource Limits können wehtun. OOMKilled sieht wie ein rätselhafter Absturz aus, bis man genauer hinsieht.
GitOps ist Richtlinie und Arbeitsweise, keine Magie. Controller gleichen Zustand ab; Menschen mergen trotzdem schlechtes YAML.
Störungen werden gemeinsam gelöst. Meine CRM-Gewohnheiten halfen. Meine Lücken bei Linux-Netzwerken taten weh. Ich habe mich auf Teamkollegen gestützt, statt Kapitänsgehabe zu spielen.
Ich lernte außerdem, in ruhigen Phasen zu dokumentieren: Runbooks, Postmortem-Notizen, „so funktionieren unsere Helm Values wirklich“. In der Luftfahrt gab es Handbücher; ich versuchte, die Teile zu schreiben, die ich mir als Neuer gewünscht hätte.
Was ich bewusst nicht gemacht habe
Jede Zertifizierung gleichzeitig jagen. Zertifikate haben Wert. Sie als Aufschub vor dem praktischen Bauen zu stapeln, eher nicht.
Luftfahrtanalogien öffentlich überziehen. Manche passen. Viele sind konstruiert. Ich nutze sie sparsam, weil ich beide Felder ernst nehme.
Mich mit Ingenieuren vergleichen, die mit zwanzig angefangen haben. Anderer Weg, anderer Zeitplan. Dieser Vergleich hat mich Monate Ruhe gekostet.
„Leidenschaft“ sagen, wenn ich „Neugier gemischt mit Frust“ meinte. Ehrliche Sprache hat mich weitergebracht.
Fähigkeiten, an denen ich noch arbeite
Offen über Lücken zu sprechen, hält mich bescheiden und brauchbar:
Linux-Interna und Netzwerke. tcpdump fühlt sich immer noch an wie eine Fremdsprache, die ich langsam sprechen lerne.
Service Meshes. Istio habe ich in Übungen genutzt; Alltagstiefe habe ich dort noch nicht.
Observability-Stacks. Dashboards bedienen kann ich. SLOs und sinnvolle Alerts zu entwerfen, lerne ich weiter.
Terraform und Cloud-IAM in größerem Maßstab. Genug, um gefährlich zu sein; nicht genug, um Architekt zu sein.
Go. Controller-Code langsam lesen; kleine Werkzeuge schlecht, aber brauchbar schreiben.
Kubernetes ist eine Plattform auf Plattformen. Man wird damit nicht fertig. Man vertieft sich in den Ausschnitten, die der eigene Job berührt, und behält den Rest im Blickfeld.
Wie sich der Berufswechsel wirklich anfühlte
Manchmal einsam. In der Luftfahrt gab es eine Crew. In den ersten DevOps-Monaten gab es Slack und Impostor-Syndrom.
Finanziell und für die eigene Identität tat der Neustart weh. „Pilot“ war eine klare Rolle. „Platform Engineer, der sich einarbeitet“ war zutreffend und wenig glamourös.
Belohnend wurde es, wenn etwas einrastete. Als ich zum ersten Mal einen fehlgeschlagenen Deploy selbst von Ingress bis zu einer falsch konfigurierten Probe nachvollziehen konnte — nicht heroisch, nur korrekt — fühlte es sich ähnlich still zufrieden an wie ein sauberer Anflug bei mäßigem Wetter. Ein kleiner Beweis, dass die Lernschleife funktionierte.
Ich wurde kein Influencer. Ich wurde einstellbar, dann nützlich im Team und später jemand, den Neuere fragen konnten, ohne dass ich in Buzzwords auswich.
Ratschläge, die ich vorsichtig gebe
Weil die Rahmenbedingungen überall anders sind:
Teams suchen, die lehren. Markennamen zählen weniger als Prüfungskultur und psychologische Sicherheit.
Ein Portfolio gelöster Probleme aufbauen, keine Sammlung von Hello-World-Repos. Einen verstandenen Vorfall aufschreiben, eine eigene Automatisierung erklären, eine verbesserte Dokumentation zeigen.
Alte Fähigkeiten übersetzen, ohne im Vorstellungsgespräch Metaphern zu erzwingen. Erst „Ich arbeite ruhig unter Zeitdruck und kommuniziere strukturiert“, dann vielleicht „ich behandle Pods wie Flugzeuge“.
Schlaf schützen. Müdes Lernen bleibt schlecht hängen. Das wusste ich aus der Luftfahrt und habe es in der Bootcamp-Kultur trotzdem ignoriert. Das war ein Fehler.
Freundlich zum früheren Ich bleiben. Die Pilotjahre waren nicht verschwendet. Sie waren ein anderes Kapitel.
Kubernetes im Besonderen und „DevOps“ im Allgemeinen
DevOps ist eine Art von Arbeit: Auslieferung, Zuverlässigkeit, Zusammenarbeit und ein Durcheinander aus Werkzeugen. Kubernetes ist ein Orchestrator unter mehreren Optionen, in vielen Firmen zentral und in anderen gar nicht vorhanden.
Ich habe mich auf Kubernetes konzentriert, weil meine Rollen dorthin zeigten. Wenn man wechselt und das Zielunternehmen eher Managed PaaS oder Serverless nutzt, ist Tiefe dort wertvoller als flaches k8s-Trivia. Die Prinzipien übertragen sich: Idempotenz, Observability, Rollback, Least Privilege.
Wenn man wie ich bei Kubernetes landet:
Die Konzepte der Control Plane lernen — die Rolle von etcd, Grundlagen des Schedulers, das mentale Modell der Controller-Schleife — auch wenn man keine Cluster installiert. Das erklärt Symptome.
Helm oder Kustomize früh genug lernen, um zu verstehen, wie Teams Wirklichkeit paketieren.
Mindestens ein schmerzhaftes Upgrade oder eine Migration im Labor durchführen. Version Skew lehrt Demut.
Was ich meinem früheren Ich sagen würde
Du bist nicht für immer zurück. Du bist heute zurück, und das ist normal.
Bitte um eine Prüfung des Diffs. Biete an, bei Störungen mitzuschreiben. Sichtbarkeit hilft mehr als stilles Kämpfen.
Der Luftfahrt-Hintergrund ist kein Marketinghaken, außer man macht ihn dazu. Er ist ein Arbeitsstil. Das reicht.
Führe ein Lernprotokoll. Daten, Fehler, Änderungen. Das zukünftige Ich wird Muster brauchen.
Warte nicht, bis du dich als Experte fühlst, um der nächsten neuen Person zu helfen. Zu erklären, was man letzte Woche gelernt hat, festigt es.
Abschluss
Ich bin Linienflugzeuge für Lufthansa geflogen. Heute arbeite ich mit Clustern, Pipelines und Störungen. Der Weg war keine Montage. Es waren Kurse, Fehler, geduldige Kollegen und viele Abende mit Dokumentation.
Wenn man aus der Luftfahrt kommt — oder aus der Pflege, der Musik oder irgendeinem anderen Feld mit eigener Tiefe — muss man kein Guru werden. Man muss in kleinen, überprüften Schritten kompetent werden und ehrlich bleiben bei dem, was man noch nicht weiß.
Kubernetes wird morgen noch da sein, weiter wachsen und weiter demütig machen. Genau deshalb bleibt es interessant. Die Startbahn ist eine andere. Die Notwendigkeit sorgfältiger Vorbereitung nicht.
