So schreibst du einen Lebenslauf für eine DevOps-Position

Wonach Hiring Manager zuerst suchen

Ein DevOps-Hiring-Manager liest einen Lebenslauf auf der Suche nach Belegen für zwei Dinge, bevor alles andere kommt: welche Teile der Toolchain du tatsächlich betrieben hast und ob du Produktionsverantwortung getragen hast oder es nur in einer Sandbox angefasst hast. Beim ersten Durchgang wird gescannt, nicht gelesen. Das bedeutet, das erste Drittel der Seite muss die Frage ‚was haben sie in Production betrieben, und in welchem Umfang' beantworten, ohne dass der Leser danach suchen muss.

Das unterscheidet sich von einem Software-Engineering-Lebenslauf, wo nach Programmiersprachen und Systemdesign gescannt wird. Ein DevOps- oder SRE-Hiring-Manager will die spezifischen Orchestrierungs- und Provisionierungstools sehen (Kubernetes, Terraform, Ansible, Pulumi), welche Cloud (AWS, Azure, GCP — und welche Services darin, denn ‚AWS' allein sagt wenig aus), die CI/CD-Tools (Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD) und ob du On-Call-Verantwortung hattest. Wenn dein Lebenslauf mit einer generischen Zusammenfassung über ein ‚ergebnisorientierter Professional' beginnt, hast du die sechs Sekunden, die du hattest, für etwas verwendet, das nichts aussagt.

Setze den Stack, den du verwendet hast, und deine spezifische Verantwortung darin in den ersten Jobeintrag, in die ersten zwei Zeilen. ‚Verantwortlich für Terraform-Module zur Provisionierung von EKS-Clustern über drei AWS-Accounts' erfüllt den Zweck. ‚Verantwortlich für Infrastruktur und Deployment-Prozesse' nicht, weil es unverändert auch auf den Lebenslauf eines Sysadmins oder Build-Engineers kopiert werden könnte. Das ist der Test: Wenn ein Satz genauso gut auf den Lebenslauf einer anderen Berufsgruppe passen würde, streiche ihn.

Zertifizierungen und wie viel sie tatsächlich zählen

Es gibt keine Berufszulassung für DevOps-Engineers — keine berufsständische Kammer, nichts Vergleichbares zu einer Anwaltszulassung oder einem Gas-Safe-Zertifikat. Zertifizierungen funktionieren hier also als Signal, nicht als Zugangshürde, und Hiring Manager unterscheiden sich erheblich darin, wie viel Gewicht sie ihnen geben. Es lohnt sich, über diese Variation ehrlich zu sein, anstatt so zu tun, als gäbe es eine einheitliche Antwort.

Die Zertifizierungen, die in diesem Bereich tatsächlich anerkannt werden, sind begrenzt: AWS Certified DevOps Engineer – Professional, AWS Certified Solutions Architect, Microsofts Azure Administrator (AZ-104) oder Azure DevOps Engineer Expert (AZ-400), Googles Professional Cloud DevOps Engineer, der Certified Kubernetes Administrator (CKA) und Certified Kubernetes Application Developer (CKAD) von der CNCF sowie HashiCorps Terraform Associate. Wenn du eine davon besitzt, liste sie mit dem Jahr auf — Zertifizierungen in diesem Bereich altern, weil sich die Services und Prüfungsinhalte alle ein bis zwei Jahre ändern, und ein Associate-Level-Zertifikat von 2019 liest sich anders als eines von 2025.

Was nicht hilft: jeden Udemy- oder Coursera-Kurs aufzulisten, den du abgeschlossen hast. Ein Hiring Manager, der herausfinden muss, ob ‚Docker & Kubernetes: The Complete Guide' eine herstelleranerkannte Qualifikation oder ein Wochenendkurs ist, wird Letzteres annehmen und weitergehen. Wenn selbstgesteuertes Lernen tatsächlich relevant ist, setze es in eine kurze ‚derzeit lerne ich'-Zeile, anstatt es als gleichwertig mit einer Zertifizierung darzustellen — der Unterschied ist für jeden im Feld sofort sichtbar, und so zu tun als wäre es anders, kostet dich Glaubwürdigkeit bei allem anderen auf der Seite.

Eins ist es wert, direkt zu benennen: Es gibt keine guten Belege dafür, dass Zertifizierungen mit der Leistung im Job in diesem Bereich korrelieren, und viele erfahrene Engineers in Senior-Rollen haben keine. Behandle sie als nützliche Abkürzung für einen Recruiter beim ersten Durchgang, nicht als Kompetenznachweis für jemanden Technisches beim zweiten.

Wie Erfahrung in diesem Bereich normalerweise belegt wird

DevOps-Arbeit produziert nicht die Art von Portfolio, auf das ein Designer oder Autor verweisen kann. Niemand kann sich deine Terraform-State-Datei ansehen. Der Lebenslauf muss also selbst die Belegarbeit leisten, durch Spezifika, die im Prinzip überprüfbar sind, auch wenn der Leser sie nicht überprüft.

Die Spezifika, die Gewicht haben:

• Größenordnung: Anzahl der Nodes, Cluster, Services oder Environments, für die du verantwortlich warst. ‚Verwaltete die Kubernetes-Plattform' ist vage; ‚betrieb ein 40-Node-EKS-Cluster, das 12 Production-Services bediente' ist es nicht.
• Vorher-Nachher-Betriebskennzahlen, die du tatsächlich deiner Arbeit zuschreiben kannst: Deployment-Frequenz, Lead Time for Changes, Mean Time to Recovery (MTTR), Change Failure Rate — die vier DORA-Metriken sind das Nächste, was dieses Feld an einer gemeinsamen Messsprache hat, und zu benennen, welche du bewegt hast und ungefähr um wie viel, ist weit stärker als ‚verbesserte Deployment-Effizienz'.
• Incident-Verantwortung: ob du die Person warst, die gerufen wurde, nicht nur jemand in einem Team, das einen On-Call-Turnus hatte. ‚Primär on-call für Zahlungsinfrastruktur, eine Woche von vier' ist spezifisch. ‚Nahm an Incident Response teil' ist es nicht.
• Migrations- und Plattformarbeit: Umzug von EC2 zu Containern, von einem Monolithen zu Microservices, von selbstverwaltetem Kubernetes zu einer Managed Control Plane, von Jenkins zu GitOps mit ArgoCD. Migrationen sind natürliches Lebenslauf-Material, weil sie ein klares Vorher, Nachher und eine Dauer haben.
• Kosten: Cloud-Kostenoptimierung ist etwas, wonach FinOps-versierte Hiring Manager gezielt suchen, und es wird selten erwähnt. Wenn du Instanzen richtig dimensioniert, Workloads auf Spot verschoben oder reservierte Kapazität neu verhandelt hast und es die Ausgaben reduziert hat, sag es — dies ist einer der wenigen Orte, wo eine Zahl hingehört, vorausgesetzt, es ist eine, hinter der du in einem Interview stehen kannst.

Was keine Erfahrung belegt: eine bloße Liste von Tool-Namen ohne Kontext. ‚Skills: AWS, Docker, Kubernetes, Terraform, Jenkins, Prometheus, Grafana' oben auf der Seite sagt einem Hiring Manager, dass du von diesen Tools gehört hast. Es sagt nicht, was du damit gemacht hast. Jedes genannte Tool sollte erneut erscheinen, an eine Aufgabe gebunden, irgendwo im Erfahrungsbereich — wenn nicht, nimmt der Hiring Manager vernünftigerweise Berührung statt Verantwortung an.

Was konkret auf die Seite gehört

• Der Cloud-Provider und die Tiefe darin. Nicht nur AWS — welche Services. EC2 und S3 ist basic; EKS, RDS, IAM-Policy-Design, VPC-Peering und Lambda für Automatisierung ist ein anderes Level der Plattform.
• Infrastructure-as-Code-Tools und ob du Module geschrieben oder konsumiert hast. Es gibt einen echten Unterschied zwischen dem Schreiben eines wiederverwendbaren Terraform-Moduls, das von anderen Teams genutzt wird, und dem Anwenden von jemandem anderes Modul.
• Container-Orchestrierungs-Spezifika: Kubernetes-Distributionen sind wichtig (Vanilla, EKS, GKE, AKS, OpenShift), ebenso die umgebenden Tools — Helm, Kustomize, Service Meshes wie Istio oder Linkerd, wenn du sie verwendet hast.
• Observability-Stack: Prometheus, Grafana, Datadog, der ELK/EFK-Stack, OpenTelemetry. Sage, was du instrumentiert hast, nicht nur welches Dashboard du dir angesehen hast.
• CI/CD-Plattform und Pipeline-Design, einschließlich ob Pipelines etwas waren, das du innerhalb eines bestehenden Templates konfiguriert hast, oder etwas, das du von Grund auf entworfen hast, einschließlich Artefakt-Management und Rollback-Strategie.
• Security- und Compliance-Berührungspunkte relevant für diese Rolle: Secrets-Management (Vault, AWS Secrets Manager), SOC-2- oder ISO-27001-Audit-Unterstützung, Least-Privilege-IAM-Arbeit. Wenn du ein Compliance-Audit als der Engineer durchlaufen hast, der Nachweise dafür produzieren musste, ist das eine Zeile wert — sowohl Auditoren als auch Hiring Manager erkennen es als eine spezifische Art von Druck.
• Sprache für Automatisierung und Tooling — Python, Go, Bash — benannt als Tools für einen Zweck (Schreiben von Custom Operators, Automatisierungsskripten, internen CLIs), nicht als generische ‚Programmiersprachen'-Liste.

Was Kandidaten aus diesem Bereich routinemäßig weglassen

Die häufigste Lücke ist Team- und Organisationskontext. DevOps sitzt per Definition zwischen Development und Operations, und ein Lebenslauf, der nicht sagt, mit wem du gearbeitet hast — ‚eingebettet in zwei Produktteams', ‚einziger Platform-Engineer, der 30 Entwickler unterstützt', ‚Teil eines vierköpfigen SRE-Teams mit Follow-the-Sun-On-Call' — lässt den Hiring Manager unfähig, den Scope zu beurteilen. Dieselbe Infrastrukturarbeit bedeutet etwas anderes, wenn allein gemacht versus als Teil eines zwölfköpfigen Plattformteams.

Die zweite Lücke ist Ausfall. Engineers in diesem Bereich sind oft unwohl damit, einen Ausfall in ihren Lebenslauf zu setzen, aber ein gut gehandhabter Incident mit einer klaren Beschreibung, was kaputt ging, was du getan hast und was sich danach änderte, ist ein stärkerer Beleg für Seniority als eine weitere Zeile über ‚Aufrechterhaltung der Uptime'. Jeder kann hohe Verfügbarkeit behaupten; nicht jeder kann beschreiben, was er das eine Mal getan hat, als sie nicht verfügbar war.

Das Dritte ist die langweilige Wartungsarbeit, die eine Plattform am Laufen hält — Patching, Dependency-Upgrades, Zertifikatsrotation, Backup- und Restore-Tests. Es ist unspektakulär, also streichen Leute es, aber ein Hiring Manager, der ein ops-lastiges Team aufbaut, wird oft mehr darüber kümmern, ob du tatsächlich eine Disaster-Recovery-Übung durchgeführt hast, als ob du das neueste Tool im Stack verwendet hast.

Schließlich lassen Leute was sie entschieden haben nicht zu tun weg. Platform Engineering geht genauso sehr darum, Nein zu unnötiger Komplexität zu sagen, wie Dinge zu bauen. Eine Zeile wie ‚riet von einer Service-Mesh-Migration aufgrund von Kosten und operativem Overhead ab' signalisiert Urteilsvermögen, das eine Tool-Liste niemals wird.

Was du als Nächstes tun solltest

Gehe deinen aktuellen Lebenslauf Zeile für Zeile durch und frage für jedes Bullet: Könnte dieser Satz unverändert auf dem Lebenslauf eines Systemadministrators oder Backend-Entwicklers stehen? Wenn ja, füge das spezifische Tool, die spezifische Größenordnung oder die spezifische Metrik hinzu, bis es nicht mehr könnte. Prüfe dann, dass jedes Tool, das du in einer Skills-Liste genannt hast, auch an eine Aufgabe gebunden in deinem Erfahrungsbereich erscheint — wenn nicht, füge entweder die Aufgabe hinzu oder entferne das Tool.

Wenn du Bewerbungen versendest und nichts zurückhörst, lohnt es sich zu prüfen, ob die Lücke der Lebenslauf oder die Passung ist — viele DevOps-Rollen, die unter einem Titel ausgeschrieben sind, decken ganz unterschiedliche tatsächliche Arbeit ab, von Platform Engineering über Release Management bis zu reinem SRE, und ein Lebenslauf, der für eines abgestimmt ist, liest sich als Mismatch für ein anderes. jobmarket.pro liest jede Anzeige vollständig und bereitet die Bewerbung aus deiner tatsächlichen Erfahrung vor, abgestimmt auf das, wonach diese spezifische Rolle fragt, anstatt denselben Lebenslauf bei jeder Ausschreibung zu senden, nur mit geändertem Jobtitel.