DevOps-Interviewfragen

Was ist der Unterschied zwischen Continuous Integration, Delivery und Deployment?

Continuous Integration bedeutet, dass jeder Commit gemerged und durch einen automatisierten Build- und Testlauf verifiziert wird, sodass der Branch nie weit von main abdriftet. Continuous Delivery bedeutet, dass jeder erfolgreiche Build ein Artefakt erzeugt, das prinzipiell in Produktion gehen könnte — der finale Push bleibt aber eine menschliche Entscheidung. Continuous Deployment nimmt diese Entscheidung weg: Jeder grüne Build geht automatisch live. Der Unterschied ist im Interview relevant, weil die meisten Teams, die CD für sich beanspruchen, in Wirklichkeit nur Delivery praktizieren.

Wie funktionieren Docker-Layer, und wie hältst du ein Image klein?

Jede Instruktion erzeugt einen Read-only-Layer, und Layer werden gecacht und wiederverwendet, solange sich an allem davor nichts geändert hat — deshalb kopierst du zuerst das Dependency-Manifest und installierst die Abhängigkeiten, bevor du den Quellcode kopierst. Die Größe reduzierst du über Multi-Stage-Builds, die den Compiler zurücklassen, ein schlankes oder distroless Base-Image, sowie das Zusammenfassen von Befehlen, damit temporäre Dateien gar nicht erst in einen Layer gelangen. Eine Datei in einem späteren Layer zu löschen verkleinert das Image nicht, weil der frühere Layer sie weiterhin enthält.

Erkläre den Zusammenhang zwischen Pod, Deployment und Service.

Ein Pod ist die kleinste planbare Einheit — ein oder mehrere Container, die sich einen Network-Namespace und Lifecycle teilen. Ein Deployment verwaltet ein ReplicaSet, das eine deklarierte Anzahl identischer Pods am Laufen hält und Rolling Updates sowie Rollbacks übernimmt. Ein Service gibt dieser sich ständig ändernden Menge von Pods eine stabile virtuelle IP und einen DNS-Namen und lastverteilt über die Pods, die gerade seinem Selector entsprechen — so muss niemand einzelne Pod-IPs im Blick behalten.

Was ist der Unterschied zwischen einer Liveness- und einer Readiness-Probe?

Die Readiness-Probe entscheidet, ob ein Pod Traffic bekommt; schlägt sie fehl, wird der Pod aus den Service-Endpoints entfernt, läuft aber weiter. Die Liveness-Probe entscheidet, ob der Container neu gestartet wird. Beide zu verwechseln ist ein klassischer Auslöser für Ausfälle: Zeigt die Liveness-Probe auf eine Abhängigkeit, lässt eine langsame Datenbank alle Replicas gleichzeitig neu starten und macht aus degradiertem Service einen Totalausfall. Liveness sollte nur prüfen, ob der Prozess hängt, Readiness sollte prüfen, ob gerade bedient werden kann.

Was ist der Terraform State, und warum ist er gefährlich?

Der State ordnet die in der Konfiguration deklarierten Ressourcen den realen Objekten beim Provider zu, damit Terraform weiß, was erstellt, geändert oder gelöscht werden muss. Gefährlich ist er, weil er die Wahrheit darstellt: Geht er verloren, weiß Terraform nicht mehr, dass es deine Infrastruktur besitzt, und versucht sie neu anzulegen. Außerdem enthält er häufig Secrets im Klartext. Deshalb gehört der State in ein Remote-Backend mit Verschlüsselung, Versionierung und Locking, damit nicht zwei Engineers gleichzeitig ein Apply ausführen.

Wann setzt du Terraform ein, wann Ansible?

Terraform ist deklaratives Provisioning: Es erstellt und löscht Infrastruktur und bringt die reale Welt in Einklang mit dem deklarierten Zustand. Ansible ist prozedurales Configuration Management: Es führt geordnete Tasks auf bereits existierenden Maschinen aus. Die saubere Trennung lautet: Terraform für alles mit einem Lebenszyklus in einer Cloud-API, Ansible für das, was innerhalb einer VM passiert. Auf einem Kubernetes-Stack schrumpft die Rolle von Ansible deutlich, weil Container-Images die Maschinenkonfiguration ersetzen.

Was sind SLI, SLO und ein Error Budget?

Ein SLI ist ein gemessener Indikator für die Gesundheit eines Service, etwa der Anteil der Requests, die erfolgreich unter 300 ms beantwortet wurden. Ein SLO ist das Ziel für diesen Indikator über ein Zeitfenster, zum Beispiel 99,9 % über 30 Tage. Das Error Budget ist der erlaubte Fehlbetrag — die 0,1 % der Requests — und macht Zuverlässigkeit zu einer ausgebbaren Ressource: Ist das Budget noch intakt, kannst du schneller shippen; ist es aufgebraucht, werden Features eingefroren und die Zuverlässigkeit repariert. Genau das verhindert, dass „Zuverlässigkeit versus Geschwindigkeit" zur reinen Meinungsdebatte wird.

Was ist der Unterschied zwischen Metrics, Logs und Traces?

Metrics sind günstige numerische Aggregate über die Zeit und beantworten die Frage, ob etwas nicht stimmt — auf sie legst du Alerts. Logs sind diskrete Events mit Detailinformationen und beantworten, was genau in einem Request oder einer Komponente passiert ist. Traces verfolgen einen einzelnen Request über mehrere Services hinweg und beantworten, wo die Zeit in einer verteilten Aufrufkette geblieben ist. Alerts auf Logs zu legen ist teuer und verrauscht; nur anhand von Metrics zu debuggen ist Raten. Du brauchst alle drei, jeweils für das, wofür sie gut sind.

Vergleiche Rolling-, Blue-Green- und Canary-Deployments.

Rolling ersetzt Instanzen schrittweise, braucht kaum zusätzliche Kapazität, aber während des Rollouts bedienen zwei Versionen gleichzeitig Traffic, und ein Rollback ist langsam. Blue-Green betreibt eine komplette zweite Umgebung und schaltet den Traffic auf einmal um — das gibt einen sofortigen Rollback, kostet aber doppelte Kapazität und macht Datenbankmigrationen zu einem harten Problem. Canary schickt einen kleinen Teil des Traffics auf die neue Version und beobachtet die Metrics, bevor weiter ausgerollt wird, was Probleme abfängt, auf die echte Nutzer stoßen — das lohnt sich aber nur mit solider Observability und automatisierter Analyse.

Wie sollten Secrets in einer Pipeline gehandhabt werden?

Secrets gehören niemals ins Repository, in Image-Layer oder in einfache Umgebungsvariablen, die beim Build fest eingebacken werden. Sie kommen aus einem dedizierten Store — Vault, dem Secret Manager der Cloud oder den verschlüsselten Secrets des CI-Anbieters — und werden zur Laufzeit mit möglichst engem Scope und möglichst kurzer Lebensdauer injiziert. Kurzlebige Credentials über OIDC-Föderation sind besser als langlebige Keys, denn das eigentliche Risiko ist nicht der Diebstahl eines Secrets, sondern ein Secret, das jahrelang gültig bleibt.

Ein Pod steckt in CrashLoopBackOff. Beschreibe deine Diagnose.

Ich starte mit kubectl describe pod, um die Events zu sehen — Fehler beim Image-Pull, fehlgeschlagene Mounts, OOMKilled oder eine fehlschlagende Probe tauchen dort auf. Danach kubectl logs mit --previous, weil der aktuelle Container eventuell zu jung ist, um irgendetwas Nützliches geloggt zu haben. Ich prüfe, ob der Exit-Code auf OOM hindeutet, und vergleiche dann das Memory-Limit mit dem tatsächlichen Verbrauch. Startet der Container und stirbt sofort wieder, sind die üblichen Ursachen eine fehlende Config oder ein fehlendes Secret, eine beim Start fehlschlagende Migration, oder eine Liveness-Probe mit zu kurzer initialer Verzögerung.

Was macht ein Postmortem nützlich statt zeremoniell?

Ein nützliches Postmortem ist blameless, sodass Leute beschreiben, was sie tatsächlich getan haben, statt was sich verteidigen lässt, und es konzentriert sich auf die Bedingungen, die einen Fehler zu einem Ausfall werden ließen. Es hält eine präzise Timeline fest, unterscheidet Auslöser von Root Cause und erzeugt eine kleine Zahl von Action Items mit Owner und Datum statt einer Wunschliste. Der Test ist, ob das Dokument einem neuen Engineer ein Jahr später den Ausfall verständlich machen würde — und ob die Follow-ups tatsächlich umgesetzt werden.