Engineering
Software Engineer
Fünf Level von Junior bis Principal und sechs Kompetenzen – vom Ausliefern von Code bis zur Entwicklung des Teams.
- 5 Level
- 6 Kompetenzen
Vorlage für eine Karriereleiter
Karriereleiter für DevOps Engineers: Vorlage
Vier Level vom Junior bis zum Staff DevOps Engineer und sechs Kompetenzen – von Infrastruktur bis Developer Enablement.
Kostenloser Plan · Keine Kreditkarte nötig
Diese Karriereleiter ist für DevOps-, Plattform- und Infrastruktur-Engineers in Unternehmen mit etwa 20 bis 200 Mitarbeitenden gedacht. In dieser Größe besteht das Infrastrukturteam meist aus ein bis sechs Personen, die die Cloud-Accounts, die Delivery-Pipelines, Monitoring und Rufbereitschaft betreuen und ebenso viel Zeit damit verbringen, Entwicklern zu helfen, wie mit Servern. Sie beschreibt vier Level – von jemandem, der klar umrissene Infrastrukturänderungen umsetzt, bis zu der Person, die die Plattformrichtung des Unternehmens verantwortet. Das oberste Level, Staff DevOps Engineer, ist ein Fach-Level; das Infrastrukturteam zu führen ist ein eigener Job.
Jedes Level ist darüber definiert, was eine Person tut und wie viel vom System man ihr anvertraut, nicht über Berufsjahre oder die Zahl der Tools im Lebenslauf. Lies eine Zeile der Kompetenzmatrix von links nach rechts, um zu sehen, wie eine Erwartung wächst; lies den Abschnitt eines Levels, um alles zu sehen, was auf diesem Level erwartet wird. Nutze sie, um zu erklären, was das nächste Level bedeutet, um Check-ins zu strukturieren und um Beförderungsentscheidungen zu treffen, die du begründen kannst.
Passe sie an, bevor du sie veröffentlichst. Ersetze die allgemeinen Formulierungen durch euren eigenen Stack und eure Praktiken und streiche die Teile, die zu einem anderen Team gehören – zum Beispiel, wenn Sicherheit oder Datenbanken anderswo verantwortet werden.
Die Level im Überblick
Junior DevOps Engineer
Nimmt klar umrissene Änderungen an Infrastruktur und Pipelines mit Review vor und lernt, wie die Produktion läuft.
- Verantwortungsbereich
- Einzelne Änderungen an bestehendem Infrastrukturcode und bestehenden Pipelines, geplant und geprüft von einer erfahreneren Person.
DevOps Engineer
Verantwortet Teile der Infrastruktur von Anfang bis Ende und übernimmt einen vollen Anteil an der Rufbereitschaft.
- Verantwortungsbereich
- Services, Umgebungen oder Pipelines für ein oder zwei Produktteams, vom Design bis zum täglichen Betrieb.
Senior DevOps Engineer
Entwirft und leitet Infrastrukturprojekte, von denen mehrere Teams abhängen, und hebt die Latte für Zuverlässigkeit.
- Verantwortungsbereich
- Gemeinsame Infrastruktur, die der Großteil des Engineerings nutzt, und Projekte wie Migrationen, die jedes Team betreffen.
Staff DevOps Engineer
Gibt die Richtung der Plattform des Unternehmens vor und steht für ihre Zuverlässigkeit, Sicherheit und Kosten ein.
- Verantwortungsbereich
- Die gesamte Produktionsplattform, ihre mehrjährige Ausrichtung und ihr Budget, über alle Engineering-Teams hinweg.
Kompetenzmatrix
Jede Zeile ist eine Kompetenz, jede Spalte ein Level. Lies eine Zeile von links nach rechts, um zu sehen, wie die Erwartung wächst.
Was jede Kompetenz bedeutet
- Infrastructure as Code
- Infrastruktur über geprüften, reproduzierbaren Code aufbauen und ändern statt von Hand.
- Build- und Delivery-Pipelines
- Code schnell und sicher von einem gemergten Pull Request in die Produktion bringen.
- Zuverlässigkeit und Incident-Response
- Die Produktion verfügbar halten und sich schnell erholen, wenn sie es nicht ist.
- Monitoring und Observability
- Sichtbar machen, was die Produktion tut, und erkennen, wenn etwas schiefläuft.
- Sicherheit und Zugriffe
- Systeme und Daten durch sichere Voreinstellungen, minimale Rechte und schnelles Patchen schützen.
- Developer Enablement und Zusammenarbeit
- Entwicklern helfen, ihre eigenen Services zu betreiben, und Wissen teilen, damit die Plattform nicht an einer Person hängt.
| Kompetenz | Junior DevOps Engineer | DevOps Engineer | Senior DevOps Engineer | Staff DevOps Engineer |
|---|---|---|---|---|
| Infrastructure as Code | Ändert bestehenden Infrastrukturcode nach den vorhandenen Mustern, prüft den geplanten Diff vor dem Anwenden und ändert die Produktion nie von Hand, ohne vorher zu fragen. | Schreibt wiederverwendbare Infrastrukturmodule für neue Services und Umgebungen, geht sicher mit State und Secrets um und entfernt Ressourcen, die nicht mehr genutzt werden. | Entwirft den Aufbau von Infrastrukturcode und Umgebungen des Unternehmens, leitet Änderungen wie Netzwerk- oder Cluster-Upgrades mit einem getesteten Rollback-Plan und macht die Cloud-Kosten pro Team sichtbar. | Wählt die Kernbausteine und Anbieter der Plattform für die nächsten Jahre, setzt die Standards, denen die Infrastruktur jedes Teams folgt, und verantwortet das Infrastrukturbudget gemeinsam mit der Führungsebene. |
| Build- und Delivery-Pipelines | Repariert kaputte Pipeline-Schritte, ergänzt bestehende Pipelines um einfache Jobs und erklärt Entwicklern, warum ihr Build fehlgeschlagen ist. | Baut und pflegt die komplette Pipeline eines Service – Build, Tests, Artefakte, Deployments in jede Umgebung – und verkürzt langsame Schritte, über die sich Entwickler beschweren. | Entwirft gemeinsame Pipeline-Vorlagen, die jedes Team nutzt, führt sicherere Release-Methoden wie Canary- oder Blue-Green-Deployments ein und verfolgt Deployment-Frequenz und Fehlerquote. | Definiert, wie das ganze Unternehmen Software ausliefert, vom Branching bis zum Rollback, und beseitigt die Engpässe, die die Auslieferung in allen Teams bremsen. |
| Zuverlässigkeit und Incident-Response | Begleitet die Rufbereitschaft im Shadowing, folgt bei bekannten Alerts den Runbooks und eskaliert schnell mit den Informationen, die die nächste Person braucht. | Übernimmt einen vollen Anteil an der Rufbereitschaft, löst die meisten Incidents im eigenen Bereich ohne Hilfe, schreibt Runbooks für das, was behoben wurde, und testet Backups, indem sie tatsächlich wiederhergestellt werden. | Leitet die Reaktion auf größere Incidents, führt Post-Mortems ohne Schuldzuweisung durch, verfolgt die Folgemaßnahmen bis zum Abschluss und plant Kapazität und Failover für kritische Systeme. | Legt Zuverlässigkeitsziele mit Produkt und Führungsebene fest, gestaltet Rufbereitschaft und Incident-Prozess für das gesamte Engineering und plant für Katastrophen wie den Ausfall einer Region oder eines Anbieters. |
| Monitoring und Observability | Ergänzt Dashboards und Alerts nach vorhandenen Beispielen und prüft zuerst Logs und Metriken, wenn etwas falsch aussieht. | Richtet Logging, Metriken und Alerts für neue Services ein, stimmt Alerts so ab, dass jeder Page eine Handlung erfordert, und hilft Entwicklern, in den Daten zu finden, was sie brauchen. | Entwirft den Observability-Ansatz für die wichtigsten Systeme des Unternehmens, definiert die Health-Signale, an denen Teams gemessen werden, und reduziert Alert-Lärm über Teams hinweg. | Wählt das Observability-Tooling des Unternehmens und sein Kostenmodell und sorgt dafür, dass die Führungsebene den Zustand der Plattform sehen kann, ohne einen Engineer fragen zu müssen. |
| Sicherheit und Zugriffe | Hält sich an die Regeln des Teams für Secrets und Zugriffe, spielt Routine-Patches ein und meldet alles, was nach einem Sicherheitsproblem aussieht, sofort. | Verwaltet Zugriffe und Secrets der eigenen Services nach dem Prinzip minimaler Rechte, patcht Schwachstellen nach ihrem Schweregrad und behebt die Befunde aus Sicherheitsscans. | Entwirft Netzwerkgrenzen, Identitäts- und Secrets-Management für die gesamte Plattform, bereitet Nachweise für Sicherheitsprüfungen durch Kunden vor und leitet die Reaktion auf Sicherheitsvorfälle. | Verantwortet gemeinsam mit der Führungsebene die Sicherheitslage der Plattform, setzt die Kontrollen um, die Compliance verlangt (zum Beispiel SOC 2 oder ISO 27001), und macht den sicheren Weg für jedes Team zum einfachsten. |
| Developer Enablement und Zusammenarbeit | Beantwortet Fragen von Entwicklern zu Umgebungen und Pipelines, dokumentiert die eigenen Fixes und bittet früh um Review. | Schreibt klare Anleitungen für häufige Aufgaben, unterstützt Entwickler im Pairing beim Deployen und Debuggen ihrer Services und arbeitet neue Teammitglieder in die Infrastruktur ein. | Baut Self-Service-Tooling, mit dem Teams Services und Umgebungen ohne Ticket anlegen können, begleitet andere DevOps Engineers im Mentoring und wirkt beim Recruiting mit. | Gestaltet die Plattform als internes Produkt mit den Entwicklern als Nutzern, entscheidet, was die Teams verantworten und was das Plattformteam, und entwickelt die nächsten Senior Engineers. |
Scrolle die Tabelle seitwärts, um alle Level zu sehen.
Als CSV herunterladen Lässt sich in Excel, Google Sheets oder Numbers öffnen.
Junior DevOps Engineer: Was erwartet wird
Nimmt klar umrissene Änderungen an Infrastruktur und Pipelines mit Review vor und lernt, wie die Produktion läuft. Einzelne Änderungen an bestehendem Infrastrukturcode und bestehenden Pipelines, geplant und geprüft von einer erfahreneren Person.
- Infrastructure as Code
- Ändert bestehenden Infrastrukturcode nach den vorhandenen Mustern, prüft den geplanten Diff vor dem Anwenden und ändert die Produktion nie von Hand, ohne vorher zu fragen.
- Build- und Delivery-Pipelines
- Repariert kaputte Pipeline-Schritte, ergänzt bestehende Pipelines um einfache Jobs und erklärt Entwicklern, warum ihr Build fehlgeschlagen ist.
- Zuverlässigkeit und Incident-Response
- Begleitet die Rufbereitschaft im Shadowing, folgt bei bekannten Alerts den Runbooks und eskaliert schnell mit den Informationen, die die nächste Person braucht.
- Monitoring und Observability
- Ergänzt Dashboards und Alerts nach vorhandenen Beispielen und prüft zuerst Logs und Metriken, wenn etwas falsch aussieht.
- Sicherheit und Zugriffe
- Hält sich an die Regeln des Teams für Secrets und Zugriffe, spielt Routine-Patches ein und meldet alles, was nach einem Sicherheitsproblem aussieht, sofort.
- Developer Enablement und Zusammenarbeit
- Beantwortet Fragen von Entwicklern zu Umgebungen und Pipelines, dokumentiert die eigenen Fixes und bittet früh um Review.
DevOps Engineer: Was erwartet wird
Verantwortet Teile der Infrastruktur von Anfang bis Ende und übernimmt einen vollen Anteil an der Rufbereitschaft. Services, Umgebungen oder Pipelines für ein oder zwei Produktteams, vom Design bis zum täglichen Betrieb.
- Infrastructure as Code
- Schreibt wiederverwendbare Infrastrukturmodule für neue Services und Umgebungen, geht sicher mit State und Secrets um und entfernt Ressourcen, die nicht mehr genutzt werden.
- Build- und Delivery-Pipelines
- Baut und pflegt die komplette Pipeline eines Service – Build, Tests, Artefakte, Deployments in jede Umgebung – und verkürzt langsame Schritte, über die sich Entwickler beschweren.
- Zuverlässigkeit und Incident-Response
- Übernimmt einen vollen Anteil an der Rufbereitschaft, löst die meisten Incidents im eigenen Bereich ohne Hilfe, schreibt Runbooks für das, was behoben wurde, und testet Backups, indem sie tatsächlich wiederhergestellt werden.
- Monitoring und Observability
- Richtet Logging, Metriken und Alerts für neue Services ein, stimmt Alerts so ab, dass jeder Page eine Handlung erfordert, und hilft Entwicklern, in den Daten zu finden, was sie brauchen.
- Sicherheit und Zugriffe
- Verwaltet Zugriffe und Secrets der eigenen Services nach dem Prinzip minimaler Rechte, patcht Schwachstellen nach ihrem Schweregrad und behebt die Befunde aus Sicherheitsscans.
- Developer Enablement und Zusammenarbeit
- Schreibt klare Anleitungen für häufige Aufgaben, unterstützt Entwickler im Pairing beim Deployen und Debuggen ihrer Services und arbeitet neue Teammitglieder in die Infrastruktur ein.
Senior DevOps Engineer: Was erwartet wird
Entwirft und leitet Infrastrukturprojekte, von denen mehrere Teams abhängen, und hebt die Latte für Zuverlässigkeit. Gemeinsame Infrastruktur, die der Großteil des Engineerings nutzt, und Projekte wie Migrationen, die jedes Team betreffen.
- Infrastructure as Code
- Entwirft den Aufbau von Infrastrukturcode und Umgebungen des Unternehmens, leitet Änderungen wie Netzwerk- oder Cluster-Upgrades mit einem getesteten Rollback-Plan und macht die Cloud-Kosten pro Team sichtbar.
- Build- und Delivery-Pipelines
- Entwirft gemeinsame Pipeline-Vorlagen, die jedes Team nutzt, führt sicherere Release-Methoden wie Canary- oder Blue-Green-Deployments ein und verfolgt Deployment-Frequenz und Fehlerquote.
- Zuverlässigkeit und Incident-Response
- Leitet die Reaktion auf größere Incidents, führt Post-Mortems ohne Schuldzuweisung durch, verfolgt die Folgemaßnahmen bis zum Abschluss und plant Kapazität und Failover für kritische Systeme.
- Monitoring und Observability
- Entwirft den Observability-Ansatz für die wichtigsten Systeme des Unternehmens, definiert die Health-Signale, an denen Teams gemessen werden, und reduziert Alert-Lärm über Teams hinweg.
- Sicherheit und Zugriffe
- Entwirft Netzwerkgrenzen, Identitäts- und Secrets-Management für die gesamte Plattform, bereitet Nachweise für Sicherheitsprüfungen durch Kunden vor und leitet die Reaktion auf Sicherheitsvorfälle.
- Developer Enablement und Zusammenarbeit
- Baut Self-Service-Tooling, mit dem Teams Services und Umgebungen ohne Ticket anlegen können, begleitet andere DevOps Engineers im Mentoring und wirkt beim Recruiting mit.
Staff DevOps Engineer: Was erwartet wird
Gibt die Richtung der Plattform des Unternehmens vor und steht für ihre Zuverlässigkeit, Sicherheit und Kosten ein. Die gesamte Produktionsplattform, ihre mehrjährige Ausrichtung und ihr Budget, über alle Engineering-Teams hinweg.
- Infrastructure as Code
- Wählt die Kernbausteine und Anbieter der Plattform für die nächsten Jahre, setzt die Standards, denen die Infrastruktur jedes Teams folgt, und verantwortet das Infrastrukturbudget gemeinsam mit der Führungsebene.
- Build- und Delivery-Pipelines
- Definiert, wie das ganze Unternehmen Software ausliefert, vom Branching bis zum Rollback, und beseitigt die Engpässe, die die Auslieferung in allen Teams bremsen.
- Zuverlässigkeit und Incident-Response
- Legt Zuverlässigkeitsziele mit Produkt und Führungsebene fest, gestaltet Rufbereitschaft und Incident-Prozess für das gesamte Engineering und plant für Katastrophen wie den Ausfall einer Region oder eines Anbieters.
- Monitoring und Observability
- Wählt das Observability-Tooling des Unternehmens und sein Kostenmodell und sorgt dafür, dass die Führungsebene den Zustand der Plattform sehen kann, ohne einen Engineer fragen zu müssen.
- Sicherheit und Zugriffe
- Verantwortet gemeinsam mit der Führungsebene die Sicherheitslage der Plattform, setzt die Kontrollen um, die Compliance verlangt (zum Beispiel SOC 2 oder ISO 27001), und macht den sicheren Weg für jedes Team zum einfachsten.
- Developer Enablement und Zusammenarbeit
- Gestaltet die Plattform als internes Produkt mit den Entwicklern als Nutzern, entscheidet, was die Teams verantworten und was das Plattformteam, und entwickelt die nächsten Senior Engineers.
So passt du diese Karriereleiter an
Nenne euren Stack in den Erwartungen
Allgemeine Formulierungen wie „Infrastrukturcode“ oder „Pipelines“ finden leicht Zustimmung und sind schwer zu bewerten. Ersetze sie durch eure echten Tools und Praktiken, damit ein Junior Engineer genau weiß, was er oder sie zuerst lernen soll.
Führe das Staff-Level erst später ein
Mit ein bis drei DevOps Engineers reichen meist Junior-, Mid- und Senior-Level. Füge Staff hinzu, wenn jemand tatsächlich die Plattformrichtung vorgibt und ihr Budget für das gesamte Engineering verantwortet – nicht als Titel für die erfahrenste Person in einem kleinen Team.
Schreib eure Regeln zur Rufbereitschaft in die Karriereleiter
Leg fest, ab welchem Level Menschen in die Rotation einsteigen, wann sie Incidents leiten und wie Rufbereitschaft vergütet wird. Unausgesprochene Erwartungen an die Rufbereitschaft gehören zu den häufigsten Gründen, warum Infrastruktur-Engineers ausbrennen und gehen.
Gleiche die Level mit deiner Karriereleiter für Software Engineers ab
Ordne jedes DevOps-Level dem Software-Engineer-Level mit demselben Verantwortungsbereich und Gehalt zu. Plattformarbeit ist Engineering-Arbeit, und wenn beide Karriereleitern aufeinander abgestimmt sind, werden Wechsel zwischen Produkt- und Plattformteams unkompliziert.
FAQ
Fragen zu dieser Karriereleiter
Was ist der Unterschied zwischen DevOps Engineer, SRE und Platform Engineer?
Streng genommen ist DevOps eine Arbeitsweise und kein Jobtitel; in der Praxis beschreiben die Titel in Unternehmen mit 20 bis 200 Mitarbeitenden meist denselben Job mit anderem Schwerpunkt: SREs konzentrieren sich auf Zuverlässigkeitsziele – typischerweise SLOs und Error Budgets – und auf Incidents, Platform Engineers auf Self-Service-Tools für Entwickler und DevOps Engineers auf Pipelines und Infrastruktur. Eine Karriereleiter deckt meist alle drei ab; passe die Formulierungen der Kompetenzen an, statt getrennte Karriereleitern anzulegen.
Wann braucht ein Startup seinen ersten DevOps Engineer?
Meist dann, wenn Entwickler einen spürbaren Teil ihrer Woche mit Deployments, Umgebungen und Produktionsproblemen statt mit Features verbringen oder wenn Kunden anfangen, nach Verfügbarkeitszusagen und Sicherheitsprüfungen zu fragen. In vielen Unternehmen passiert das bei etwa 15 bis 30 Engineers.
Sollte Rufbereitschaft bei der Beförderung eines DevOps Engineers zählen?
Ja, aber zähl, was Menschen lernen und verbessern, nicht wie viele Pages sie beantwortet haben. Einen größeren Incident gut zu leiten, Post-Mortems zu schreiben, deren Maßnahmen umgesetzt werden, und Alert-Lärm zu reduzieren, sind klare Belege für das nächste Level. Oft Bereitschaft zu haben ist es nicht.
Spielen Cloud-Zertifizierungen für das Level eines DevOps Engineers eine Rolle?
Sie können jemandem helfen, eine Plattform zu lernen, sollten aber kein Level entscheiden. Bewerte anhand der Kompetenzmatrix, was die Person in eurer Umgebung gebaut und betrieben hat. Ein Zertifikat ohne diese Belege zeigt nicht das nächste Level; diese Belege ohne Zertifikat schon.
Wie viele Level braucht eine Karriereleiter für DevOps Engineers?
Drei oder vier, weil Infrastrukturteams in Unternehmen dieser Größe klein sind. Diese Vorlage nutzt vier – Junior, DevOps Engineer, Senior und Staff – und passt gut zu einer Karriereleiter für Software Engineers mit fünf Leveln, bei der die Staff-Level aufeinander abgestimmt sind.
Baue diese Karriereleiter in LadderKit – kostenlos
Richte ihre Level und Skills für dein Team ein, bewerte Personen in Check-ins daran und triff Beförderungsentscheidungen nach einheitlichem Maßstab.
Kostenloser Plan · Keine Kreditkarte nötig
Ähnliche Vorlagen
Engineering
QA Engineer
Vier Level vom Junior QA bis zum Lead QA Engineer und sechs Kompetenzen – vom Testdesign bis zu Qualitätspraktiken.
- 4 Level
- 6 Kompetenzen
Engineering
Engineering Manager
Vier Level vom Engineering Manager bis zum VP of Engineering in sechs Führungskompetenzen.
- 4 Level
- 6 Kompetenzen