DevOps-Engineer auswählen: verlässliche Abläufe statt Werkzeugliste

Beginnen Sie mit dem Betriebsproblem

„Kennt Kubernetes, Terraform und AWS“ sagt nicht, ob Sie eine Plattform aufbauen, bestehende Abläufe verbessern oder ein Entwicklungsteam bei zuverlässigen Releases unterstützen wollen. Beschreiben Sie den Dienst, die wiederkehrende Störung und das Ergebnis, das sich im Alltag ändern soll.

Ordnen Sie die Aufgaben: Plattform bereitstellen, Entwicklerabläufe verbessern, Produktionsprobleme untersuchen oder Sicherheitskontrollen pflegen. Eine Person kann mehrere Bereiche abdecken; nennen Sie, welche zuerst zählen. Seniorität bemisst sich daran, ob sie nach klarer Vorgabe arbeitet oder auch Abhängigkeiten und Betriebsrisiken über mehrere Dienste hinweg abstimmt.

Klären Sie vor dem Gespräch die Zugriffsgrenzen. Fragen Sie, wie die Person mit Geheimnissen, Änderungen an produktiven Systemen und einer Rücknahme umgeht. Wichtige Regeln und Freigaben gehören in Ihre Organisation; eine Rolle allein ersetzt sie nicht.

Lassen Sie einen fehlgeschlagenen Release durchspielen

Fiktives Beispiel: Nach einer neuen Version melden sich Nutzer zwar an, sehen aber keine aktuellen Daten. Die Änderung wurde ausgerollt, während Hintergrundverarbeitung weiterläuft. Fragen Sie, welche Signale die Person zuerst prüft, wie sie Umfang und Beginn des Problems eingrenzt und wann sie zurücksetzt statt weiter zu ändern.

Eine gute Antwort trennt Nutzerwirkung, technische Hypothese und Beleg. Sie nennt einen sicheren Rückfallweg, prüft Datenkompatibilität und informiert die zuständigen Personen. Danach folgt eine Ursachenanalyse, die eine Wiederholung unwahrscheinlicher macht. „Einfach mehr Überwachung“ ist ohne konkrete Frage kein vollständiger Plan.

Bitten Sie zusätzlich um einen Entwurf für einen Alarm: Welche Messung löst ihn aus, wer erhält ihn und welche erste Handlung ist möglich? Ein Alarm, der nur einen technischen Wert meldet, aber keine Nutzerwirkung oder Zuständigkeit zeigt, erzeugt leicht Lärm.

Der Ablauf ist erfunden und dient als Gesprächsprobe. Tatsächliche Rücknahmen folgen Ihren Systemen, Zuständigkeiten und Freigaben.

Fragen für die Auswahl

• „Wie haben Sie zuletzt eine Änderung zurückgenommen, die Probleme verursachte?“
• „Welche Schritte müssen wiederholbar sein, und welche brauchen menschliche Freigabe?“
• „Wie trennen Sie Anwendungseinstellungen von Geheimnissen?“
• „Welche Kennzahl würde zeigen, ob ein Dienst für Nutzer gerade funktioniert?“
• „Wie gehen Sie vor, wenn ein Alarm keine klare Handlung auslöst?“
• „Was dokumentieren Sie, damit ein anderes Teammitglied einen Vorfall übernehmen kann?“

Für eine Arbeitsprobe genügt ein vorbereiteter Ablauf mit einem bewusst eingebauten Fehler. Lassen Sie Risiken, Rücknahme und Informationsbedarf skizzieren. Geben Sie keine produktiven Zugangsdaten und verlangen Sie keine Änderungen an Ihrem echten System.

• Dienst und Zuständigkeiten benennen.
• Zugriffsmodell vor Arbeitsbeginn klären.
• Rücknahme und Wiederherstellung besprechen.
• Beispiele für Kommunikation bei einem Vorfall prüfen.

Betrieb ist gemeinsame Teamverantwortung

Ein Gespräch beweist nicht, wie ein Dienst unter Ihrer Last oder in Ihrer Organisation reagiert. Ihr Team verantwortet Freigaben, Zugänge und das akzeptierte Risiko. Division5 gleicht den Bedarf mit vorab geprüften Profilen ab. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Für alle Fachkräfte gilt eine 30-tägige Testphase; Umfang und Bedingungen halten Sie vor Beginn schriftlich fest. So läuft der Auswahlprozess ab.

Fachkräfte für Ihr Team ansehen.