Linux-Sysadmin im Homeoffice: Traumjob oder 24/7-Bereitschaft?

Der Mythos vom Sysadmin im Unterhemd

Zu ungewöhnlicher Zeit aufstehen, sich per SSH mit Public/Private-Key mit dem jeweiligen Server verbinden, prüfen, ob die Dienste (Webserver, MySQL) laufen, Repositories und Patches aktualisieren, eine Monitoring-Anwendung mit geplanten Alarmen einrichten und dann einen Film schauen, bis die Schicht vorbei ist. Das ist die Erzählung, die die Debatte auslöst: der Linux-Systemadministrator im Remote-Job als Traumarbeit, ohne Kontakt zu irgendwem, während der Anwendungsentwickler sein Gehirn verbrennt und Frameworks lernt, die sich jedes Jahr wandeln. Die Diskussion zerfällt jedoch in tausend Teile, sobald jemand die Tastatur übernimmt, der wirklich schon Bereitschaft gehabt hat.

Der Arbeitstag, der nie endet

Der erste Dämpfer für die Erzählung ist die Arbeitszeit. Der Tag eines Systemadministrators endet nicht um sechs. Wer echte Bereitschaften übernommen hat, beschreibt ganze Nächte ohne Schlaf: Eingriffe um 02:00 Uhr, Alarme um 04:00 Uhr und ein letzter Anruf um 06:30 Uhr, der den Schlaf schon unmöglich macht, sodass man einen doppelten Kaffee runterkippt und die aufgestaute Arbeit vom Vortag aufholt. Das alles auch noch mit Vorgesetzten, die nicht verstehen, warum man die offenen Aufgaben nicht fertiggestellt hat.

Hinzu kommt: Störungen kündigen sich nicht an. Eine Festplatte kann jederzeit durchbrennen; ein Server kann zu einer zufälligen Uhrzeit angegriffen werden. Monitoring gibt es gerade deshalb, um auf diese Probleme hinzuweisen, was bedeutet, dass jemand schnell reagieren muss, zu jeder Zeit. Der Programmierer dagegen hat Arbeitszeiten und trennt sich nach Feierabend ab. Der Systemadministrator ist dauerhaft erreichbar, und genau diese Verfügbarkeit zerstört das Privatleben.

Der Tag, an dem alles gleichzeitig zusammenbricht

Das Bild des Technikers, der sich den Bauch kratzt, hält bis zur ersten Störung. Wenn ein Dienst ohne erkennbaren Grund ausfällt, nicht startet und niemand etwas verändert hat, beginnt die Party. Und sie kommt selten allein: zwei Maschinen gleichzeitig ausgefallen, ein Angriff, ein Leistungsabfall, ein weiterer verketteter Ausfall. Manche beschreiben diese Phase als vier Kilo Gewichtsverlust in wenigen Tagen und die Erkenntnis, dass der Job nicht das ist, was er schien.

Die optimistischste Rechnung geht davon aus, dass eine Bereitschaft mit erledigten Vorbereitungen entspannt sein kann. Das pessimistische Szenario beginnt bei der Tatsache, dass Observability und Metriken gerade deshalb existieren, weil ein System „fehlerfrei“ laufen kann und trotzdem eine erbärmliche Erfolgsquote hat, nur wegen einer Fehlkonfiguration. Niemand streitet ab, dass Bereitschaften bezahlt werden sollen; gestritten wird, ob der Preis nur ein finanzieller ist.

Sackgasse oder solides Fundament?

Die zweite Front ist Gehalt und Karriere. Ein Systemadministrator, so das Argument, habe ein begrenztes Wachstum: Er wartet, was andere erschaffen, sein Arbeit gewinnt keinen Mehrwert, und seine Rolle ähnelt eher der eines IT-Beamten als der eines Unternehmers. Ein Entwickler dagegen kann eine Anwendung bauen und an Tausende Nutzer verkaufen. Diese Asymmetrie ist real, allerdings stimmt auch, dass Entwickler die Überstunden schlucken, wenn die Deadlines kommen.

Dagegen hält mancher entgegen, dass die Arbeit so komplex geworden ist, dass die ursprüngliche Erzählung sich das nicht einmal vorstellen kann: Cloud-Identitäten, CI/CD-Pipelines, Container, Hochverfügbarkeit und Skalierung. Was ein Praktikant früher am ersten Tag machte —Verzeichnisse anlegen, Dienste initialisieren, Zertifikate verwalten— ist heute nur der Ausgangspunkt einer Kette von Tools, die sich gegenseitig bekämpfen. Die Gesamtrechnung, mit allen beteiligten Ebenen, ergibt ein deutlich weniger rosiges Bild als das des Technikers beim Filmschauen.

Monitoring, Observability und die Kunst, das Rad umzubenennen

Eine der kuriosesten Nebenlinien des Austauschs ist die Diskussion über die Fachsprache. Was die Industrie Observability nennt, so das Argument, sei nichts anderes als die kontinuierliche Überwachung, die industrielle SCADA-Systeme seit Jahrzehnten machen: Erfassung historischer Daten, Alarme, wenn ein Parameter den Sollbereich verlässt, und Prozesssteuerung. Der Unterschied, so heißt es, sei, dass heute eine Business-Schicht hinzukommt —wie viele Bestellungen eingehen, wie viele verloren gehen, wie viel Geld im Abfluss versenkt wird— und ein hübscheres Grafana obendrauf gesetzt wird. Das Rad neu zu erfinden und ihm einen neuen Namen zu geben, ist, kurz gesagt, eine Tradition der Branche.

Das Profil, das das System wirklich am Laufen hält

Jenseits von Gehalt und Bereitschaften zeichnet sich das Porträt eines Profis ab, der Aufgaben mit Skripten und eigenen Tools automatisiert, während andere wochenlang weiter Tabellen abtippen. Eine Arbeit, die einfach und schlecht bezahlt sein kann oder komplex und nur mit Trinkgeldern entlohnt, die aber in jedem Fall verlangt, ständig zu messen, selbst wenn kein Alarm ausgelöst wird. Die Frage lautet am Ende nicht, ob der Job bequem ist. Sie lautet, ob jemand derjenige sein will, der die Infrastruktur trägt, wenn alles andere versagt — im Wissen, dass das Telefon um drei Uhr nachts klingeln kann.