Interviewfragen für DevOps Engineers, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Lies dann die ausführliche Antwort und such dir zwei oder drei Punkte aus, die du ergänzt, mit einem Beispiel aus einem System, das du betrieben hast. Interviewer wollen hören, wie du über Ausfälle denkst, nicht eine Liste von Werkzeugen.

Ein Hinweis wie „hängt vom Anbieter ab“ oder „hängt vom Release ab“ markiert ein Detail, das sich mit einem Anbieter oder einem Release ändern kann. Prüf die aktuelle Dokumentation, bevor du es zitierst.

Was ein DevOps Engineer können muss

• LinuxIn 39 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Die Basis der meisten Server und Container: Prozesse, Dateien, Rechte, systemd, Netzwerkwerkzeuge und Logs. und NetzwerkeIn 10 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).DNS, TCP/IP, Load Balancer, TLS-Zertifikate, Firewalls und private Netze in der Cloud.: Prozesse, Berechtigungen, Logs, DNS, Load Balancer und TLS-Zertifikate (was eine Verbindung sicher macht).
• Container: gut gebaute DockerIn 38 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Kleine, sichere Images, die jedes Mal gleich gebaut werden; Layer, Caching und Betrieb als normaler Benutzer kennen.-Images und KubernetesIn 48 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Workloads ausrollen, skalieren und debuggen: Deployments, Services, Ingress, Ressourcenlimits, Probes und Rollbacks., um sie zu betreiben, zu skalieren und zu heilen.
• CI/CDIn 73 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Pipelines, die jede Änderung bauen, testen, scannen und ausrollen, mit sicheren Rollouts und schnellem Weg zurück.: CI (Continuous Integration) baut und testet jede Änderung; CD (Continuous Delivery oder Deployment) liefert sie sicher aus. Werkzeuge wie GitLab CIIn 10 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Pipelines direkt neben dem Code: Stufen, Runner, Umgebungen und Freigaben für Produktion., GitHub ActionsIn 5 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Workflows für Build, Test und Deployment, wiederverwendbare Actions, Umgang mit Secrets und kurzlebige Cloud-Logins. oder JenkinsIn 19 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).In großen Firmen noch verbreitet: Pipelines als Code, Shared Libraries, Agents und ein sicherer Betrieb..
• Infrastructure as Code: TerraformIn 27 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Infrastructure as Code: Module, Remote State mit Locking, geprüfte Pläne vor dem Apply, keine Änderungen von Hand. für Cloud-Ressourcen, AnsibleIn 27 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Server mit Playbooks und Rollen jedes Mal gleich konfigurieren; wissen, wann Terraform besser passt. für die Einrichtung von Servern, alles über GitIn 38 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Branching, Reviews und Historie; alles (Code, Pipelines, Infrastruktur) ändert sich über einen Pull Request. und Review geändert.
• Eine Cloud: AWSIn 23 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Kerndienste (Rechenleistung, Speicher, Netzwerk, IAM) und Entwurf für Ausfälle über Availability Zones hinweg. je nach Anbieter, AzureIn 27 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Verbreitet in europäischen Firmen: Identitäten, Netzwerk, AKS und Richtlinien; oft mit Microsoft 365 verbunden. je nach Anbieter oder Google CloudIn 12 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Google Cloud: Projekte, IAM, GKE und Netzwerk; in Anzeigen seltener als AWS und Azure. je nach Anbieter: Konten, Identitäten, Netze und Design für Ausfälle. je nach Anbieter
• Monitoring: Metriken, Logs und Traces, zum Beispiel mit PrometheusIn 15 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Metriken und Alarme (mit Grafana für Dashboards): was man misst, und Alarme, auf die Menschen reagieren können. und Grafana, und Alarme, auf die Menschen reagieren können.
• Code: Skripte in BashIn 17 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Kurze, sichere Skripte für Verbindungsarbeit; wissen, wann aus einem Skript ein richtiges Werkzeug werden sollte. und kleine Werkzeuge in PythonIn 31 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Automatisierung und kleine Werkzeuge: Cloud-APIs, Datenbereinigung, Prüfungen. Lesbarer, getesteter Code. oder GoIn 0 % der Anzeigen für DevOps Engineer gefragt (Stand 05.11.2026).Die Sprache vieler Cloud-native-Werkzeuge und Kubernetes-Operatoren; ein Plus in Plattform-Teams. je nach Version.
• Sicherheit: Least Privilege (jede Person und jeder Service bekommt nur den Zugriff, den er braucht), Secrets außerhalb des Codes, gepatchte Images.

CI/CD-Pipelines und Releases

Entwirf eine CI/CD-Pipeline für einen Webservice, vom Commit bis zur Produktion.

Worauf sie achten: dass du in Stufen mit schneller Rückmeldung denkst, einmal baust, sicher auslieferst und immer einen Weg zurück hast.

Kurze Antwort: „Jede Änderung durchläuft zuerst die schnellen Prüfungen: Build, Unit-Tests, Linting und einen Security-Scan. Die Pipeline baut ein Container-Image, versieht es mit dem Commit als Tag, und genau dieses Image geht nach Test, Staging und Produktion. Jede Stufe nach oben verlangt, dass ihre Prüfungen bestanden sind. In der Produktion gibt es einen schrittweisen Rollout mit Health Checks, und eine fehlgeschlagene Prüfung rollt automatisch zurück.“

Die ausführliche Antwort in sieben Schritten:

1. Bei jeder Änderung: Build, Unit-Tests, eine Stilprüfung und ein Scan der Abhängigkeiten auf bekannte Sicherheitslücken. Ziel: Rückmeldung innerhalb von zehn Minuten, damit die Leute darauf warten, statt sie zu ignorieren.
2. Einmal bauen. Ein Container-Image erstellen, mit dem Commit taggen und in einer Registry ablegen. Für die Produktion nie neu bauen: Was getestet wurde, wird ausgeliefert.
3. Testumgebung. Das Image automatisch deployen und die API- und End-to-End-Tests laufen lassen. Änderungen an der Datenbank laufen als Migrationen (geskriptete, versionierte Änderungen) und werden hier zuerst getestet.
4. Staging. Eine Kopie der Produktion im Aufbau, nicht in den Daten. Smoke-Tests (kurze Prüfungen, ob das Wichtigste funktioniert) laufen lassen und bei großen Änderungen einen Lasttest.
5. Produktion, schrittweise. Ein Rolling, Blue-Green oder Canary Release (erklärt in der nächsten Frage), überwacht von Health Checks und Fehlerraten.
6. Der Weg zurück. Ein automatischer Rollback, wenn die Prüfungen fehlschlagen, und ein manueller Rollback in einem Schritt für alles andere. Datenbankänderungen sind so geschrieben, dass die alte Version noch mit dem neuen Schema funktioniert.
7. Regeln und Nachweise. Wer die Produktion freigeben darf, Secrets aus einem Vault statt in der Pipeline gespeichert und ein Protokoll, was wann ausgeliefert wurde, damit sich ein Incident auf eine Änderung zurückführen lässt.

Schwache Antwort: „Jenkins baut es und kopiert es auf den Server.“ Keine Stufen, keine genannten Tests, kein Rollback.

Nachfrage: „Die Pipeline dauert vierzig Minuten, und die Entwickler beschweren sich.“ Jede Stufe messen, Abhängigkeiten und Image-Layer cachen, Tests parallel laufen lassen und langsame Tests in eine spätere Stufe verlegen, die nicht jede Änderung blockiert.

Blue-Green, Canary oder Rolling: Wie wählst du eine Deployment-Strategie, und wie rollst du zurück?

Worauf sie achten: dass du die Zielkonflikte kennst und den Rollback vor dem Release planst.

Kurze Antwort: „Ein Rolling Release ersetzt Server nach und nach; es ist einfach und in Kubernetes der Standard. Blue-Green lässt die neue Version neben der alten laufen und schaltet den Traffic in einem Schritt um, der Rollback ist also ein Zurückschalten. Canary schickt zuerst einen kleinen Teil der Nutzer auf die neue Version und erweitert ihn, solange die Zahlen gut bleiben. Ich wähle nach Risiko, Kosten und danach, wie gut unser Monitoring ist.“

Die ausführliche Antwort: Blue-Green braucht eine Zeit lang doppelte Kapazität, dafür ist der Rollback sofort möglich. Canary braucht gute Metriken, denn es geht darum, die neue Version mit echtem Traffic mit der alten zu vergleichen; das lässt sich mit einem Werkzeug automatisieren, das den Rollout stoppt, wenn die Fehler steigen. Rolling ist günstig, mischt aber eine Zeit lang zwei Versionen, also müssen beide mit derselben Datenbank funktionieren. Feature-Flags (Schalter im Code) erlauben es, Code ausgeschaltet auszuliefern und später einzuschalten; das trennt Deployment und Release. Der Plan für den Rollback ist in jedem Fall derselbe: wissen, zu welcher Version es zurückgeht, und sicherstellen, dass die Daten noch mit ihr funktionieren.

Schwache Antwort: „Wir deployen nachts, wenn niemand es nutzt.“ Nachfrage: „Die neue Version hat die Datenbank geändert. Kannst du trotzdem zurückrollen?“ Nur, wenn die Änderung additiv war (neue Spalten, nichts entfernt); alte Teile werden in einem späteren Release entfernt.

Wie hältst du Builds schnell und reproduzierbar?

Worauf sie achten: praktische Erfahrung mit langsamen, instabilen Pipelines.

Kurze Antwort: „Versionen von Werkzeugen und Abhängigkeiten festschreiben, in sauberen Containern bauen, cachen, was sicher zu cachen ist, und Images klein halten. Derselbe Commit muss immer dasselbe Ergebnis liefern.“

Die ausführliche Antwort: Reproduzierbar heißt, ein Build aus dem Commit vom letzten Monat ergibt heute dasselbe Image. Dafür braucht es festgeschriebene Versionen, ein Lock-File für die Abhängigkeiten und Basis-Images mit fester Version statt „latest“. Für die Geschwindigkeit: die Schritte im Image so ordnen, dass die Teile, die sich am seltensten ändern, zuerst kommen und gecacht werden, Jobs parallel laufen lassen und in einem großen Repository nur bauen, was sich geändert hat. Verfolge die Laufzeit der Pipeline als Zahl, die das Team sieht.

Schwache Antwort: „Wir kaufen größere Build-Server.“ Nachfrage: „Ein Build läuft auf einem Runner durch und schlägt auf einem anderen fehl.“ Etwas ist nicht festgeschrieben oder nicht sauber: Versionen vergleichen und jedes Mal in einem frischen Container bauen.

Infrastructure as Code und Secrets

Was ist Infrastructure as Code, und wie arbeitest du sicher mit dem Terraform-State?

Worauf sie achten: dass du Infrastruktur wie Software behandelst und weißt, wo Terraform dir schaden kann.

Kurze Antwort: „Infrastructure as Code heißt, Server, Netze und Cloud-Dienste werden in Dateien beschrieben, in Git gehalten und per Review geändert; so lassen sie sich neu aufbauen, und jede Änderung ist festgehalten. Terraform führt eine State-Datei, die die Dateien den echten Ressourcen zuordnet. Ich halte den State in einem gemeinsamen, gesperrten, gesicherten Speicher, teile ihn nach Umgebung auf und prüfe jeden Plan, bevor er angewendet wird.“

Die ausführliche Antwort: Die State-Datei ist das Gedächtnis von Terraform darüber, was existiert. Ändern ihn zwei Leute gleichzeitig oder geht er verloren, versucht Terraform vielleicht, die falschen Dinge anzulegen oder zu löschen. Deshalb: Remote State mit Sperre, Verschlüsselung und Versionierung; getrennter State pro Umgebung und pro großem Teil, damit ein Fehler einen kleinen Blast Radius hat (den Bereich, den ein Ausfall erreichen kann); Module für wiederkehrende Muster; der Plan im Pull Request angezeigt und von der Pipeline angewendet, nicht vom Laptop aus; und eine regelmäßige Prüfung auf Drift, also Änderungen, die jemand von Hand am Code vorbei gemacht hat. je nach Version

Schwache Antwort: „Ich lasse Terraform von meinem Laptop laufen, wenn etwas geändert werden muss.“ Nachfrage: „Jemand hat in der Konsole von Hand eine Security Group geändert.“ Die Drift-Prüfung zeigt es; entweder die Änderung per Review in den Code übernehmen oder Terraform sie zurücksetzen lassen, und den Zugriff von Hand schließen.

Terraform oder Ansible: Wofür ist was gedacht?

Worauf sie achten: dass du Werkzeuge aus einem Grund wählst.

Kurze Antwort: „Terraform legt Cloud-Ressourcen an und ändert sie: Netze, Datenbanken, Cluster. Ansible konfiguriert, was auf Servern läuft: Pakete, Dateien, Dienste. Mit Containern und Managed Services wandert vieles, was Ansible erledigt hat, in den Build des Images.“

Die ausführliche Antwort: Terraform beschreibt den Endzustand und ermittelt die Schritte; Ansible führt Schritte der Reihe nach aus, so geschrieben, dass sie gefahrlos zweimal laufen können. Beide können einen Teil der Arbeit des anderen, aber sie ohne Regel zu mischen, führt zu zwei Werkzeugen, die sich um eine Ressource streiten. Ich schreibe auf, welches Werkzeug was verantwortet. Wo Server aus Images neu gebaut statt vor Ort geändert werden, gibt es ohnehin weniger zu konfigurieren.

Schwache Antwort: „Die sind gleich, ich nehme irgendeins.“ Nachfrage: „Fünfzig alte Server müssen heute Nacht gepatcht werden.“ Ansible, in Gruppen, mit einer Prüfung nach jeder Gruppe und einem Stopp bei einem Fehler.

Wie gehst du mit Secrets wie Passwörtern und API-Keys um?

Worauf sie achten: dass Secrets nie in Code, Images oder Logs landen und dass du für ein Leck planst.

Kurze Antwort: „Secrets liegen in einem Secrets Manager oder Vault, nicht in Git, Images oder Pipeline-Dateien. Services holen sie beim Start mit ihrer eigenen Identität, der Zugriff ist so klein wie nötig, jedes Lesen wird geloggt, und Secrets werden rotiert, also nach Plan und nach einem Leck sofort geändert.“

Die ausführliche Antwort: Vermeide langlebige Secrets, wo es geht, ganz: Die Pipeline meldet sich mit kurzlebigen Zugangsdaten bei der Cloud an, und Services nutzen die Identitäten der Cloud selbst. Scanne jeden Commit auf Secrets und behandle ein Secret, das in Git gelandet ist, als geleakt, auch wenn der Commit entfernt wurde: rotiere es. Kubernetes-Secrets sind standardmäßig nur kodiert, nicht verschlüsselt; schalte also die Verschlüsselung ein oder nutze einen externen Speicher. je nach Anbieter

Schwache Antwort: „Wir halten sie in einer Environment-Datei im Repository, aber das ist privat.“ Nachfrage: „Ein Key wurde vor einer Stunde in ein öffentliches Repository gepusht.“ Ihn sofort widerrufen, einen neuen ausstellen, die Logs auf Nutzung des alten Keys prüfen und dann herausfinden, wie es passiert ist.

Container und Kubernetes

Erklär in einfachen Worten, wie eine Anwendung auf Kubernetes läuft.

Worauf sie achten: ein klares Bild der wichtigsten Teile, keine auswendig gelernten Namen.

Kurze Antwort: „Die App ist in ein Container-Image verpackt. Ein Pod ist ein oder mehrere Container, die zusammen laufen. Ein Deployment sagt, wie viele Pods welcher Version laufen sollen, und ersetzt sie, wenn sie ausfallen oder eine neue Version kommt. Ein Service gibt den Pods eine feste Adresse, und ein Ingress lässt Traffic von außen herein. Kubernetes prüft ständig, ob das, was läuft, dem entspricht, was verlangt wurde.“

Die ausführliche Antwort: Ergänze die Teile, die es in der Produktion tragfähig machen: Probes, die Prüfungen, mit denen Kubernetes sieht, ob ein Pod lebt und bereit für Traffic ist; Requests und Limits, wie viel Prozessor und Speicher ein Pod reserviert und nutzen darf; Config Maps und Secrets für Einstellungen; Namespaces, um Teams zu trennen; und Autoscaling, das Pods hinzufügt, wenn die Last steigt. Managed Services (EKS, AKS, GKE) betreiben den Steuerungsteil für dich. je nach Anbieter

Schwache Antwort: eine Liste aller Objekttypen ohne Vorstellung, wie sie zusammenpassen. Nachfrage: „Warum läuft ein Pod, bekommt aber keinen Traffic?“ Seine Readiness Probe schlägt fehl, oder die Labels des Service passen nicht zum Pod.

Ein Pod startet immer wieder neu. Wie findest du heraus, warum?

Worauf sie achten: ein ruhiges, geordnetes Vorgehen bei der Fehlersuche.

Kurze Antwort: „Ich schaue zuerst auf die Events und den Status des Pods, dann auf die Logs des letzten abgestürzten Laufs. Die üblichen Ursachen sind ein Absturz beim Start, eine falsche Einstellung oder ein falsches Secret, eine fehlgeschlagene Liveness Probe oder ein Pod, dem der Speicher ausgeht und der deshalb beendet wird. Dann prüfe ich, was sich geändert hat: ein neues Image, eine neue Einstellung oder eine Abhängigkeit, die ausgefallen ist.“

Die ausführliche Antwort: Der Status sagt dir, welche Art von Fehler es ist: zu wenig Speicher, ein Image, das sich nicht laden lässt, oder die App, die mit einem Fehler endet. Die Logs des vorigen Laufs zeigen meist den Fehler. Ist die Liveness Probe zu streng, beendet Kubernetes eine langsame, aber gesunde App; prüfe also ihr Timing. Ist es der Speicher, vergleiche das Limit mit der echten Nutzung über die Zeit. Begann es nach einem Release, roll zuerst zurück und such danach den Fehler, denn die Nutzer gehen vor.

Schwache Antwort: „Ich lösche den Pod und schaue, ob er wiederkommt.“ Nachfrage: „Nur einer von drei Pods startet neu.“ Schau, was anders ist: sein Node, seine Daten oder die Anfragen, die ihn erreichen.

Wie legst du Resource Requests und Limits fest, und wie skalierst du?

Worauf sie achten: dass du Einstellungen auf Messungen stützt und die Kostenseite verstehst.

Kurze Antwort: „Ich setze Requests nach der gemessenen normalen Nutzung, damit der Scheduler Pods gut platziert, und ein Speicherlimit, um den Node zu schützen. Ich skaliere Pods nach einem Signal, das der Last folgt, etwa Prozessorlast oder Länge der Queue, und lasse den Cluster Nodes hinzufügen, wenn Pods nicht mehr passen.“

Die ausführliche Antwort: Zu hohe Requests verschwenden Geld; zu niedrige, und Pods werden auf volle Nodes gequetscht. Speicherlimits verhindern, dass ein Pod mit Speicherleck einen Node lahmlegt; Prozessorlimits können Apps bremsen, deshalb lassen viele Teams sie weg. Skaliere nach dem, was den Service tatsächlich begrenzt: bei einem Worker nach der Länge seiner Queue statt nach der Prozessorlast. Teste die Skalierung mit einem Lasttest, bevor du sie brauchst, und setz ein Maximum, damit ein Fehler die Rechnung nicht grenzenlos hochtreiben kann.

Schwache Antwort: „Wir geben jedem Pod reichlich, sicherheitshalber.“ Nachfrage: „Die Kosten haben sich nach dem Umzug auf Kubernetes verdoppelt.“ Requests mit der echten Nutzung vergleichen, die Größen anpassen und in ruhigen Zeiten herunterskalieren.

Monitoring, SLOs und Incidents

Was überwachst du, und was sollte nachts jemanden wecken?

Worauf sie achten: dass du bei dem alarmierst, was Nutzer spüren, nicht bei jeder Zahl.

Kurze Antwort: „Ich sammle Metriken, Logs und Traces für jeden Service. Ich wecke jemanden nur bei Symptomen, die Nutzer spüren, etwa Fehler, langsame Antworten oder ein ausgefallener Service, und nur, wenn jemand sofort handeln muss. Alles andere kommt auf ein Dashboard oder in ein Ticket für die Arbeitszeit.“

Die ausführliche Antwort: Monitoring sagt dir, dass etwas nicht stimmt; Observability heißt, du hast genug Daten (Metriken, Logs, Traces), um herauszufinden, warum, auch bei einem Problem, mit dem du nie gerechnet hast. Ein einfacher Start sind die vier Golden Signals: Traffic, Fehler, Latenz (wie lange Antworten dauern) und Sättigung (wie voll das System ist). Jeder Alarm, der jemanden weckt, braucht einen klaren Verantwortlichen und ein Runbook, eine kurze Anleitung für die ersten Schritte. Zu viele Alarme bringen den Leuten bei, sie zu ignorieren; entferne oder korrigiere also jeden Alarm, der auslöst, ohne dass gehandelt werden muss.

Schwache Antwort: „Wir alarmieren, wenn die Prozessorlast über achtzig Prozent liegt.“ Das kann für die Nutzer völlig in Ordnung sein. Nachfrage: „Wer letzte Woche Rufbereitschaft hatte, wurde dreißigmal geweckt.“ Jeden Alarm durchgehen, die lauten löschen oder nachjustieren und die Ursachen der echten beheben.

Was sind SLOs und Error Budgets, und wie verändern sie Entscheidungen?

Worauf sie achten: dass du „zuverlässig“ in eine Zahl übersetzen kannst, der das Business zustimmt.

Kurze Antwort: „Ein SLI ist ein Maß für das, was Nutzer spüren, etwa der Anteil der Anfragen, die schnell genug erfolgreich sind. Ein SLO ist das Ziel dafür, vereinbart mit dem Business. Das Error Budget ist der Ausfall, den das Ziel erlaubt. Solange Budget übrig ist, liefert das Team aus; ist es aufgebraucht, hat Zuverlässigkeit Vorrang.“

Die ausführliche Antwort: SLO heißt Service Level Objective; SLI Service Level Indicator. Ein Ziel von hundert Prozent ist falsch: Es stoppt jede Änderung, und Nutzer merken keinen Unterschied zu einem etwas niedrigeren. Wähle pro Service ein paar SLOs aus Sicht der Nutzer, miss sie über einen rollierenden Monat und alarmiere, wenn das Budget zu schnell verbraucht wird, statt bei jedem Fehler. Das Budget macht aus Streit eine Regel: Produkt und Entwicklung vereinbaren vorher, was passiert, wenn es aufgebraucht ist.

Schwache Antwort: „Unser SLA sind fünf Neunen.“ Ein SLA ist ein Vertrag mit Kunden, und das Ziel beruht nicht auf den Nutzern. Nachfrage: „Das Budget ist aufgebraucht, aber das Business will ein großes Release.“ Der vereinbarten Regel folgen oder die Ausnahme offen machen, mit zusätzlicher Sicherheit wie einem Canary Release.

Erzähl, wie du mit einem Incident umgehst und was danach passiert.

Worauf sie achten: ruhige Ordnung unter Druck, Kommunikation und Lernen ohne Schuldzuweisung.

Kurze Antwort: „Zuerst den Schaden für die Nutzer begrenzen, dann die Ursache finden. Eine Person leitet, eine arbeitet an der Lösung, eine hält alle auf dem Laufenden. Oft ist ein Rollback die schnellste Lösung. Danach schreiben wir ein Blameless Postmortem: was passiert ist, warum, was geholfen hat und die Maßnahmen, die eine Wiederholung verhindern.“

Die ausführliche Antwort in sechs Schritten:

1. Ausrufen. Klar sagen, dass es einen Incident gibt, wie schwer er ist und wer ihn leitet. Einen Kanal dafür öffnen.
2. Den Schaden begrenzen. Die letzte Änderung zurückrollen, eine Funktion abschalten, Traffic umleiten oder Kapazität ergänzen. Die eigentliche Ursache kann warten, bis die Nutzer sicher sind.
3. Alle auf dem Laufenden halten. Kurze Updates zu festen Zeiten für Support und Kunden, in einfachen Worten: was betroffen ist, was wir tun, wann das nächste Update kommt.
4. Die Ursache finden. Schauen, was sich geändert hat (Releases, Einstellungen, Traffic, Anbieter), dann Metriken, Logs und Traces. Nebenbei eine Zeitleiste schreiben.
5. Abschließen. Mit den Messgrößen, die Nutzer spüren, bestätigen, dass der Service wieder läuft, dann den Incident beenden.
6. Lernen. Ein Blameless Postmortem innerhalb weniger Tage: die Zeitleiste, die Ursachen, was es schlimmer oder besser gemacht hat, und Maßnahmen mit Verantwortlichen und Terminen. Blameless heißt: fragen, wie das System es zulassen konnte, nicht, wen man bestraft, damit die Leute die ganze Geschichte erzählen.

Schwache Antwort: „Ich logge mich auf den Servern ein und fange an, Dinge zu reparieren.“ Keine Leitung, keine Updates, kein Rollback, kein Lernen.

Nachfrage: „Dieselbe Art von Incident ist dieses Jahr dreimal passiert.“ Die Maßnahmen aus den Postmortems wurden nicht umgesetzt oder reichten nicht: Verfolge sie wie Produktarbeit und such nach der gemeinsamen Ursache.

Ein Linux-Server ist langsam. Wie findest du heraus, warum?

Worauf sie achten: eine Methode, von außen nach innen, keine Vermutungen.

Kurze Antwort: „Ich prüfe die vier Ressourcen der Reihe nach: Prozessor, Speicher, Festplatte und Netzwerk. Welche ist voll, und welcher Prozess nutzt sie? Dann die Logs auf Fehler und was sich kürzlich geändert hat.“

Die ausführliche Antwort: Load und Prozessorlast zeigen, ob die Maschine beschäftigt ist oder wartet. Speicher: Swappt sie, lagert also Speicher auf die Festplatte aus, was alles langsam macht? Festplatte: Ist sie voll, oder stauen sich Lese- und Schreibzugriffe? Netzwerk: Fehler, verlorene Pakete, langsames DNS? Dann der Prozess selbst: Hängt er und wartet auf eine Datenbank oder einen anderen Service? Vergleiche in den Metriken mit derselben Zeit in der Vorwoche. Auf einer Container-Plattform gelten dieselben Fragen pro Container.

Schwache Antwort: „Ich starte ihn neu.“ Das hilft vielleicht für den Moment, versteckt aber die Ursache. Nachfrage: „Die Prozessorlast ist niedrig, aber alles ist langsam.“ Such nach Wartezeiten: Festplatte, Netzwerk, Sperren oder eine langsame Abhängigkeit.

Cloud, Sicherheit und Kosten

Wie richtest du Zugriffe und Netze in einem Cloud-Konto sicher ein?

Worauf sie achten: Least Privilege, Trennung und keine Abkürzungen, die bleiben.

Kurze Antwort: „Getrennte Konten oder Subscriptions für die Produktion und den Rest, Menschen, die sich über das Identitätssystem der Firma mit Rollen statt mit persönlichen Keys anmelden, Services mit eigenen, engen Rechten, private Netze für Datenbanken und jede Änderung über Code und Review.“

Die ausführliche Antwort: Die Produktion ist nur über Rollen erreichbar, die geloggt werden, mit zusätzlichen Prüfungen für mächtige Aktionen. Nichts Wichtiges hat eine öffentliche Adresse, wenn es nicht sein muss: Datenbanken und interne Services liegen in privaten Netzen, und eingehender Traffic läuft über einen Load Balancer und eine Firewall. Guardrails, Regeln für die ganze Organisation, blockieren Dinge wie öffentliche Storage Buckets. Logs darüber, wer was getan hat, gehen in ein getrenntes, gesperrtes Konto. je nach Anbieter

Schwache Antwort: „Alle im Team haben Admin-Rechte, das geht schneller.“ Nachfrage: „Ein Entwickler braucht Produktionsdaten zum Debuggen.“ Zeitlich begrenzten, geloggten Lesezugriff geben, oder besser eine sichere Kopie ohne personenbezogene Daten.

Wie senkst du Cloud-Kosten, ohne der Zuverlässigkeit zu schaden?

Worauf sie achten: dass du zuerst misst und die wichtigsten Hebel kennst.

Kurze Antwort: „Zuerst die Kosten pro Team und Service mit Tags sichtbar machen. Dann entfernen, was ungenutzt ist, verkleinern, was zu groß ist, in ruhigen Zeiten herunterskalieren und für die gleichmäßige Grundlast Rabatte mit fester Laufzeit nutzen. Jede Änderung prüfe ich gegen die SLOs.“

Die ausführliche Antwort: Die üblichen Gewinne: ungenutzte Testumgebungen nachts abgeschaltet; alte Disks, Snapshots und Logs per Regel gelöscht; Server und Pods nach gemessener Nutzung bemessen; Spot- oder Preemptible-Maschinen, günstige freie Kapazität, die zurückgefordert werden kann, für Arbeit, die sich unterbrechen lässt; Savings Plans oder Reservierungen für die Grundlast; und wenig Datenübertragung zwischen Regionen. Kosten, die den verursachenden Teams gezeigt werden, sinken am schnellsten. je nach Anbieter

Schwache Antwort: „Wir ziehen alles auf den günstigsten Instanztyp um.“ Nachfrage: „Die Finanzabteilung will die Kosten in diesem Quartal um ein Drittel senken.“ Die größten Posten zeigen, die sicheren Einsparungen und was Zuverlässigkeit kosten würde, und das Business entscheiden lassen.

Was bedeutet DevOps für dich, und wie arbeitest du mit Entwicklungsteams zusammen?

Worauf sie achten: dass du DevOps als Arbeitsweise siehst, nicht als eigenes Team, das für andere deployt.

Kurze Antwort: „DevOps heißt, die Leute, die einen Service bauen, helfen auch, ihn zu betreiben, und der Weg in die Produktion ist automatisiert und gemeinsam. Meine Aufgabe ist, den sicheren Weg zum einfachen zu machen: gute Pipelines, Vorlagen und eine Plattform, die Entwickler selbst nutzen können, damit sie nicht auf mich warten.“

Die ausführliche Antwort: Zeichen, dass es funktioniert: Teams deployen selbst viele Male am Tag, Incidents sind selten und kurz, und die Plattform hat Dokumentation und einen klaren Weg, um Hilfe zu bitten. Übliche Messgrößen sind die DORA-Metriken: wie oft ein Team deployt, wie lange eine Änderung bis in die Produktion braucht, wie oft eine Änderung einen Ausfall verursacht und wie schnell der Service wiederhergestellt ist. Ich behandle die Plattform als Produkt: Die Entwickler sind ihre Nutzer, und ich frage sie, was sie bremst.

Schwache Antwort: „Die Entwickler schreiben den Code, und wir deployen ihn.“ Nachfrage: „Ein Team bittet dich immer wieder, für es zu deployen.“ Herausfinden, was es blockiert, das in der Plattform oder der Dokumentation beheben und die ersten paar Releases gemeinsam mit dem Team machen.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon sagt, denn der Interviewer fragt nach dem, was darin steht. Schreib unter jede Stelle zu jedem dieser Punkte eine Zeile, in den Wörtern der Anzeigen:

Bewerte deinen Lebenslauf dann an einem echten Job: Du siehst, welche dieser Punkte der Job verlangt und welche dein Lebenslauf noch nicht belegt.