Vom Keller-PC zum Detektiv der Automatisierung: Kevin Greßlehner (DS Automotion GmbH) über Netzwerke, Leitsysteme und Lernen durch Selbermachen

Warum uns diese DevStory wichtig ist

In der Session „Kevin Greßlehner, IT Techniker bei DS Automotion“ gibt uns Speaker Kevin Greßlehner von der DS Automotion GmbH einen selten offenen Einblick in eine Rolle, die viele Entwickler:innen und IT-Spezialist:innen zwar kennen – aber selten so anschaulich erklärt bekommen: kundennahe IT in hochautomatisierten Umgebungen. Was wir gehört haben, ist die Geschichte eines frühen Tüftlers, der seine Freude am Bauen, Analysieren und Verstehen konsequent in eine Laufbahn übersetzt hat, die zwischen Netzwerk-Design, Leitsystemen und akribischer Störungsanalyse pendelt – oft mit einer Portion Humor und Teamgeist.

Was uns sofort auffiel: Diese Karriere ist weniger ein geradliniger Plan und mehr eine Haltung. Kevin beschreibt sie als eine Kette von „selbst machen, ausprobieren, verstehen“ – vom ersten „kaputten“ PC im Keller bis zur Hochverfügbarkeit im produktiven 24/7-Betrieb.

Der erste Funke: Ein „kaputter“ PC, der gar nicht kaputt war

Kevin war sieben Jahre alt, als zu Hause ein ausrangierter PC im Keller landete – offiziell „kaputt“. Der Rechner war schwer, alt, „ein riesen schwarzer Kübel“, wie er sagt. Aber er war nicht kaputt. Kevin trug ihn heimlich nach oben, schloss ihn an und spielte die Spiele seiner Zeit. Das war 2003, und es war der Anfang.

Dieser Moment ist mehr als eine Kindheitsanekdote. Er setzt den Ton für alles Weitere: Nicht hinnehmen, was als unmöglich oder defekt gilt. Nachsehen. Aufbauen. Testen. Und sich dabei selbst etwas zutrauen.

Vom Basteln zum Programmieren: Linux, Basic und die Frage „Was geht noch?“

Was als Spielen begann, wurde schnell zu einer Bastelleidenschaft. Kevin bekam im Keller einen Raum, um „Sachen zu bauen und zu experimentieren“. Er schraubte an Hardware, installierte Linux und stellte sich die entscheidende Frage: „Was kann man mit dem Ding eigentlich noch tun, außer Spiele spielen?“

Seine Antwort: programmieren. Er brachte sich Basic bei – als Kind, irgendwo zwischen acht und zehn Jahren. Natürlich „schlecht gelernt“, wie er selbstironisch sagt, aber die Richtung stimmte: eigenständig lernen, Funktion verstehen, Ideen umsetzen.

Diese frühe Kombi aus Hardware, Betriebssystemen und ersten Programmierschritten legt ein Fundament, das wir in vielen Laufbahnen sehen, die später in komplexe Systeme münden: Wer Hardware anfasst und Betriebssysteme neu aufsetzt, entwickelt ein mentales Modell dafür, wie Komponenten zusammenspielen. Wer dann dazu programmiert, baut Brücken in die Logik dahinter.

HTL IKT: Systemtechnik, Netzwerke, Java und Projekte

Nach der Hauptschule folgt für Kevin die HTL, Schwerpunkt Informations- und Kommunikationstechnologie. Dort verfestigt sich das breite Technikprofil:

• Netzwerktechnik
• Systemtechnik
• Programmieren (damals Java)
• Projektarbeiten inklusive Projektmanagement

Die Mischung ist bezeichnend: Theorie trifft Praxis, Code trifft Betrieb, und alles wird in Projekten zusammengeführt. Genau diese Verbindung wird später im Kundenservice-IT essenziell – dort, wo Software, Netzwerk, Hardware und reale Prozesse nicht nebeneinander existieren, sondern ineinandergreifen.

Der Aha-Moment bei DS Automotion: Autonome Fahrzeuge in der Produktionshalle

Nach Matura und Bundesheer beginnt die Jobsuche – und Kevin stößt auf die DS Automotion GmbH. Im Bewerbungsgespräch der Moment, der hängen bleibt: Man geht in die Produktionshalle, und dort fahren die Fahrzeuge und Stapler „völlig von selbst herum“.

Die Entscheidung fällt schnell: Am nächsten Tag sagt er zu. Seit 2016 ist Kevin im Kundenservice-IT für die Anlagen der DS Automotion tätig. Damit beginnt der Teil seiner Arbeit, der für viele Tech-Talente überraschend vielschichtig ist.

Kundenservice-IT seit 2016: Wo Technik auf Betrieb trifft

Kevin beschreibt sein Aufgabengebiet als breit und lebendig – mit klaren technischen Kernen und viel Kontext zum realen Einsatz:

• Netzwerktechnik auf Kundenseite: IP-Adressierung für Fahrzeuge, Netzwerkstrukturierung, Firewall-Regeln abstimmen
• Integration von Fremdgeräten in die Anlage
• Aufsetzen der Leitsysteme: Die Entwicklungsabteilung liefert, Kevin und Team installieren auf Kundenrechnern und sichern den Betrieb
• Kommunikationssicherung zwischen allen Komponenten
• Support im Fehlerfall – vom Fahrzeug über die Leitsteuerungstechnik bis zu peripheren Komponenten wie einem Brandschutztor

Diese Rolle ist technisch anspruchsvoll, aber vor allem ist sie operativ relevant. Sie sitzt am Knotenpunkt zwischen Entwicklung, Infrastruktur und realen Betriebsabläufen der Kunden.

Netzwerke beim Kunden: Struktur, Adressen, Firewalls, Fremdgeräte

Ein besonders praxisnahes Stück seiner Arbeit ist das Netzwerk-Design beim Kunden. Neue Anlagen bedeuten, dass Fahrzeugflotten und Leitsysteme sauber adressiert, strukturiert und gesichert werden müssen.

• Vergabe von IP-Adressen für Fahrzeuge und Anlagenkomponenten
• Segmentierung und Strukturierung des Netzwerks in Abstimmung mit Kunden-IT
• Firewall-Regeln definieren und konsensual umsetzen
• Aufnahme und Integration von Fremdgeräten, die in die Anlage eingebunden werden

Hier entscheidet sich, ob ein System stabil und sicher kommuniziert – oder ob es später zu jenen „Fehlerfällen“ kommt, die das Team nachts um drei erreichen. Es ist nicht glamourös, aber fundamental: sauberes Design, klare Zuständigkeiten, nachvollziehbare Regeln.

Leitsysteme aufsetzen: Von der Entwicklungsabteilung in den Betrieb

Die Leitsysteme kommen von der Entwicklungsabteilung. Kevin und Team installieren sie auf den Kundenrechnern, prüfen die Kommunikation und bereiten den laufenden Betrieb vor. Dieser Übergang von Entwicklung in die Produktionsrealität ist immer eine kritische Phase: Hier müssen Versionen, Konfigurationen, Schnittstellen und Abhängigkeiten zusammenfinden.

Im Anschluss liegt auch der Support bei ihnen. Das heißt: Wenn etwas nicht funktioniert, führt die Spur schnell zu den Kolleg:innen im Kundenservice-IT.

Support und Störungsbehebung: Detektivarbeit mit Logfiles

Wenn beim Kunden eine Störung auftritt, beginnt die Arbeit eines Detektivs. So nennt Kevin das selbst, und die Beschreibung könnte nicht besser passen.

Der Prozess ist klar strukturiert, aber in der Sache oft anspruchsvoll:

1. Eingang der Störung – per E‑Mail, per Telefon, „auch einmal in der Nacht um drei in der Früh“.
2. Erste Bestandsaufnahme – „Wie schaut die Anlage gerade aus, wie verhält sich das?“ Stimmt die Beschreibung des Kunden mit dem aktuellen Systemzustand überein?
3. Logfiles öffnen, durchgehen, Hypothesen bilden – Wo ist „irgendein Teil der Software falsch abgebogen“? Oder liegt ein Fehler auf Kundenseite vor?
4. Differenzieren, dokumentieren, erklären – und dem Kunden eine nachvollziehbare Beschreibung liefern.

Die Aufgabe ist nicht nur technisch, sie ist auch kommunikativ. Manchmal behauptet ein Kunde vehement, „wir haben es verursacht“ – und es ist ein besonderer Moment, wenn die Logik und die Logfiles das Gegenteil belegen.

Hinter dem Humor steckt Professionalität: Fehlerkultur, Beweisführung und Klarheit in der Analyse. Genau diese Mischung macht Krisen handhabbar.

Teamkultur: Freundschaft, Humor und Nerf-Darts

Bei aller Ernsthaftigkeit im Betrieb wirkt das Teamklima: „Unser Team ist eigentlich ziemlich zusammengeschwast. Es ist eher freundschaftlich als Arbeitskollegen. Wir haben eine Gaudi bei der Arbeit.“

Und wenn es einmal stressig wird, fliegen auch „Nervdarts im Büro“. Keine Dienst-nach-Vorschrift-Mentalität, keine starre Hierarchie – sondern ein Team, das Nähe und Humor pflegt. Das macht einen Unterschied, wenn nächtliche Störungen reinkommen oder komplexe Hochverfügbarkeiten getestet werden müssen.

Hochverfügbarkeit in der Praxis: Failover planen, aufsetzen, testen

Neue Anlagen bedeuten oft auch Anforderungen an Hochverfügbarkeit. Das heißt: Es braucht eine Lösung, die den Ausfall eines Servers abfängt, in dem der zweite übernimmt – inklusive der passenden Hardware, Konfiguration und Tests.

Das ist ein Feld, in dem sich mehrere Disziplinen treffen: Infrastruktur-Design, Betriebsprozesse, Testmethodik. Kevin betont, wie viel Freude ihm das macht – und richtet im gleichen Atemzug eine Einladung an Interessierte: „Meldet euch bei uns bei der DS-Automotion. Die HR-Abteilung freut sich sicher über euchere Nachrichten.“

Mindset: Interesse und der Wille, selbst zu bauen

Der vielleicht prägendste Punkt dieser DevStory ist das Lern- und Arbeitsverständnis, das Kevin vermittelt. Es ist einfach formuliert, aber konsequent in der Anwendung: Interesse zeigen, selbst bauen, tun.

Anstatt bei einem Problem die Lösung zu kaufen, lohnt es sich oft, zunächst zu fragen: Lässt sich das selbst machen? Dadurch lernt man. So entsteht Praxiswissen, das sich später in professionellen Kontexten auszahlt – von der ersten eigenen Cloud bis zur Analyse komplexer Logfiles.

Konkrete Einstiege: Mikrocontroller-Bewässerung und eigene Cloud

Kevin nennt zwei Beispiele, die greifbarer kaum sein könnten:

• Ein Bewässerungssystem mit einem Mikrocontroller selbst bauen, anstatt ein fertiges Produkt zu bestellen.
• Eine eigene Cloud zu Hause betreiben, statt Daten „bei irgendeinem großen Moloch“ wie Microsoft oder Google zu hosten.

Beide Ideen tragen dieselbe Botschaft: Wer Systeme selbst aufsetzt und betreibt, lernt die Grundprinzipien – Netzwerk, Sicherheit, Betrieb, Fehleranalyse – aus erster Hand. Dieses Erfahrungswissen ist die Basis, auf der sich später komplexe industrielle IT-Landschaften besser verstehen und gestalten lassen.

Was wir als Entwickler:innen und IT-Talente mitnehmen

Aus Kevins Weg und seinen Alltagsaufgaben lassen sich klare Leitlinien ableiten:

• Baue breite Grundlagen auf: Hardware, Betriebssysteme, Netzwerke, Programmierung. Diese Breite macht dich in heterogenen Systemen handlungsfähig.
• Lerne in Projekten: Theorie wird stabil, wenn sie in realen Abläufen erprobt wird – so wie in HTL-Projektarbeiten oder beim Aufsetzen einer privaten Cloud.
• Denke Ende-zu-Ende: Leitsysteme, Fahrzeuge, Fremdgeräte, Firewalls – alles hängt zusammen. Deine Lösung zählt erst im Zusammenspiel.
• Dokumentiere und beweise: Logfiles, Hypothesen, klare Kommunikation. Gute Störungsbehebung ist Detektivarbeit – mit Struktur, Belegen und Respekt.
• Pflege Teamgeist: Humor, Vertrauen und kurze Wege helfen, wenn es „um drei in der Früh“ ernst wird.
• Habe Spaß am Betrieb: Hochverfügbarkeit ist kein Buzzword, sondern eine Disziplin. Failover planen, aufsetzen, testen – das ist echtes Engineering.
• Baue selbst: Nichts ersetzt die Erfahrung, etwas von Grund auf einzurichten, zu konfigurieren und im Fehlerfall zu verstehen.

„DevOps-Mentalität“, ohne es so zu nennen

Kevin benutzt keine Schlagworte. Aber was er beschreibt, lebt vieles, was man gemeinhin als DevOps-Mentalität bezeichnet:

• Verantwortung von der Installation bis zum Betrieb
• Zusammenarbeit mit Entwicklung und Kunden-IT
• Fokus auf Automatisierungssysteme, die im Realbetrieb funktionieren
• Kontinuierliches Lernen durch Praxis

Ohne Hype, ohne Buzz. Stattdessen mit klaren Aufgaben und sichtbaren Ergebnissen: Fahrzeuge, die „völlig von selbst herumfahren“, weil im Hintergrund Netzwerke, Leitsysteme und Server stabil zusammenspielen.

Für wen dieser Weg passt

Diese DevStory spricht Menschen an, die Freude daran haben, Systeme zum Laufen zu bringen – und zwar dort, wo es zählt: beim Kunden, in Produktionshallen, unter Zeitdruck, zugleich strukturiert und pragmatisch. Wer gerne Hypothesen gegen Logfiles hält, wer Netzwerke so plant, dass später Ruhe ist, wer bei Hochverfügbarkeit an Tests denkt und nicht nur an Diagramme, findet sich in Kevins Beschreibung wieder.

Und wer noch am Anfang steht, kann mit Kevins Rat starten: Interesse zeigen, selbst bauen, wiederholen. Aus einem „kaputten“ Keller-PC kann einiges werden.

Zitate und Gedanken, die bleiben

Diese Sätze fassen die Haltung zusammen: neugierig, verantwortlich, praxisnah.

Fazit: Eine Karriere, die mit Selbermachen beginnt – und im Betrieb reift

„Kevin Greßlehner, IT Techniker bei DS Automotion“ zeigt, wie aus frühem Tüfteln eine belastbare, vielseitige IT-Karriere wird. Bei der DS Automotion GmbH verbindet Kevin Netzwerktechnik, Leitsystem-Setup, Störungsanalyse und Hochverfügbarkeit – getragen von einem Team, das Professionalität und Humor verbindet.

Wer sich in dieser Welt wiederfindet, weiß nach dieser Session, was zählt: Systeme verstehen, Verantwortung übernehmen, Belege liefern – und immer wieder selbst bauen. Genau daraus entsteht die technische Reife, die man braucht, wenn Fahrzeuge autonom fahren und Anlagen rund um die Uhr funktionieren sollen.

Am Ende bleibt Kevins Einladung im Ohr: Interesse mitbringen, selbst anpacken – und sich melden, wenn genau das die eigene Vorstellung von guter IT-Arbeit ist.

• 

  

  Klemens Pleiner, Basis Software Developer bei DS Automotion

  Klemens Pleiner von DS Automotion gibt im Interview Einblicke in seinen Weg als Developer, das Besondere an seiner aktuellen Arbeit im Unternehmen und was seiner Meinung nach wichtig für Neueinsteiger ist.

  Jetzt ansehen
• 

  

  Gerald Hahn, Requirements Engineer bei DS Automotion

  Gerald Hahn von DS Automotion berichtet im Interview über das Requirements Engineering: wie er in die Branche eingestiegen ist und was er Anfängern raten würde.

  Jetzt ansehen
• 

  

  Lukas Fiel, Test Automation Engineer bei DS Automotion

  Lukas Fiel von DS Automotion erzählt im Interview von seinem Werdegang von den eigenen Projekten bis hin zum Test Automation Engineering und welche Tipps er für Neueinsteiger bereithält.

  Jetzt ansehen