Wie steigt man aus einem anderen Bereich in DevOps-Engineering ein?

Der ehrliche Ausgangspunkt

DevOps ist keine Einstiegsposition, und es ist auch keine Disziplin, in die man sich wie etwa in die Buchhaltung einfach hineinzertifizieren kann. Es gibt keine Zulassungsstelle, keinen geschützten Titel, keine Prüfung, die allein die Tür öffnet. Das ist gleichzeitig die gute und die schlechte Nachricht. Gut, weil niemand Sie auf dem Papier ausschließen kann. Schlecht, weil es keinen festen Lehrplan gibt, den man abschließen und dann abhaken kann — Sie müssen selbst einen praktischen Nachweis aufbauen, und der Personalverantwortliche muss davon überzeugt werden, dass er echt ist.

Die meisten Menschen, die in DevOps wechseln, kommen aus einer von zwei Richtungen: aus der Softwareentwicklung (Code schreiben, im Team arbeiten, das regelmäßig ausliefert, Deployment-Pipelines nebenbei erlernen) oder aus Systemadministration und Infrastruktur (Server, Netzwerke und später Cloud-Accounts verwalten und dabei Code und Automatisierung erlernen). Wenn Sie aus einem ganz anderen Bereich kommen — Support-Desk, QA ohne Automatisierung, eine nicht-technische Rolle — ist der Wechsel möglich, aber er dauert länger, und Sie sollten das ehrlich einplanen, anstatt anzunehmen, dass sechs Monate ausreichen.

Was tatsächlich übertragbar ist

Seien Sie ehrlich zu sich selbst, welche dieser Fähigkeiten Sie bereits haben, denn vage Hoffnung übersteht kein Vorstellungsgespräch.

• Linux-Grundlagen. Wenn Sie sich in einer Shell zurechtfinden, Benutzer und Berechtigungen verwalten, Logs lesen und Prozesse und Dienste verstehen (systemd in den meisten aktuellen Umgebungen), ist das eine echte, übertragbare Basis. Die meiste DevOps-Arbeit findet auf Linux statt, selbst wenn das Frontend eine Cloud-Konsole ist.
• Skripting. Bash und Python sind die beiden Sprachen, die Sie am häufigsten sehen werden — Bash für Verknüpfungen und schnelle Automatisierung, Python für alles mit mehr Logik (oder Go in manchen Infrastructure-Tooling-Umgebungen). Wenn Sie Skripte geschrieben haben, um eine sich wiederholende Aufgabe in irgendeinem Job zu automatisieren, zählt diese Erfahrung, selbst wenn der Job selbst nicht technisch war.
• Versionsverwaltung. Git, richtig eingesetzt — Branches, Pull Requests, Konflikte auflösen — nicht nur "Ich habe GitHub verwendet, um etwas herunterzuladen." Das ist vorausgesetztes Wissen, kein Verkaufsargument, also machen Sie es solide, bevor Sie sich bewerben.
• Netzwerk-Grundlagen. DNS, HTTP, Load Balancing, Firewalls auf konzeptioneller Ebene. Sie brauchen keine Netzwerk-Zertifizierung, aber Sie müssen erklären können, warum eine Anfrage zwischen einem Load Balancer und einem Backend-Service fehlschlagen könnte.
• Arbeit in einer Umgebung mit Produktionsfolgen. Wenn Sie ein Live-System unterstützt haben, in einem Bereitschaftsdienst waren oder in irgendeiner technischen Rolle unter Zeitdruck mit einem Ausfall umgegangen sind, ist diese Erfahrung näher an der DevOps-Realität als viel theoretisches Studium.
• Cloud-Erfahrung jeglicher Art. Selbst grundlegende AWS-, Azure- oder GCP-Nutzung — ein persönliches Projekt deployen, Speicher und Rechenleistung für ein Hobby verwalten — ist mehr wert, als es scheinen mag, weil so viel der Arbeit jetzt innerhalb einer dieser drei Plattformen stattfindet.

Was sich nicht überträgt, egal wie senior Sie in Ihrem vorherigen Bereich waren: Projektmanagement-Erfahrung, allgemeines "Ich bin gut mit Technologie" und ein Tool als Konsument verwendet zu haben, anstatt es konfiguriert oder automatisiert zu haben. Ein Personalverantwortlicher, der einen DevOps-Lebenslauf liest, kann den Unterschied erkennen zwischen jemandem, der terraform apply auf selbst geschriebener Infrastruktur ausgeführt hat, und jemandem, der zugesehen hat, wie jemand anderes es tat.

Der Zertifizierungs- und Qualifikationsweg

Es gibt keine Lizenz und keine Berufsorganisation, die diesen Beruf bewacht, aber es gibt eine anerkannte Reihe von Anbieter-Zertifizierungen, die bei Personalverantwortlichen echtes Gewicht haben, weil sie zumindest beweisen, dass Sie die Labs gemacht haben.

• Cloud-Plattform-Zertifizierungen — AWS Certified DevOps Engineer – Professional, Microsofts Azure DevOps Engineer Expert oder Googles Professional Cloud DevOps Engineer. Das sind die nächste Entsprechung zu einer anerkannten Qualifikation in diesem Bereich. Sie sind nicht einfach und setzen voraus, dass Sie bereits praktische Erfahrung mit der Plattform haben, nicht nur Lernmaterial — die Prüfungen enthalten Szenario-Fragen, die schwer nur aus der Theorie heraus zu bestehen sind.
• Certified Kubernetes Administrator (CKA) von der Cloud Native Computing Foundation. Kubernetes erscheint inzwischen in vielen DevOps-Stellenanzeigen, und der CKA ist eine der wenigen Zertifizierungen in diesem Bereich, die tatsächlich praktisch ist — Sie verwalten während der Prüfung einen echten Cluster, keine Multiple-Choice-Fragen.
• HashiCorp Certified: Terraform Associate. Infrastructure as Code ist in dieser Rolle inzwischen nahezu universal, und Terraform ist das Tool, das die meisten Anzeigen konkret nennen.

Keine davon ersetzt ein Portfolio. Arbeitgeber, die DevOps-Engineers einstellen, möchten in der Regel Arbeit sehen, nicht nur Zeugnisse — ein GitHub-Profil mit echtem Infrastruktur-Code, ein dokumentiertes Home Lab, ein Blog-Beitrag, der durchgeht, wie Sie eine CI/CD-Pipeline für ein persönliches Projekt aufgebaut haben. Wenn Sie nur eine Sache tun können, bevor Sie sich bewerben, bauen Sie etwas, das Sie zeigen und im Detail durchsprechen können, und holen Sie dann die Zertifizierung, die dazu passt.

Was Ihre Bewerbung überwinden muss

Eine DevOps-Bewerbung beim Quereinstieg steht vor einem spezifischen, wiederkehrenden Einwand: Der Leser nimmt an, dass Sie ein Generalist sind, der sich ein paar Tutorials angesehen hat, und nicht jemand, dem man Produktionsinfrastruktur und einen Bereitschaftsdienst anvertrauen kann. Sie müssen diesen Einwand direkt beantworten, denn der Lebenslauf allein tut es nicht.

Das erste Problem ist meist die Form des Lebenslaufs. Wenn Ihr aktuellster Jobtitel nichts mit Infrastruktur, Engineering oder Software zu tun hat, wird ein schnell scannender Recruiter daran vorbeilesen, bevor er den Absatz erreicht, in dem Sie Ihr Terraform-Projekt erklären. Platzieren Sie die relevanten Nachweise — die Tools, das Projekt, die Zertifizierung — im ersten Drittel der Seite, nicht vergraben unter einer chronologischen Berufsgeschichte, die mit irrelevanten Titeln beginnt.

Das zweite Problem ist Tiefe versus Breite. Quereinsteiger listen oft jedes Tool auf, das sie einmal berührt haben (Docker, Jenkins, Ansible, Prometheus, Grafana, Kubernetes), ohne bei einem davon zwei Fragen tief gehen zu können. Interviewer in diesem Bereich fragen "Führen Sie mich durch, was passiert, wenn diese Pipeline läuft" oder "Was würden Sie zuerst prüfen, wenn dieses Deployment um 2 Uhr morgens fehlschlägt" — Fragen, die Menschen, die einmal etwas konfiguriert haben, von Menschen trennen, die es verstehen. Wählen Sie weniger Tools und kennen Sie sie richtig, anstatt alles aufzulisten, was Sie kurz angesehen haben.

Das dritte Problem ist die Geschichte. Sie brauchen eine kohärente Antwort auf "Warum DevOps, warum jetzt", und sie muss von der Arbeit handeln, nicht davon, Ihrem alten Bereich zu entkommen. "Ich war die Person, die alles automatisiert hat, was mein Team manuell gemacht hat" ist eine echte Antwort. "Ich möchte eine Veränderung und DevOps zahlt gut" trifft auf viele Menschen zu, übersteht aber kein Vorstellungsgespräch.

Wie lange das tatsächlich dauert

Es gibt keine verlässliche veröffentlichte Zahl dafür, wie lange ein Quereinstieg in DevOps dauert, und seien Sie skeptisch gegenüber jedem, der eine angibt, denn es hängt enorm von Ihrem Ausgangspunkt ab. Was sich ehrlich sagen lässt:

Wenn Sie bereits Softwareentwickler sind, ist der seitliche Wechsel in eine DevOps- oder Platform-Engineering-Rolle realistisch eine Frage von Monaten — Sie erweitern Fähigkeiten, die Sie bereits haben, und viele Unternehmen stellen Entwickler gezielt für diese Rollen ein, weil sie programmieren können.

Wenn Sie Systemadministrator oder Netzwerk-Engineer sind und in Cloud-natives DevOps wechseln, hängt der Zeitplan hauptsächlich davon ab, wie viel Skripting und Infrastructure-as-Code Sie bereits machen. Manche schaffen diesen Wechsel in unter einem Jahr; andere brauchen länger, weil die Umstellung von der Verwaltung physischer oder virtueller Server zur Verwaltung von allem als Code eine echte Änderung in der Denkweise über die Arbeit ist, nicht nur ein neues Toolset.

Wenn Sie aus einem nicht-technischen Bereich kommen, seien Sie realistisch: Das ist üblicherweise ein Ein- bis Zwei-Jahres-Projekt, nicht das Ergebnis eines Wochenend-Bootcamps, wenn Sie von fast null aufbauen — Linux lernen, eine Skriptsprache, Cloud-Grundlagen und ein Portfolio, wahrscheinlich während Sie Ihren aktuellen Job machen. Bootcamps und Kurzkurse existieren und manche Menschen werden nach ihnen eingestellt, aber der Markt für als junior bezeichnete "DevOps"-Rollen ist dünn; die meisten Stellenanzeigen mit diesem Titel erwarten etwas vorherige Infrastruktur- oder Entwicklungserfahrung, weil die Rolle nachgelagert zu beiden Disziplinen liegt, anstatt ein Anfänger-Einstiegspunkt in eine der beiden zu sein.

Was als Nächstes zu tun ist

Finden Sie ehrlich heraus, welchem der beiden Ausgangspunkte Sie näher sind — Entwickler oder Infrastruktur — und bauen Sie die fehlende Hälfte gezielt auf: Entwickler brauchen Linux, Netzwerke und Infrastructure-as-Code; Systemadministratoren brauchen Skripting-Tiefe und CI/CD-Pipeline-Erfahrung. Bauen Sie ein echtes Projekt, das Sie im Detail durchsprechen können, machen Sie die Zertifizierung, die dazu passt, und schreiben Sie Ihren Lebenslauf um, sodass die relevanten Nachweise im ersten Drittel der Seite stehen, nicht im letzten. Wenn Sie bereit sind, sich zu bewerben, liest jobmarket.pro jede Anzeige gegen Ihr tatsächliches Profil und sagt Ihnen, bevor Sie etwas senden, wo Sie wirklich passen und wo nicht.