DevOps Engineer
Sie führen die Deploys nicht mehr aus. Sie entwerfen die Systeme, die sichere Deploys automatisch, beobachtbar und wiederherstellbar machen. Infrastruktur wird zur Spezifikation, und die Agenten brauchen auch Infrastruktur, denn sie liefern jetzt Code aus.
Die Arbeit
Sie verantworten die Laufzeit: Deployment, Observability, Skalierung, Zuverlässigkeit, Sicherheit auf Plattformebene. In einer KI-nativen Organisation verantworten Sie zusätzlich ein neues Substrat, nämlich die Infrastruktur, die Agenten für ihre Arbeit nutzen, und Sie sind dafür rechenschaftspflichtig, sie sicher, schnell und wiederherstellbar zu halten.
Im Alltag tun Sie folgendes:
- Deployment-Muster spezifizieren. Canary-Rollouts, Feature-Flags, Traffic-Shaping, Rollback-Auslöser. Der Agent setzt um, Sie entwerfen die Richtlinie.
- Observability entwerfen, bevor die Arbeit fertig ist. Telemetrie, Dashboards, Alarme, Fehlerbudgets gehören zur Spezifikation jedes Features, statt nach Incidents nachgerüstet zu werden.
- Das Agent-Laufzeitsubstrat verantworten. Wo Agenten laufen, welche Credentials sie halten, was sie berühren dürfen, was nicht. Die Plattform, die Agenten zum Ausliefern von Code nutzen, ist nun ein eigenes Produktivsystem.
- Risikoabgestufte Deploy-Gates entwerfen. Umkehrbare Änderungen laufen über reine Agentenprüfung, unumkehrbare (Schema, Secrets, Abrechnungsinfrastruktur) erfordern menschliche Freigabe. Sie setzen die Regeln und justieren sie.
- Incidents untersuchen. Weniger Zeilen-Logs lesen, mehr fragen: welche Annahme im Workflow oder in der Spezifikation hat diesen Ausfall erzeugt? Die Behebung liegt meist vorgelagert.
- Die Deployment-Pipeline pflegen. CI/CD, Build-Infrastruktur, Umgebungsmanagement, aber Sie schreiben weniger davon per Hand und reviewen mehr agent-produzierten Infrastructure-as-Code.
- Kapazitäts- und Kostenplanung betreiben. Compute, Tokens, Observability-Storage. KI-native Organisationen haben ein anderes Kostenprofil; Sie verantworten die Sichtbarkeit darauf.
- Engineers in Produktionsdisziplin coachen. Was Telemetrie braucht, was Flags braucht, was Runbooks braucht. Der Agent produziert, der Engineer spezifiziert, Sie setzen den Standard.
Wie Erfolg aussieht
Konkrete Ergebnisse auf dieser Ebene:
- Deployment-Kadenz. Deploys finden viele Male am Tag statt, sicher. Die mittlere Zeit zwischen Incidents ist hoch und tendiert nach oben.
- Wiederherstellungsgeschwindigkeit. Die mittlere Zeit zur Wiederherstellung ist kurz und tendiert nach unten. Incidents lösen sich durch dokumentierte Muster, nicht durch Heldentaten.
- Kostendisziplin. Compute-Kosten pro ausgeliefertem Feature werden verfolgt. Token-Ausgaben pro Workflow sind sichtbar. Kosten pro Ergebnis verbessern sich.
- Observability-Abdeckung. Jedes Produktionssystem hat Telemetrie, Fehlerbudgets und einen aktionierbaren Alarmpfad. Sie entdecken Features in Produktion nicht durch Überraschung.
- Gesundheit der Agent-Laufzeit. Agenten haben verlässlichen Zugang zu den Diensten, die sie brauchen, mit auditierten Credentials und Rate Limiting, das sowohl Ausfälle als auch Missbrauch verhindert.
Was nicht als Erfolg zählt: geschlossene Tickets, gestartete Infrastrukturprojekte, gebaute Dashboards, die niemand anschaut.
Was diese Arbeit interessant macht
Der interessante Teil ist nicht das Betreiben der Infrastruktur. Es ist das Entwerfen von Systemen, die Unsicherheit souverän handhaben, und nun gibt es mehr Unsicherheit zu handhaben als je zuvor.
Die Agent-Laufzeit ist wirklich neues Gebiet. KI-native Organisationen brauchen Infrastruktur, die Menschen noch nicht gebaut haben: Agent-Credentials, Agent-Rate-Limiting, Agent-Kontextlieferung, Agent-Observability. Sie entwerfen die Muster, die der Rest der Branche kopieren wird.
Reliability Engineering zählt mehr, nicht weniger. Wenn Agenten ein Vielfaches dessen ausliefern, was Menschen früher ausgeliefert haben, skaliert die Konsequenz eines fehlerhaften Deploys mit dem Durchsatz. Die Disziplin von Canaries, Rollbacks und inkrementellem Rollout wird tragend in einer Weise, in der sie es vorher nicht war.
Sie untersuchen faszinierende Ausfälle. Ein Agent hat Code ausgeliefert, der alle Tests bestanden hat, in Produktion fehlschlug, innerhalb von Minuten zurückgerollt wurde, und Sie fragen, warum die Test-Suite es übersehen hat. Die Antwort ist selten einfach. Die diagnostische Arbeit ist befriedigend.
Cost Engineering wird interessant. Token-Ausgaben pro Ergebnis, Compute-Kosten pro Feature, Observability-Kosten pro Signal. Das Optimierungsproblem ist neu und die Hebel sind nicht offensichtlich. Menschen, die Kostenmodellierung vor KI mochten, finden hier eine reichere Version davon.
Sie sitzen zwischen Engineering und Vertrauen. Sicherheit, Governance, Compliance: alle brauchen Infrastruktur zur Durchsetzung. Sie entwerfen die Durchsetzung, und das Vertrauen, das die Organisation extern verdient, hängt von dem ab, was Sie bauen.
Ihre Arbeit verstärkt sich. Ein gutes Deploy-Muster wird von jedem Agenten und jedem Engineer im Unternehmen genutzt. Ein guter Observability-Standard wird auf jedes Feature angewendet. Der Hebel ist real.
Was unter Umständen nicht reizt. Weniger praktische Konfiguration, mehr Spezifikation und Review. Weniger nächtliche Incidents (wenn Sie Ihren Job machen). Für manche DevOps Engineers war das Adrenalin der Incident-Reaktion Teil dessen, warum sie die Arbeit mochten. Wenn Sie das vermissen werden, wird die neue Rolle ruhiger wirken. Sie verantworten zudem Systeme, deren Fehlermodi Sie nicht vollständig vorhersagen können (die Agenten), was für Engineers, die deterministische Infrastruktur mochten, unbequem sein kann.
Wer in dieser Rolle gedeiht
Die wichtigsten Eignungen auf T3 sind systemisches Denken und Fehlermodus-Eignungen, also andere als reine Ausführungsstärken.
Sie denken in Fehlermodi. Bei jedem System, dem Sie begegnen, fragen Sie: „Wie scheitert das, und wie sieht dieser Ausfall für den Nutzer aus?" Die Disziplin ist operativ, nicht paranoid.
Sie kommen mit probabilistischen Systemen zurecht. Agenten sind nicht deterministisch. Infrastruktur, die sie unterstützt, muss das akkommodieren. Engineers, die jedes System durchgängig vorhersagbar brauchen, haben Mühe; Engineers, die mit statistischen Garantien arbeiten können, gedeihen.
Sie halten Widersprüche, ohne sie zu flachen. Geschwindigkeit gegen Sicherheit. Abdeckung gegen Kosten. Autonomie gegen Aufsicht. Gute Infrastrukturentscheidungen navigieren diese Spannungen, sie kollabieren sie nicht.
Sie schreiben klar unter Druck. Incidents sind, wann Dokumentation am meisten zählt und wann niemand Zeit zum Schreiben hat. Menschen, die am Tag nach einem Incident ein klares Post-Mortem schreiben können, produzieren die Artefakte, die sich verstärken.
Sie kümmern sich um Observability so sehr wie um Funktionalität. Ein Feature ohne Telemetrie ist ein Feature, das Sie nicht betreiben können. Engineers, die Observability als optional behandeln, bauen keine produktionsreifen Systeme.
Sie können mit benachbarten Spezialisten kollaborieren. Sicherheit, Compliance, Finanzen, Anwendungs-Engineering: DevOps-Arbeit berührt sie alle. Engineers, die über diese Grenzen hinweg übersetzen können, sind jene, deren Arbeit sich ausbreitet.
Weniger essenziell als zuvor: Tool-Konfigurationen auswendig kennen, Infrastructure-as-Code per Hand schreiben, tiefes Wissen über die Eigenheiten eines bestimmten Cloud-Anbieters. Die Agenten übernehmen das. Ihr Wert liegt im Entwerfen und im Urteil, nicht im Konfigurations-Auswendiglernen.
Fähigkeiten, die Sie entwickeln sollten
Die Eignungen beschreiben die Disposition. Die folgenden Fähigkeiten bauen Sie aktiv auf.
Design von Deployment-Mustern. Canaries, Rollbacks, Feature-Flags, Traffic-Shaping als Richtlinie spezifizieren, nicht als ad-hoc-Konfiguration. Wie üben: Für das nächste Feature, das Ihr Team ausliefert, die Deploy-Spec schreiben, bevor Code geschrieben wird. Was ist das Canary-Kriterium? Was löst automatisches Rollback aus? Was ist die manuelle Übersteuerung?
Observability-Spezifikation. Definieren, was gemessen wird, was alarmiert, und was die erwartete Reaktion ist, bevor das Feature existiert. Wie üben: Für jedes Feature, das Sie berühren, fragen: „Was ist die Metrik, die uns sagt, dass das kaputt ist?" Wenn die Antwort „wir werden es aus Nutzerbeschwerden erfahren" lautet, ist die Spec nicht fertig.
Incident-Root-Cause-Analyse auf Workflow-Ebene. Diagnostizieren, ob ein Ausfall im Code, im Deploy, im Workflow, in der Spezifikation oder im Agent-Kontext liegt. Wie üben: Strukturiertes Post-Mortem nach jedem Incident führen. Sich zwingen, die Annahme zu benennen, die gebrochen ist. Wenn Sie das nicht können, ist die Analyse nicht fertig.
Agent-Laufzeit-Engineering. Das Substrat entwerfen, auf dem Agenten laufen: Credentials, Rate Limits, Kontextlieferung, Observability der Agentenaktionen. Wie üben: Einen Agent-Workflow in Ihrer Organisation auswählen und die Laufzeit dokumentieren, von der er abhängt. Fehlermodi identifizieren. Steuerungen entwerfen.
Engineering risikoabgestufter Gates. Umkehrbare von unumkehrbaren Operationen unterscheiden und passende Validierung zuweisen. Wie üben: Für jede Art von Operation, die Ihre Plattform unterstützt, in eine Risikostufe einsortieren. Jede begründen. Mit jemandem argumentieren, der widerspricht.
Cost Engineering. Token-Ausgaben, Compute-Kosten und Observability-Kosten als erstklassige Engineering-Daten lesen. Wie üben: Ein Kosten-Dashboard für einen Workflow bauen. Die größten Posten aufspüren. Eine davon optimieren. Das Muster dokumentieren.
Funktionsübergreifende Übersetzung. Runbooks und Richtlinien schreiben, die für Engineers, Finanzen, Recht und Sicherheit gleichzeitig funktionieren. Wie üben: Eine Deploy-Richtlinie entwerfen. Sie einer Person aus jeder dieser Funktionen zeigen. Wo sie verwirrt sind, muss das Dokument umgeschrieben werden.
Wählen Sie eine Fähigkeit. Üben Sie sie zwei Wochen an echten Systemen. Die Verdichtung beginnt sofort.
Wie sich das von der alten DevOps-Rolle unterscheidet
| Alter DevOps / SRE (vor KI) | DevOps Engineer (KI-nativ) |
|---|---|
| Schreibt Infrastructure-as-Code per Hand | Spezifiziert Infrastrukturrichtlinie; der Agent setzt die Konfiguration um |
| Verbringt erhebliche Zeit mit Konfigurationsdrift und Toolchain-Pflege | Verbringt mehr Zeit mit Design, weniger mit Konfiguration |
| Verantwortet die menschliche Deployment-Pipeline | Verantwortet sowohl die menschliche als auch die Agent-Deployment-Pipeline |
| Incident-Reaktion ist reaktives Feuerlöschen | Incident-Reaktion umfasst strukturierte Root-Cause-Analyse auf Workflow-Ebene |
| Observability wird nachträglich an Features gebolzt, nachdem sie ausgeliefert sind | Observability wird vor dem Ausliefern spezifiziert |
| Cost Engineering bedeutet nur Compute | Cost Engineering umfasst Compute, Tokens, Observability und Ergebnisse |
| Die besten Engineers kennen die meisten Tools | Die besten Engineers entwerfen die klarsten Richtlinien |
Die Rolle ist kein umbenannter SRE. Sie absorbiert neue Verantwortung (Agent-Laufzeit, Kosten pro Ergebnis), die in der alten Version nicht existierte.
Welche Rollenentwicklungsmuster wirken
- Elevation (primär). Von praktischer Konfiguration zu Richtlinien-Design und Validierung. Wert wandert von Tool-Wissen zu Systemurteil.
- Emergenz (sekundär). Agent-Laufzeit-Engineering, Verfolgung von Kosten pro Ergebnis und Agent-Observability sind tatsächlich neue Verantwortungen, die durch das KI-native Betriebsmodell entstehen.
- Konvergenz (teilweise). Grenzen zu Sicherheit, Platform Engineering und Finanzen verschwimmen, da Infrastruktur die Durchsetzungsschicht für viele funktionsübergreifende Richtlinien wird.
Spezialisierung und Absorption wirken nicht wesentlich: die Rolle weitet sich im Umfang, statt sich zu verengen, und fügt neue Verantwortungen hinzu, statt zu verschwinden.
Verwandte Rollen im Katalog
Quellen und weiterführende Literatur
- Patel, N. (2026). From Tasks to Roles: How Agentic AI Reconfigures Occupational Structures.
- Google SRE (2024 bis 2025). Site Reliability Engineering principles, evolved.
- Aus diesem Rahmenwerk: Zuverlässigkeit entwickeln und KI-Ausführungsstandards.
← Zurück zu Rollen · Rollenentwicklungsmuster · Referenzrahmenwerk · Zuverlässigkeit entwickeln · KI-Ausführungsstandards