Middle DevOps / SRE — DevOps-Interviewfragen

Ein Pod steckt in CrashLoopBackOff. Nenne mir deine ersten drei Befehle.

Zuerst kubectl describe pod, weil der Events-Abschnitt Fehler beim Image-Pull, fehlgeschlagene Mounts, OOMKilled und Probe-Fehler zeigt — meist schon die halbe Antwort, bevor du auch nur eine Logzeile gelesen hast. Dann kubectl logs --previous, weil der laufende Container erst Sekunden alt sein und noch nichts geloggt haben könnte. Dann der Exit-Code, und wenn es nach OOM riecht, das Memory-Limit gegen den tatsächlichen Verbrauch.

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

Er ordnet deine Konfiguration den realen Ressourcen zu, damit Terraform weiß, was ihm gehört. Gefährlich ist er, weil er maßgeblich ist: Geht er verloren, schlägt Terraform vor, alles neu zu bauen, weil es nichts mehr von diesen Ressourcen weiß. Außerdem enthält er Secrets im Klartext, und zwei gleichzeitige Applies ohne Locking korrumpieren ihn — deshalb sind Remote-Backends mit Locking, Verschlüsselung und Versionierung keine Option, sondern Pflicht.

Was ist ein Error Budget, und wie würdest du es in einer Diskussion einsetzen?

Ein SLI ist das, was du misst, ein SLO ist das Ziel über ein Zeitfenster, und das Error Budget ist die Unzuverlässigkeit, die du dir leisten darfst. Sein Wert liegt nicht in der Metrik, sondern als Verhandlungsinstrument: Es macht aus „wir sollten langsamer machen und die Zuverlässigkeit reparieren" — einer Meinung, die gegen eine Roadmap immer verliert — eine Rechnung, auf die sich beide Seiten vorher geeinigt haben.

Rolling, Blue-Green oder Canary für ein Deployment mit Datenbankmigration?

Rolling braucht kaum Reservekapazität, lässt aber zwei Versionen gleichzeitig laufen, weshalb die Migration abwärtskompatibel sein muss, ob es dir gefällt oder nicht. Blue-Green gibt dir einen sofortigen Rollback und verdoppelt die Infrastruktur, macht die Migration aber eher schwerer als leichter, weil sich beide Umgebungen eine Datenbank teilen. Canary fängt echte Probleme ab, aber nur, wenn die Observability innerhalb des Canary-Fensters etwas bemerkt.

Wie bekommst du ein Secret in eine Anwendung, ohne es ins Repository zu legen?

Über einen externen Store — Vault, den Secret Manager der Cloud —, bei dem sich der Workload über seine Identität authentifiziert und nicht über ein weiteres Secret, denn genau das unterscheidet die Lösung davon, das Problem nur zu verschieben. Injektion zur Laufzeit ist besser als das Einbacken ins Image, weil ein Image überall kopiert und gecacht wird. Rotation ist die Anforderung, die man beim Design gerne wegdenkt und später nicht mehr nachrüsten kann.

Was ist der Unterschied zwischen einer Metric, einem Log und einem Trace?

Eine Metric ist eine Zahl über die Zeit und beantwortet, ob etwas nicht stimmt. Ein Log ist ein Event mit Details und beantwortet, was passiert ist. Ein Trace verfolgt einen Request über Services hinweg und beantwortet, wo die Zeit geblieben ist. Teams investieren meist zu viel in Logs, die am teuersten zu speichern und am wenigsten nützlich sind, um ein Problem zu entdecken, nach dem man noch gar nicht gesucht hat.

Was muss ein Health-Check des Load Balancers eigentlich prüfen?

Genug, um zu wissen, dass die Instanz bedienen kann — nicht mehr. Prüft er eine gemeinsam genutzte Datenbank, entfernt ein einziges Datenbankproblem gleich alle Instanzen auf einmal; prüft er nur den Prozess, kommt weiter Traffic bei einer Instanz an, die nicht antworten kann. Die übliche Antwort ist ein flacher Endpoint, der bestätigt, dass die App läuft und ihre eigenen Abhängigkeiten erreichbar sind — getrennt vom tiefergehenden Readiness-Check.

`df` zeigt freien Speicherplatz, aber Schreibvorgänge scheitern mit „no space left on device". Was ist da los?

Zwei übliche Ursachen. Entweder sind nicht die Bytes, sondern die Inodes ausgegangen — Millionen winziger Dateien —, was df -i sofort zeigt. Oder ein Prozess hält noch eine bereits gelöschte Datei offen, sodass die Blöcke nicht freigegeben werden, während df die Datei schon nicht mehr mitzählt; lsof +L1 findet sie, und ein Neustart des haltenden Prozesses gibt den Speicher frei. Eine dritte Möglichkeit auf ext-Dateisystemen sind die für root reservierten 5 %, an die ein nicht-root-Schreiber nicht herankommt.

Wie richtest du SSH-Zugriff auf eine Serverflotte sicher ein?

Nur Keys — PasswordAuthentication no —, ohne direkten Root-Login, mit einer klaren Einschränkung, wer sich überhaupt anmelden darf, über AllowUsers oder eine Gruppe, und mit einem Bastion-Host davor statt jedem einzeln exponierten Host. Personenbezogene Keys statt einem gemeinsamen Key, weil sich ein gemeinsamer Key nicht für eine einzelne ausscheidende Person widerrufen lässt. Darüber hinaus: Agent-Forwarding vermeiden zugunsten von ProxyJump, command=-Einschränkungen für Automatisierungs-Keys, und sobald die Flotte so groß ist, dass die Key-Verteilung selbst zum Problem wird, eine Certificate Authority.