Bei DevOps- und SRE-Interviews geht es weniger darum, Tools aufzuzählen, als um Urteilsvermögen unter Druck: Was rollst du zuerst zurück, worauf legst du einen Alert, und was lässt du bewusst bis zum Morgen kaputt? Hier sind die häufigsten Fragen, jeweils mit einer Musterantwort. Junior: Grundlagentheorie, Definitionen und einfache Praxisfälle.
Readiness steuert, ob Traffic an den Pod geschickt wird; Liveness steuert, ob der Container neu gestartet wird. Zeigt die Liveness-Probe auf eine gemeinsam genutzte Abhängigkeit, wird aus einer langsamen Datenbank ein clusterweiter Neustart-Sturm, weil alle Replicas denselben Check im selben Moment nicht bestehen. Ein Readiness-Fehler nimmt dagegen nur einen Pod aus der Rotation, der Rest bedient weiter.
Ein Image ist das unveränderliche Dateisystem samt Metadaten; ein Container ist eine laufende Instanz davon mit einem beschreibbaren Layer obendrauf. Images werden in Layern gebaut und pro Layer gecacht, weshalb die Reihenfolge der Instruktionen im Dockerfile bestimmt, wie lange ein Rebuild dauert — die Installation der Abhängigkeiten vor das Kopieren des Quellcodes zu setzen bedeutet, dass eine Codeänderung diesen Layer nicht invalidiert.
Ein Deployment behandelt Pods als austauschbar und gibt ihnen zufällige Namen; ein StatefulSet gibt stabile Identitäten und stabilen Storage und startet beziehungsweise stoppt sie in fester Reihenfolge. Ein StatefulSet brauchst du, wenn Identität zählt — ein Datenbank-Replica-Set, alles mit einem eigenen Volume pro Instanz. Es dort einzusetzen, wo ein Deployment reichen würde, macht Rollouts ohne jeden Nutzen langsamer.
Der Request ist das, was der Scheduler beim Platzieren des Pods reserviert; das Limit ist die zur Laufzeit durchgesetzte Obergrenze. Kein Request bedeutet, der Scheduler geht von nichts aus und kann einen Node übercommitten; ein zu niedriges Memory-Limit bedeutet, dass der Container bei normaler Last per OOM gekillt wird. CPU-Throttling am Limit ist der leisere Fehler, weil der Pod weiterläuft und einfach nur langsam wird.
Beide injizieren Konfiguration; ein Secret ist für sensible Werte gedacht und wird base64-kodiert in etcd gespeichert — das ist Kodierung, keine Verschlüsselung, solange Encryption at Rest nicht aktiviert ist. Die praktische Regel: Ein Secret hält Werte aus dem Manifest und aus Logs heraus, ist aber kein Vault — für echtes Secret-Management brauchst du einen externen Store.
Checkout, Installation, Build, Tests, dann die Erzeugung eines Artefakts — ein Image oder Paket — und erst danach das Deployment. Die Reihenfolge zählt, weil jede Stufe so früh und so billig wie möglich scheitern soll: Linting vor Tests, Unit-Tests vor Integrationstests. Eine Pipeline, die deployt, bevor sie testet, ist keine Pipeline, sondern ein Deployment-Skript mit ein paar Extraschritten.
Ich fange damit an, was läuft und was es gerade tut: ps oder systemctl status, dann journalctl oder die Logdatei, dann df für die Festplatte und free für den Speicher, weil eine volle Platte und ein erschöpfter Heap beide wie ein Applikationsfehler aussehen. Dann ss oder netstat, um zu sehen, ob der Port überhaupt lauscht. Erst das Log zu lesen statt zu raten ist eine Gewohnheit, die sich auszahlt.
Ein Inode ist der eigentliche Datensatz zu einer Datei — Berechtigungen, Zeitstempel, Zeiger auf die Daten —, und der Dateiname ist nur ein Verzeichniseintrag, der darauf zeigt. Ein Hardlink ist ein zweiter Name für denselben Inode, sodass die Daten erhalten bleiben, bis der letzte Name entfernt wird. Ein Symlink ist eine kleine Datei mit einem Pfad darin, deshalb bricht er, wenn das Ziel verschoben wird, kann aber im Gegensatz zum Hardlink Dateisystemgrenzen überschreiten.
Ein Zombie ist beendet, aber sein Parent hat den Exit-Status noch nicht ausgelesen, deshalb bleibt der Eintrag in der Prozesstabelle stehen — für sich genommen harmlos, ein Bug im Parent, sobald sie sich häufen. Der Load Average ist die Anzahl der Prozesse, die laufen oder warten, einschließlich Warten auf Disk-I/O, weshalb eine Maschine mit Load 8 und untätigen CPUs meist an I/O hängt und nicht an fehlender Rechenleistung.
TCP baut eine Verbindung auf, garantiert Zustellung und Reihenfolge und drosselt sich bei Netzwerküberlastung. UDP schickt einfach Pakete — kein Handshake, keine erneute Übertragung, keine Reihenfolgegarantie — deshalb ist es schneller und genau das Richtige, wenn zu spät ankommende Daten schlimmer sind als fehlende: Video, Sprache, DNS-Anfragen, Telemetrie. TCP für einen Metrik-Stream zu wählen bringt dir Head-of-Line-Blocking ohne jeden Vorteil ein.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Junior DevOps / SRE-Interview üben →