DevOps-Ingenieur Interviewfragen & Antworten

Beispielantwort

Unser primärer Datenbankcluster ist während der Stoßzeiten ausgefallen, weil unser Monitoring ein Speicherplatzproblem nicht erkannt hat. Das Failover selbst hat funktioniert, aber das Replikat war 30 Sekunden im Rückstand, was bei einigen Nutzern zu Datenkonsistenzproblemen geführt hat. Ich habe die Incident Response geleitet: das Problem in 10 Minuten isoliert, das betroffene Nutzersegment gemeinsam mit dem Engineering-Team in 20 Minuten identifiziert und innerhalb von 45 Minuten eine Kundenkommunikation rausgeschickt. Die Gesamtausfallzeit betrug 8 Minuten. Im Post-mortem habe ich drei Maßnahmen umgesetzt: Speicherplatz-Monitoring mit Alerts bei 80 % Auslastung, ein Runbook für Datenbank-Failover-Szenarien und wöchentliche Chaos-Engineering-Tests für unsere Failover-Mechanismen. Außerdem sind wir für kritische Tabellen auf synchrone Replikation umgestiegen. In den folgenden 12 Monaten gab es keine ungeplanten Datenbankausfälle mehr.

Beispielantwort

Das Entwicklungsteam deployete manuell per SSH und wehrte sich gegen automatisierte Deployments, weil man 'die Kontrolle behalten' wollte. Statt die Änderung zu erzwingen, habe ich mit ihrem Schmerzpunkt angesetzt. Ich habe gemessen, dass manuelle Deployments im Schnitt 45 Minuten dauerten, eine Fehlerquote von 15 % hatten und regelmäßig freitags um 17 Uhr stattfanden. Ich habe eine CI/CD-Pipeline gebaut, die genau ihre manuellen Schritte nachbildete, sie 2 Wochen parallel betrieben und gezeigt, dass automatisierte Deployments 3 Minuten dauerten bei einer Fehlerquote von 1 %. Den skeptischsten Entwickler habe ich das erste automatisierte Produktions-Deployment selbst durchführen lassen. Als es reibungslos lief, wurde er zum größten Befürworter der Pipeline. Innerhalb eines Monats deployete das Team 3-mal täglich statt einmal pro Woche. Der Schlüssel war, den Wechsel sicher erscheinen zu lassen, statt Compliance zu erzwingen.

Beispielantwort

Ich habe unsere AWS-Ausgaben analysiert und festgestellt, dass wir monatlich $28K für Ressourcen zahlten, die rund um die Uhr liefen, aber nur während der Geschäftszeiten gebraucht wurden (Entwicklungsumgebungen, Staging-Cluster, Batch-Verarbeitung). Ich habe ein automatisiertes Scheduling-System mit AWS Lambda und CloudWatch Events implementiert, das Nicht-Produktionsumgebungen über Nacht und am Wochenende auf null herunterfährt. Außerdem habe ich Produktions-Instanzen anhand von 3 Monaten CloudWatch-Metriken richtig dimensioniert. Wir betrieben m5.2xlarge-Instanzen, die nie mehr als 30 % CPU auslasteten. Der Wechsel zu m5.large mit Autoscaling sparte weitere $8K monatlich. Selten abgerufene S3-Daten habe ich nach Glacier verschoben und so $3K monatlich eingespart. Gesamtersparnis: $18K monatlich ($216K jährlich) ohne Leistungseinbußen. Ich habe ein monatliches Cost-Review-Dashboard eingerichtet, das zur Standardpraxis wurde.

Beispielantwort

Entwickler verbrachten durchschnittlich 90 Minuten damit, ihre lokale Entwicklungsumgebung einzurichten, und Konfigurationsabweichungen verursachten wöchentlich 'funktioniert bei mir'-Bugs. Ich habe den gesamten Entwicklungsstack mit Docker Compose containerisiert: Datenbank, Message Queue, Cache und alle Microservices. Ich habe einen einzigen 'make dev'-Befehl geschrieben, der die neuesten Images zieht, die Datenbank befüllt und alle Services startet. Die Einrichtungszeit sank von 90 Minuten auf 5 Minuten. Zusätzlich habe ich ein Pre-Commit-Hook-System gebaut, das lokal Linting, Type-Checking und Unit-Tests ausführt und so 80 % der CI-Fehler vor dem Push abfängt. Die Bewertungen der Entwicklerzufriedenheit für 'Tooling und Infrastruktur' stiegen von 2,8 auf 4,3 von 5. Die zentrale Erkenntnis: Entwicklerproduktivität ist ein Infrastrukturproblem.

Beispielantwort

VMs virtualisieren Hardware. Jede VM betreibt ihren eigenen OS-Kernel, verwaltet durch einen Hypervisor. Container virtualisieren das Betriebssystem: Sie teilen sich den Host-Kernel und isolieren auf Prozessebene mittels Namespaces und cgroups. Container sind leichter (MB statt GB), starten schneller (Sekunden statt Minuten) und lassen sich dichter auf einem Host betreiben. Ich wähle Container für Microservices, zustandslose Anwendungen und alles, das schnelles Skalieren erfordert. VMs wähle ich, wenn ich vollständige OS-Isolierung brauche (mandantenfähige Umgebungen mit strengen Sicherheitsanforderungen), verschiedene Betriebssysteme auf demselben Host betreiben muss oder Software ausführe, die Kernel-Modifikationen benötigt. In der Praxis sind die meisten modernen Workloads containerisiert. Legacy-Anwendungen, bestimmte Compliance-Anforderungen (PCI-DSS-Umgebungen mit vorgeschriebener VM-Isolation) und Windows-Workloads passen jedoch weiterhin besser zu VMs.

Beispielantwort

Ich würde sie in Schichten aufbauen. Der Inner Loop (pro Service): Jeder Microservice hat eine eigene Pipeline, die bei Commits in sein Verzeichnis ausgelöst wird. Sie führt Linting, Unit-Tests und den Build eines Container-Images mit einem inhaltsadressierbaren Tag (Git-SHA) durch, pusht in eine Registry und deployed in eine Entwicklungsumgebung. Die Integrationsschicht: Nachdem ein Service seine eigenen Tests bestanden hat, laufen Integrationstests in einer gemeinsamen Staging-Umgebung mit allen Services. Ich würde Contract Testing (Pact) einsetzen, um Kompatibilitätsprobleme zwischen Services früh zu erkennen, ohne alle Services laufen lassen zu müssen. Die Deployment-Schicht: Ich würde GitOps mit ArgoCD verwenden. Ein Merge in den Deploy-Branch aktualisiert ein Manifest-Repository, und ArgoCD synchronisiert den Cluster-Zustand. Rollbacks sind ein Git-Revert. Zur Absicherung: Canary-Deployments mit automatischem Rollback basierend auf Fehlerraten-Schwellenwerten, Deployment-Fenster mit automatischen Sperren bei hohem Traffic und in den ersten Monaten ein manuelles Freigabe-Gate für Produktion, bis ausreichend Vertrauen aufgebaut ist.

Beispielantwort

Infrastructure as Code bedeutet, die Infrastruktur (Server, Netzwerke, Datenbanken, Load Balancer) in deklarativen Konfigurationsdateien zu definieren, statt durch Klicken in Konsolen oder Ad-hoc-Skripte. Tools wie Terraform, CloudFormation und Pulumi ermöglichen das. Drei Gründe, warum es wichtig ist. Erstens Reproduzierbarkeit: Ich kann eine identische Umgebung in jeder Region hochfahren, indem ich denselben Code ausführe. Kein 'Wir vermuten, dass Staging mit Produktion übereinstimmt'. Zweitens Versionskontrolle: Infrastrukturänderungen durchlaufen denselben Code-Review, Genehmigungsprozess und Prüfpfad wie Anwendungscode. Ich kann nachvollziehen, wer was wann und warum geändert hat, und bei Bedarf zurückrollen. Drittens Automatisierung: Infrastrukturänderungen können von CI/CD-Pipelines getestet, validiert und angewendet werden, wodurch manuelle Fehler entfallen. In der Praxis verwende ich Terraform mit Remote-State in S3, State-Locking mit DynamoDB und Module für wiederverwendbare Komponenten. Jede Infrastrukturänderung geht über einen Pull Request mit terraform-plan-Ausgabe zur Überprüfung.

Beispielantwort

Ich folge den drei Säulen: Metriken, Logs und Traces. Metriken (Prometheus und Grafana) geben mir einen aggregierten Überblick über den Systemzustand: CPU, Arbeitsspeicher, Request-Rate, Fehlerrate, Latenz-Perzentile. Ich setze Alerts auf Symptome (hohe Fehlerrate, erhöhte Latenz), nicht auf Ursachen (hohe CPU-Last), weil Symptome anzeigen, dass Nutzer betroffen sind. Logs (ELK oder Loki) liefern detaillierten Ereigniskontext zur Fehlersuche. Ich setze strukturiertes Logging (JSON) mit Correlation-IDs durch, damit ich eine Anfrage über Services hinweg verfolgen kann. Traces (Jaeger oder Tempo) zeigen mir den vollständigen Anfragepfad durch das System und offenbaren, welcher Service langsam ist und warum. Jenseits der drei Säulen baue ich Business-Level-Dashboards: Bestellungen pro Minute, Anmeldungen pro Stunde, Zahlungserfolgsrate. Das ist das Erste, was ich bei einem Incident prüfe, weil es die Frage beantwortet 'Sind Nutzer betroffen?', bevor ich in Infrastrukturmetriken eintauche. Außerdem implementiere ich SLOs mit Error-Budgets. Das wandelt Monitoring von 'Ist irgendetwas kaputt?' in 'Erfüllen wir unsere Zuverlässigkeitszusagen?'

Beispielantwort

Kurzfristig: Ich würde den Kubernetes Cluster Autoscaler aktivieren, um Nodes automatisch hinzuzufügen, wenn Pods nicht eingeplant werden können. Ich würde prüfen, ob der Node-Pool genug Spielraum zum Skalieren hat und ob die Scaling-Richtlinien des Autoscalers sinnvoll sind (schnell hoch, langsam runter). Außerdem würde ich prüfen, ob bestehende Ressourcen überdimensioniert sind. Es ist üblich, dass Pods das Doppelte der tatsächlich benötigten Ressourcen anfordern. Eine Anpassung der Ressourcenanforderungen auf der Basis tatsächlicher Nutzungsmetriken könnte 30 bis 40 % Kapazität freischalten, ohne Nodes hinzuzufügen. Mittelfristig: Ich würde den Horizontal Pod Autoscaler (HPA) für alle Workloads mit sinnvollen CPU- und Arbeitsspeicher-Zielen implementieren und für Workloads mit unvorhersehbarem Ressourcenbedarf den Vertical Pod Autoscaler (VPA) in Betracht ziehen. Außerdem würde ich Batch-Workloads auf Spot- bzw. Preemptible-Instanzen verlagern. Langfristig: Ich würde Traffic-Muster analysieren und prädiktives Skalieren einführen. Wenn Stoßzeiten zwischen 9 und 11 Uhr liegen, skaliere ich 15 Minuten vor der Nachfragespitze hoch, statt auf die Nachfrage zu reagieren. Zudem würde ich prüfen, ob bestimmte Workloads auf Serverless (Lambda oder Cloud Run) verlagert werden sollten, um den Kapazitätsplanungsaufwand ganz zu eliminieren.

Beispielantwort

Zuerst würde ich das unmittelbare Problem beheben: die Konfigurationsänderung zurückrollen und den Betrieb wiederherstellen. Dann würde ich ein schuldzuweisungsfreies Post-mortem durchführen. Der Fokus liegt auf dem System, das dies ermöglicht hat, nicht auf der Person, die die Änderung gemacht hat. Meine Präventivmaßnahmen: Erstens durchlaufen alle Konfigurationsänderungen dieselbe CI/CD-Pipeline wie Code. Pull Request, Review, automatisierte Validierung, schrittweises Rollout. Kein direktes Pushen in die Produktionskonfiguration. Zweitens: Konfigurationsvalidierung in der Pipeline implementieren, Schema-Prüfung, Probelauf und Integrationstests in einer Staging-Umgebung. Drittens: Schrittweises Rollout für Konfigurationsänderungen. Die Änderung zuerst auf 5 % der Instanzen anwenden, 10 Minuten lang die Fehlerraten beobachten, dann auf 25 %, 50 % und 100 % fortfahren. Viertens: Automatische Rollback-Trigger. Wenn die Fehlerrate innerhalb von 5 Minuten nach einer Konfigurationsänderung das 2-Fache des Ausgangswerts übersteigt, wird automatisch zurückgerollt. Das Ziel ist, den sicheren Weg zum einfachen Weg zu machen. Es sollte schwieriger sein, Konfiguration direkt zu pushen, als die Pipeline zu durchlaufen.

Beispielantwort

Ich würde niemals einen Big-Bang-Rewrite machen. Das scheitert zuverlässig. Stattdessen würde ich das Strangler-Fig-Muster verwenden: Services schrittweise extrahieren, während der Monolith weiterhin Traffic bedient. Schritt 1: Service-Grenzen mithilfe von Domain-Driven Design identifizieren. Ich würde die Domänen, Dateneigentümerschaft und Abhängigkeiten des Monolithen abbilden und mit dem am wenigsten gekoppelten, wertvollsten Service beginnen. Schritt 2: Den neuen Service parallel zum Monolithen aufbauen und Traffic über ein API-Gateway dorthin routen. Monolith und neuer Service teilen sich anfangs die Datenbank. Schritt 3: Sobald der Service stabil ist, seine Daten in eine eigene Datenbank migrieren und die gemeinsame Datenbankabhängigkeit entfernen. Schritt 4: Für den nächsten Service wiederholen. Für einen mittelgroßen Monolithen würde ich eine vollständige Migration von 12 bis 18 Monaten einplanen. Grundprinzipien: Jeder extrahierte Service muss unabhängig deploybar und testbar sein, das System muss im hybriden Zustand funktionieren (einige Services extrahiert, andere noch im Monolithen) und ich würde umfassendes Monitoring an der Grenze zwischen alt und neu einrichten, um Integrationsprobleme früh zu erkennen.

Beispielantwort

Ich würde auf Basis von vier Faktoren evaluieren, nicht nach persönlicher Präferenz. Erstens vorhandenes Know-how: Was kennt das Team bereits? Cloud-Lernkurven sind steil, und die Produktivitätskosten eines Wechsels sind real. Wenn das Team 3 Jahre AWS-Erfahrung hat, muss die neue Plattform einen überzeugenden Vorteil bieten, der den Einarbeitungsaufwand rechtfertigt. Zweitens spezifische Service-Anforderungen: Benötigt das Projekt einen Service, den eine Cloud deutlich besser anbietet? GCP für ML (Vertex AI), Azure für Enterprise-Integration (Active Directory), AWS für den breitesten Service-Katalog. Drittens Preismodell: Ich würde die Kosten anhand des Kalkulators jeder Cloud für unser spezifisches Workload-Muster schätzen. Reserved Instances, Spot-Preise und Egress-Kosten variieren erheblich. Viertens organisatorischer Kontext: Rahmenverträge, Compliance-Anforderungen und bestehende Infrastruktur. Wenn das Unternehmen bereits ein AWS-Enterprise-Agreement hat, bringt GCP zusätzliche Beschaffungskomplexität mit sich. Ich würde eine Empfehlung mit einer klaren Entscheidungsmatrix vorlegen, nicht nur mein Bauchgefühl.