Senior DevOps / SRE — DevOps-Interviewfragen

Wie entwirfst du einen Rollback, der tatsächlich funktioniert?

Indem du jedes Deployment unabhängig umkehrbar machst, was vor allem die Datenbank betrifft: erst expand, dann contract, nie in demselben Release löschen, in dem das Schreiben eingestellt wird. Die zweite Voraussetzung ist, dass der Rollback tatsächlich geübt wird — ein Pfad, der einmal im Quartal während eines Incidents benutzt wird, ist ein Pfad, der nicht funktioniert. Feature Flags entkoppeln Release von Deploy und machen aus den meisten Rollbacks eine reine Config-Änderung.

Ein Incident läuft, und du kennst die Ursache noch nicht. Wie führst du ihn?

Erst den Service wiederherstellen, dann diagnostizieren: Maßnahmen wie Rollback, Traffic umleiten oder Skalieren brauchen keine Root Cause. Jemand übernimmt die Koordination und debuggt dabei nicht selbst mit, und die Timeline wird laufend mitgeschrieben, weil das Gedächtnis sie hinterher falsch rekonstruiert. Das Postmortem fragt, was den Fehler möglich gemacht hat und was seine Erkennung verzögert hat — nicht, wer welchen Befehl eingegeben hat.

Wie entscheidest du, worauf du einen Alert legst?

Auf Symptome, die der Nutzer spürt — Fehlerrate, Latenz, Nichtverfügbarkeit — nicht auf Ursachen, denn Ursachen gibt es viele und die meisten sind harmlos. Jeder Alert braucht eine Handlung; einer, der routinemäßig bestätigt und ignoriert wird, trainiert die Leute darauf, Alerts zu ignorieren. Das Maß für ein gutes Alerting-Setup ist, wie viele Pages unnötig waren, und diese Zahl sollte regelmäßig überprüft werden.

Ein Cluster kostet dreimal so viel, wie er sollte. Wo schaust du zuerst nach?

Zuerst bei Requests gegenüber tatsächlicher Nutzung, weil überhöhte Requests Kapazität reservieren, die niemand nutzt, und das die mit Abstand größte Verschwendungsquelle ist. Dann bei der Node-Größe und dem Bin-Packing, dann bei dem, was läuft und niemandem gehört — alte Umgebungen, vergessene Load Balancer, Snapshots. Storage und Egress-Traffic sind die Posten, die still wachsen und in der ersten Schätzung nie auftauchen.

Wie führst du Infrastructure as Code in eine handgepflegte Umgebung ein?

Indem du importierst statt neu zu bauen, ein abgegrenztes Stück nach dem anderen, beginnend mit etwas risikoarmem, damit sich der Workflow einspielt, bevor es wirklich zählt. Die eigentliche Schwierigkeit liegt nicht im Tooling, sondern in der Regel, dass manuelle Änderungen aufhören müssen — denn ein Codebase, der von der Realität abdriftet, ist schlimmer als gar kein Codebase, weil man ihm vertraut, obwohl er falsch ist. Drift Detection muss nach einem festen Zeitplan laufen.

Wie hältst du On-Call auf Dauer tragbar?

Indem du das Alert-Aufkommen wie eine Anzahl von Defekten mit einem Owner behandelst, nicht wie das Wetter. Eine Rotation, die jede Nacht piept, brennt Leute aus, und die daraus entstehende Fluktuation kostet mehr als die Engineering-Zeit, um die Ursachen zu beheben. Die konkreten Praktiken sind ein Follow-up-Task zu jedem Page, eine Obergrenze für akzeptable Toil und reservierte Zeit im nächsten Sprint für das, was die letzte Rotation zutage gefördert hat.