Zum Inhalt springen

Ein System Engineer hält am Laufen, was alle anderen voraussetzen.

System Engineer klingt nach der Rolle, die Server aufsetzt und danach wartet, bis etwas ausfällt. Tatsächlich verantwortet sie die Schicht, auf der alles andere aufbaut: Betriebssysteme, Zugänge, Zertifikate, Sicherungen, Überwachung. Wir zeigen, was die Rolle im Alltag tut, worin sie sich von Cloud und Platform Engineer unterscheidet und was ein KMU 2026 davon braucht.

Wenn im Betrieb etwas stillsteht, ruft niemand nach dem System Engineer. Angerufen wird der IT Partner, der Entwickler oder die Person im Haus, die sich am ehesten auskennt. Meistens läuft es danach wieder und genau deshalb bleibt eine Frage jahrelang offen: Wem gehören die Systeme, auf denen alles andere aufbaut. Wir schreiben auf, was ein System Engineer im Alltag tut, worin er sich von einem Cloud Engineer und einem Platform Engineer unterscheidet und was ein KMU davon 2026 tatsächlich braucht.

Ein System Engineer verantwortet die Schicht, die alle anderen voraussetzen.

Unter jeder Anwendung liegt eine Schicht, über die im Projekt kaum gesprochen wird: Betriebssystem, Datenbank, Netzwerk, Zertifikate, Zugänge, Sicherungen, Überwachung. Ein System Engineer plant diese Schicht, baut sie auf und betreibt sie. Das gilt für Server im eigenen Haus genauso wie für Maschinen bei einem Anbieter, denn eine virtuelle Maschine in der Cloud ist ein Server mit Rechnung statt mit Lüftergeräusch.

Im Alltag ist das eine Reihe unspektakulärer Arbeiten. Betriebssysteme und Datenbanken aktuell halten. Zugänge vergeben und, wichtiger, wieder entziehen, wenn jemand die Firma verlässt. Zertifikate erneuern, bevor sie ablaufen. Kapazität beobachten, damit der Speicher nicht am Quartalsende voll ist. Protokolle so einrichten, dass sich nach einem Vorfall noch nachlesen lässt, was passiert ist.

Dazu kommt die Arbeit, die den Unterschied macht: aufschreiben, wie das System aufgebaut ist, damit eine andere Person es übernehmen kann. Ein Betrieb, der nur im Kopf einer einzelnen Person existiert, ist kein Betrieb, sondern ein Risiko mit Ferienanspruch.

Die Sicherung gehört ebenfalls hierher und dort zeigt sich der Unterschied zwischen eingerichtet und verantwortet am deutlichsten. Ein Backup ist ein Versprechen, ein Restore ist der Beweis und den Beweis liefert nur, wer die Wiederherstellung regelmässig durchspielt.

Cloud Engineer und Platform Engineer lösen andere Probleme, auch wenn sich die Arbeit überschneidet.

Die drei Bezeichnungen werden in Stelleninseraten fast beliebig verwendet, dahinter stehen aber drei verschiedene Aufträge.

Ein Cloud Engineer arbeitet mit den Diensten eines Anbieters. Er baut die Umgebung aus deren Bausteinen zusammen, regelt Berechtigungen und behält die monatliche Rechnung im Auge, die bei diesem Modell die eigentliche Steuergrösse ist.

Ein Platform Engineer baut nach innen. Sein Kunde ist das Entwicklungsteam und sein Ergebnis ist eine Umgebung, in der dieses Team selber ausliefern kann, ohne für jeden Schritt jemanden zu fragen. Das lohnt sich, wenn mehrere Teams gleichzeitig entwickeln. Für ein Unternehmen mit zwei Anwendungen und einem externen Entwickler ist es Aufwand ohne Gegenwert.

Ein System Engineer verantwortet den Betrieb, unabhängig davon, wo er stattfindet. Er bleibt auch dann zuständig, wenn die Hälfte im eigenen Haus läuft, ein Teil beim Hoster und der Rest bei einem Anbieter mit einem Vertrag, den vor drei Jahren jemand unterschrieben hat, der nicht mehr da ist.

In einem KMU macht ohnehin eine Person alle drei Teile und das ist richtig so. Wichtig ist nicht der Titel im Vertrag, sondern dass jemand für die ganze Schicht zuständig ist statt nur für den Teil, den er selber aufgesetzt hat. Wo etwas läuft, ist am Ende auch eine Frage der Abhängigkeit: Was davon heute auf Schweizer Infrastruktur möglich ist und wo es weh tut, steht in Digitale Souveränität in der Schweiz 2026.

Betrieb und Sicherheit überschneiden sich in der Arbeit und trennen sich in der Verantwortung.

Updates einspielen, Zugänge sauber halten, Protokolle überwachen: Diese Aufgaben stehen in beiden Rollenbeschreibungen und in einer kleinen Firma macht sie dieselbe Person. Der Unterschied liegt in der Frage, die sie beantworten.

Ein System Engineer fragt, ob das System läuft und wie schnell es nach einem Ausfall wieder läuft. Ein Cyber Security Engineer fragt, wer darauf zugreifen kann und was passiert, wenn es jemand tut, der nicht soll. Beide Fragen führen zu denselben Massnahmen und zu unterschiedlichen Abwägungen: Dass sich aus einer Sicherung schnell wiederherstellen lässt, ist Betrieb. Dass diese Sicherung verschlüsselt und getrennt vom Hauptsystem liegt, ist Sicherheit.

Wie die zweite Rolle im Alltag arbeitet, steht in Was macht ein Cyber Security Engineer. Bei uay gehören beide zur Disziplin Betrieb, Qualität und Sicherheit, zusammen mit QA Engineer und Data Engineer.

Drei Anzeichen zeigen, dass die Rolle bei euch niemandem gehört.

Das erste ist die Antwort auf die Frage, was auf den Servern eigentlich läuft. Wenn sie in einer Sitzung niemand vollständig geben kann, betreibt die Firma Systeme, die sie nicht kennt. Bezahlt, gesichert und irgendwann ersetzt werden sie trotzdem.

Das zweite sind Zugänge von Leuten, die nicht mehr im Unternehmen sind. Das ist der Prüfpunkt, der am schnellsten geht und er ist in den meisten KMU, die wir anschauen, mindestens einmal fällig.

Das dritte ist die Offerte für neue Server, die niemand beurteilen kann. Sie ist plausibel, die alten Maschinen sind tatsächlich alt und trotzdem fehlt die Grundlage für den Entscheid: was darauf läuft, ob es das noch braucht und was dieselbe Leistung bei einem anderen Anbieter kostet. Diese Ausgangslage haben wir unter neue Server vom IT Partner beschrieben, weil sie oft vorkommt.

Keines der drei Anzeichen heisst, dass jemand schlecht gearbeitet hat. Sie heissen, dass die Rolle nirgends zugeordnet ist und deshalb jeder nur seinen Teil sieht.

Ein KMU braucht 2026 selten eine Stelle und immer eine Zuständigkeit.

Wer seine Software vollständig als Dienst bezieht, also Mail, Buchhaltung und Branchenlösung beim Anbieter, braucht keinen eigenen System Engineer. Gebraucht wird jemand, der die Zugänge, die Verträge und die Sicherungen dieser Dienste im Blick behält und das sind wenige Stunden im Quartal.

Sobald eigene Server oder eigene Anwendungen im Spiel sind, sieht die Rechnung anders aus. Für eine überschaubare Umgebung mit zwei bis drei Systemen rechnen wir mit zwei bis drei Tagen am Anfang, um aufzunehmen, was vorhanden ist und danach mit einem halben bis einem Tag im Monat für Updates, Sicherungen, Zugänge und den Blick auf die Überwachung. Eine eigene Stelle wird daraus erst, wenn mehrere Systeme gleichzeitig laufen, der Betrieb an Zeiten gebunden ist und ein Ausfalltag Geld kostet, das sich beziffern lässt.

Bei jedem Problem schauen wir zuerst, welche Rollen es braucht. Diese hier ist fast immer dabei, sobald etwas dauerhaft laufen muss. Sie muss nicht bei uns liegen: Wenn der bestehende IT Partner sagen kann, was läuft, wer zugreift und wann zuletzt eine Wiederherstellung geprüft wurde, ist das der einfachere Weg. Wenn niemand zuständig ist, übernehmen wir es und bleiben gegenüber dem Kunden verantwortlich.

Warum nicht einfach die KI fragen

  1. Frag sie

    Was ein System Engineer tut und worin er sich von einem Cloud Engineer unterscheidet, erklärt dir die KI in fünf Minuten und das ist ein guter Anfang.

  2. Was die KI nicht weiss

    Was auf euren Servern tatsächlich läuft, wer heute noch Zugriff hat und ob die Sicherung im Ernstfall hält. Dafür gibt es uns.

Wenn bei dir niemand sagen kann, was auf den Servern läuft und wer noch Zugriff hat, schreib uns, was ihr betreibt und wer es heute macht. Wir lesen, was du schickst und melden uns.