DevOps Engineer:in

Bewusste Entscheidungen statt Default-Übernahme: deterministische Builds (Lockfiles, Container-Digests, keine latest-Tags), explizite Test-Stufen (Unit, Integration, Smoke, E2E) mit Begründung der Reihenfolge, Deployment-Strategie passend zum Risiko (Rolling, Blue-Green, Canary, Feature-Flag). Bonus: die:der Kandidat:in nennt Entscheidungen, die sie:er heute anders treffen würde. Wer ohne Reflexion alles in Jenkins-Skripten mit shell scripts beschreibt, hat selten ernsthaft abgewogen.

Strukturierte Debug-Methode: Reproduktion, Logs, Metriken, durch Experiment validierte Hypothesen. Ehrlichkeit zur Dauer (ein echter Production-Incident mit Wirkung ist selten in unter 30 Min. geschlossen). Bonus: die:der Kandidat:in nennt die Grundursache und den systemischen Fix (Post-mortem, Runbook, neuer Alarm, Architektur-Anpassung), nicht nur den Hotfix. Antworten wie Ich habe den Cluster neugestartet ohne Diagnose deuten auf schwache Investigationsfähigkeit.

Schrittweises Vorgehen: parallele Systeme mit Traffic-Shifting (1 %, 10 %, 50 %, 100 %), expliziter Rollback-Plan zu jedem Schritt, Validierung auf Daten- oder Funktions-Konsistenz vor jedem Cut-over. Bonus: die:der Kandidat:in nennt einen Fall, in dem die Migration länger gedauert hat als geplant, und was sie:er daraus gelernt hat. Wer eine Big-Bang-Migration ohne Rollback beschreibt, zeigt Risikoblindheit.

Strukturierte Methode: (1) Rollback-Option offenhalten und Stakeholder kommunizieren, (2) Metriken korrelieren (CPU, Memory, Connection-Pool, Network, DB-Latenz, GC-Pausen), (3) verteiltes Tracing einer langsamen Anfrage von Edge bis DB, (4) Pattern identifizieren (Tageszeit, Endpoint, Tenant, Region). Wer sofort auf wird wohl die DB sein springt, ohne zu investigieren, hat einen Bias. Bonus: explizite Erwähnung, parallel ein Post-mortem-Dokument zu starten und einen On-Call-Backup einzubinden.

Zuerst Diagnose: nicht alles gleichzeitig reparieren wollen. Priorisierung nach Risiko und Wirkung (typisch: zuerst zentralisiertes Logging und Basis-Alerting für Sichtbarkeit, dann reproduzierbare Builds und ein erster automatisierter Deploy-Pfad für einen Service, dann Test-Pipeline für die kritischste Geschäftslogik, IaC-Erfassung zuletzt). Abstimmung mit Team und Tech Lead vor jeder Maßnahme. Wer sich direkt in eine vollständige GitOps-Migration mit Service Mesh stürzt, zeigt mangelnden Pragmatismus.

Klärung des fachlichen Bedarfs vor der Diskussion über die Lösung (oft lassen sich Debug-Anforderungen mit besseren Logs, Tracing und Just-in-Time-Zugriff lösen). Alternativvorschläge anbieten: bessere Observability, Read-only-Zugriffe, JIT-Access mit Audit-Trail, ephemerale Debug-Pods in Kubernetes. Antworten wie Klar, gebe ich ihm zeigen Sicherheits-Blindheit ; Antworten wie Niemals, das geht nicht zeigen mangelnde Kollaboration. Die richtige Antwort kombiniert konstruktives Pushback mit konkretem Alternativ-Pfad.

Solides Verständnis der Workload-Typen: Deployment für stateless, austauschbare Pods (Web, API), StatefulSet für stabile Identität und persistente Storage-Bindung (Datenbanken, Queues), DaemonSet für einen Pod pro Node (Log-Forwarder, Network-Plugins). Typische Fallen: PVC-Verlust bei StatefulSet-Skalierung, Reihenfolge-Probleme bei Rolling Updates eines StatefulSets, DaemonSet auf Nodes ohne nötige Resources. Bonus: Erwähnung von PodDisruptionBudgets und Topology Spread Constraints. Wer die drei Typen nicht trennen kann, baut in Produktion Datenverlust-Risiken ein.

Klare Trennung von Logs (strukturiert, mit Trace-ID, zentralisiert in Loki, Elasticsearch oder einem Anbieter), Metriken (RED- oder USE-Methode: Rate, Errors, Duration ; oder Utilization, Saturation, Errors) und verteiltem Tracing (OpenTelemetry, Jaeger, Tempo). Konkrete Tool-Wahl mit Begründung (Prometheus plus Grafana, Datadog, Sentry, Loki). Alarme nur auf actionable Signale, mit SLOs und Error Budget pro Service. Cluster-Ebene: Node-Health, kube-state-metrics, Control-Plane-Latenz. Wer pauschal alles loggen sagt, zeigt fehlende Erfahrung mit Plattformen ab einer gewissen Größe.

Klare Liste: Container-Image-Scanning (Trivy, Grype) auf CVEs und Secrets, signierte Images (Cosign, Notary), Pod Security Standards (Restricted oder Baseline), Network Policies pro Namespace, Secrets über externen Manager (Vault, AWS Secrets Manager, Sealed Secrets), least-privilege RBAC pro ServiceAccount, Ressourcen-Limits gegen Noisy-Neighbor-Effekte. Konkrete Maßnahmen: Admission Controller (OPA Gatekeeper, Kyverno), Audit-Logs aktiv, sichere Egress-Regeln. Bonus: konkrete Erfahrung mit einem Vorfall, der durch eine dieser Maßnahmen verhindert oder eingegrenzt wurde.

Klärung vor dem Vorschlag (Stack der Anwendung, Datenbank-Topologie, aktueller Deploy-Prozess, akzeptable Risiko-Toleranz, Cloud-Anbieter, Compliance-Anforderungen). Kohärente Migrationsstrategie: zunächst Container-isieren ohne Architektur-Änderung, parallele Bereitstellung in Kubernetes neben dem aktuellen System, Traffic-Shifting (1 %, 10 %, 50 %, 100 %) über Load Balancer, Rollback-Pfad pro Schritt. Bonus: explizite Behandlung von Stateful-Komponenten (DB, Sessions, File-Uploads), Observability vor dem Switch, schrittweiser Aufbau der Plattform-Capabilities (Logging, Monitoring, Tracing, Autoscaling) parallel zur Migration. Wer ohne Klärung sofort in den Code springt, zeigt eine Design-Schwäche.

Erkennen, dass RPO und RTO die Strategie diktieren: Multi-AZ als Basis (synchron, RPO nahe 0 für die DB), automatisierte Snapshots der Datenbank alle 15 Min., Point-in-Time-Recovery aktiv, getestete Restore-Prozeduren (nicht nur dokumentiert). Lösungsraum: RDS Multi-AZ oder Aurora, S3 mit Versioning und Cross-Region-Replication für statische Assets, Infrastructure-as-Code für schnelles Neuaufsetzen, regelmäßige DR-Drills. Bonus: explizite Behandlung der Anwendungs-Konsistenz (keine reinen Volume-Snapshots ohne Datenbank-Quiescence), klare Runbooks für den Restore. Wer Backups nimmt, ohne den Restore zu testen, hat keine DR-Strategie.

Strukturierte Methode: (1) Node-Metriken prüfen (CPU-Throttling, Memory-Pressure, Disk-IO, Network-Saturation, kubelet-Health), (2) Pod-Verteilung auf dem Node ansehen (Noisy Neighbor? Ein Pod mit hoher Resource-Nutzung ohne Limits?), (3) kernel-Logs auf dem Node (dmesg, journalctl), (4) Hardware oder zugrundeliegende EC2-Instanz prüfen (Steal Time, EBS-Saturation, Network-Burst-Credits aufgebraucht). Bonus: erkennen, dass intermittierend auf einem Node oft auf einen Resource-Engpass, einen problematischen Pod oder Hardware-Issues hindeutet, und sofort ein Cordon plus Eviction als Mitigation in Betracht ziehen.

Offenheit: Fähigkeit, Code vom persönlichen Ego zu trennen. Bonus: die:der Kandidat:in nennt einen Fall, in dem sie:er durch eine Review tatsächlich umgedacht hat (andere Modul-Struktur, andere Variable, andere Provider-Konfiguration). Wer beschreibt, der:dem Reviewer:in die eigene Logik nur erklärt zu haben, anstatt zuzuhören, zeigt eine Schwäche in der Coachability ; im KMU mit kleinem DevOps-Team ist das ein hartes K.o.-Signal.

Aktive Mentorenhaltung: Pair-Programming auf kritischen Pfaden, gemeinsam erstellte Runbooks, Onboarding zu On-Call mit klarem Eskalations-Pfad, Weitergabe guter Praktiken (Backoff, Idempotenz, sichere Deploys). Wer sagt Ich übernehme das einfach selbst, ist schneller, zeigt eine zentralistische Haltung, die mit dem Skalierungsziel einer Plattform-Funktion kollidiert. Die richtige Antwort beschreibt Enablement, nicht Übernahme.

Realistisches Verständnis der Trade-offs: im KMU mehr Autonomie, ganzes Stack im Zugriff, direkter Produktbezug, aber weniger Spezialisierung, kleinere Inzident-Komplexität, weniger Resources für eigene interne Tools und Migrationen. Bonus: die:der Kandidat:in nennt konkrete Aspekte, die zum aktuellen Karrierezeitpunkt zur KMU-Umgebung passen (will Eigentum eines ganzen Bereichs übernehmen, will näher am Produkt sein). Wer Konzern als langsam und bürokratisch abqualifiziert, ohne die Vorteile zu nennen, zeigt mangelnde Reflexion.