Strategie & Migration

Mitarbeiter auf Linux schulen, ohne den Betrieb auszubremsen

Die Entscheidung für Linux fällt schneller als die Frage, wer es danach betreibt. Plane Schulung als Teil des Projekts ein, nicht als Nachlauf, sonst betreibt am Ende eine einzelne Person das System und wird zum Engpass.

6 Kapitel mit allen Befehlen
IT-Entscheider besprechen eine Infrastruktur-Roadmap im Besprechungsraum
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Qualifizierung der eigentliche Engpass ist

Technisch ist eine Migration planbar. Du kennst deine Fachverfahren, du weißt, welche Anwendungen unter Wine, im Browser oder in einer VM weiterlaufen müssen, und du hast eine Vorstellung davon, ob die Clients auf Linux Mint, Ubuntu oder eine RHEL-nahe Distribution gehen. Was sich schlechter planen lässt, ist der Wissensstand der Menschen, die das System danach jeden Tag anfassen. Genau daran scheitern Umstiege häufiger als an Treibern oder Dateiformaten.

Bei den Administratoren zeigt sich das Problem verzögert. Installation und Rollout laufen oft noch mit externer Unterstützung, aber sechs Wochen später steht das Team vor Rechteproblemen im Dateiserver, vor einem Dienst, der nach dem Reboot nicht mehr startet, und vor Logs, die niemand systematisch liest. Wer aus der Windows-Welt kommt, sucht in der GUI nach dem Schalter, statt sich mit systemctl, journalctl und den Konfigurationsdateien unter /etc auseinanderzusetzen. Ohne Grundlagen zu Prozessen, Rechten, Paketverwaltung und Netzwerkdiensten bleibt jede Störung ein Einzelfall.

Bei den Anwendern ist der typische Fehler das Gegenteil: Es wird zu viel erklärt und zu wenig geübt. Für die meisten Beschäftigten ist der Desktop nur Mittel zum Zweck. Sie brauchen Sicherheit bei LibreOffice, bei den Dateiformaten im Austausch mit externen Partnern, bei Mail, Drucken und den Ablagen im Netz. Ein Kernel-Vortrag hilft ihnen nicht, ein halber Tag mit den eigenen Dokumenten schon. Wenn beide Gruppen dieselbe Schulung bekommen, ist sie für die einen zu oberflächlich und für die anderen zu technisch.

Miniatur-Szene: Spielbrett, auf dem eine Server-Figur von einer alten auf eine neue Plattform zieht, daneben eine Roadmap
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Schulungsplan entlang der Migration

  1. 01 Rollen und Wissensstand erheben
  2. 02 Admin-Team vorziehen: LPI01 bis LPI04
  3. 03 Multiplikatoren je Fachbereich benennen
  4. 04 Anwenderschulung pro Rollout-Welle
  5. 05 Zertifizierung LPIC-1 als Nachweis
  6. 06 Betrieb festigen: Automatisierung, Security, Troubleshooting
Was du mitnimmst

Zwei Lernpfade, eine Zeitachse

Wir trennen die Qualifizierung konsequent nach Rolle und hängen sie an den Rollout-Plan. Anwender werden kurz vor ihrer Umstellungswelle geschult, Administratoren deutlich davor, damit sie den Rollout selbst begleiten können.

Anwender: kurz, konkret, am eigenen Arbeitsplatz

Der Kurs "Umstieg auf Linux Mint und LibreOffice" deckt Desktop-Bedienung, Dateiablage und die Office-Umstellung ab, inklusive der Stolperstellen bei docx- und xlsx-Austausch. Für Beschäftigte ohne IT-Vorerfahrung passt der IT-Basiskurs mit Ubuntu, LibreOffice und E-Mail besser, weil er die Grundlagen mitnimmt.

Administratoren: Grundlagen vor Spezialthemen

Der Einstieg läuft über den Linux Grundkurs (LPI01) und den Aufbaukurs Administration und Systemmanagement (LPI02). Danach folgen Shell-Programmierung (LPI03) und Linux im Netz (LPI04). Damit sitzen Dateisystem, Rechte, Paketverwaltung, systemd, Benutzerverwaltung und die zentralen Netzwerkdienste.

Zertifizierung als messbarer Abschluss

Wer den Wissensstand belegen will, hängt die Prüfungsvorbereitung LPIC-1 (LPI05) an oder wählt gleich die Komplettausbildung zur LPIC-1 Zertifizierung. Für Teams mit Zeitdruck gibt es das Linux BootCamp zum LPIC-1 Linux-Administrator als kompakten Block.

Umstiegs- und Koexistenzwissen einplanen

Reine Linux-Grundlagen reichen nicht, solange Windows-Systeme im Netz bleiben. Der Kurs "Linux Migration - Von Windows zu Linux" adressiert genau die Übersetzungsarbeit, "Linux Samba und Windows Netzwerke" die gemeinsamen Datei- und Druckdienste in gemischten Umgebungen.

Multiplikatoren im Haus aufbauen

Aus jedem Fachbereich sollten ein bis zwei Personen deutlich tiefer geschult werden als der Rest. Diese Multiplikatoren fangen die kleinen Fragen ab, sammeln wiederkehrende Probleme und entlasten den Servicedesk in den ersten Wochen nach jeder Welle spürbar.

Betriebsreife nach dem Rollout

Wenn der erste Betrieb läuft, folgen die Themen, die den Aufwand dauerhaft senken: Automatisierung mit dem Ansible Kompaktkurs, Härtung im Linux Security Intensivkurs und strukturierte Fehlersuche im Linux Troubleshooting Training.

Tutorial

Vom Ist-Stand zum Qualifizierungsplan in vier Schritten

Die Reihenfolge ist immer dieselbe: erst messen, was ihr betreibt und wer was kann, dann einstufen, dann eine Übungsumgebung stellen und den Zeitplan an den Rollout hängen. Zum Schluss geht es darum, das erworbene Wissen im Haus zu halten, statt es nach sechs Monaten wieder einzukaufen.

01

Erst messen, was tatsächlich läuft

Der Schulungsinhalt ergibt sich aus dem Bestand, nicht aus einem Katalog. Zwei Stunden Inventur sparen ein halbes Jahr am Ziel vorbei.

Distributionen und Versionen einsammeln
# hosts.txt: eine Zeile je Server
while read -r h; do
  info=$(ssh -n -o BatchMode=yes -o ConnectTimeout=5 "$h" \
    '. /etc/os-release; echo "$PRETTY_NAME"' 2>/dev/null)
  printf '%-30s %s\n' "$h" "${info:-nicht erreichbar}"
done < hosts.txt | tee inventar.txt

# Mit Ansible geht dasselbe kürzer
ansible all -m setup -a 'filter=ansible_distribution*'

Das -n bei ssh ist wichtig: ohne die Option liest ssh die restliche hosts.txt von der Standardeingabe weg und die Schleife bricht nach dem ersten Server ab. Ergänze den Aufruf um systemctl list-units --type=service --state=running, dann siehst du zusätzlich, welche Dienste die Server tragen.

Was der Befund für die Qualifizierung bedeutet

BefundGehört in den Plan
RHEL, Rocky oder AlmaLinux überwiegtSELinux, firewalld, dnf und Repository-Verwaltung
Debian oder Ubuntu überwiegtAppArmor, apt, netplan und automatische Sicherheitsupdates
Beides gemischtDie Vereinheitlichung vorher prüfen, sonst schult ihr jedes Thema doppelt
Viele ContainerPodman oder Docker, Logging und Registry vor klassischer Paketpflege
Zentrale Anmeldung an AD oder LDAPVerzeichnisdienste und Kerberos, sonst steht das Team beim ersten Anmeldefehler still
02

Kompetenzraster statt Bauchgefühl

Ohne Raster wird die Person geschult, die am lautesten fragt. Mit Raster siehst du, wo genau ein einzelner Ausfall den Betrieb stoppt.

Raster mit sechs Zeilen, mehr füllt niemand aus

BereichNachweis für selbstständiges ArbeitenRisiko, wenn es niemand kann
Dateisystem und RechteGruppenverzeichnis mit vererbten Rechten einrichtenFreigaben werden mit 777 repariert
Paketpflege und UpdatesSicherheitsupdate einspielen und begründen, warum ein Neustart nötig istServer laufen mit bekannten Lücken weiter
systemd und LogsFehlgeschlagenen Dienst allein bis zur Ursache eingrenzenJede Störung eskaliert sofort nach außen
Netz und FirewallAdresse dauerhaft setzen, Regel öffnen, Erreichbarkeit belegenÄnderungen überleben den nächsten Neustart nicht
Backup und RestoreEine einzelne Datei und ein ganzes System zurückholenDie Sicherung existiert, der Restore wurde nie geübt
AutomatisierungWiederkehrende Aufgabe als Skript mit Timer abbildenWissen bleibt an Handgriffen einzelner Personen hängen

Drei Regeln, damit das Raster nützt

  • Nachweis statt Selbsteinschätzung eintragen.Selbsteinschätzung misst Selbstvertrauen, nicht Können. Beides liegt in beide Richtungen weit auseinander, und du planst am Bedarf vorbei.
  • Je Bereich müssen zwei Personen selbstständig arbeiten können.Eine Person bedeutet Urlaub, Krankheit und Kündigung als Betriebsrisiko. Genau dieser Engpass ist der Grund, warum Qualifizierung überhaupt Projektthema ist.
  • Das Raster wird zweimal im Jahr aktualisiert, nicht einmalig ausgefüllt.Wissen ohne Anwendung verfällt, und der Bestand ändert sich. Ein Raster von vorletztem Jahr beschreibt ein System, das so nicht mehr läuft.
03

Einstufung über einen echten Test, nicht über einen Fragebogen

Eine knappe Stunde an einer Wegwerf-VM sagt mehr als jedes Formular. Kündige das als Einstufung an, nicht als Prüfung, und halte die Ergebnisse aus der Personalakte heraus.

Aufgabenblatt, 45 Minuten, alles an einer vorbereiteten VM
1. Der Dienst 'anwendung' startet nicht. Finde die Ursache und behebe sie.
   Erwartet: systemctl status, journalctl -u, Blick in die Unit

2. Auf /srv sind nur noch wenige Megabyte frei. Schaffe Platz, ohne Daten zu verlieren.
   Erwartet: df, du, lsof auf gelöschte, aber offene Dateien

3. Port 8080 ist von außen nicht erreichbar, der Dienst lauscht aber.
   Erwartet: ss -tlnp, firewalld oder nftables, bei RHEL zusätzlich SELinux

4. Lege eine Gruppe an, die gemeinsam in /srv/projekt schreiben darf.
   Erwartet: groupadd, setgid, ggf. ACL

5. Richte eine wiederkehrende Aufgabe ein, die nachts um 02:30 laeuft.
   Erwartet: systemd-Timer oder Cron, plus Nachweis der Ausfuehrung

Bewertet wird nicht die Lösung, sondern der Weg: Wer bei Aufgabe 1 zuerst ins Journal schaut, hat den Reflex, um den es geht. Wer den Dienst dreimal neu startet und hofft, braucht Grundlagen.

Test-VM zwischen zwei Durchgängen zurücksetzen
virt-clone --original einstufung-vorlage --name einstufung-lauf --auto-clone
virsh snapshot-create-as einstufung-lauf start "Ausgangszustand"

# nach jedem Durchgang
virsh snapshot-revert einstufung-lauf start

Alle bekommen damit exakt dieselbe Ausgangslage. Ohne Rücksetzung findet die zweite Person die Fehler der ersten vor und du vergleichst Äpfel mit Birnen.

04

Eine Übungsumgebung, die den Betrieb nicht gefährdet

Wenn der Zugang zum Labor länger als eine Minute dauert, wird an Produktivsystemen geübt. Das ist keine Disziplinfrage, sondern eine Frage der Reibung.

Klon je Person aus einer gemeinsamen Vorlage
virt-clone --original lab-vorlage --name "lab-$USER" --auto-clone
virsh snapshot-create-as "lab-$USER" start
virsh start "lab-$USER"
virsh domifaddr "lab-$USER"      # IP-Adresse zum Anmelden

# Reset in Sekunden statt Neuinstallation
virsh snapshot-revert "lab-$USER" start

Eine Vorlage mit der produktiv eingesetzten Distribution und Version, nicht die neueste. Geübt wird an dem System, das nachher wirklich betreut wird.

Für kurze Übungen reicht ein Container
podman run --rm -it -v "$PWD/uebungen:/uebungen:Z" \
  registry.access.redhat.com/ubi9/ubi bash

podman run --rm -it docker.io/library/debian:12 bash

Für Paketverwaltung, Textwerkzeuge und Rechte ist das ideal, weil es in Sekunden startet. Für systemd, Kernelmodule, Firewall und Bootvorgang brauchst du eine VM, denn genau das fehlt im Container.

05

Den Zeitplan an den Rollout hängen

Schulung wirkt nur, wenn zwischen Lernen und Anwenden wenige Wochen liegen. Zu früh ist genauso teuer wie zu spät.

Zeitpunkte im Migrationsprojekt

ZeitpunktZielgruppeInhaltWarum genau dann
Sechs bis vier Monate vor dem RolloutAdministrationGrundlagen und SystemverwaltungDas Gelernte wird sofort in der Aufbauphase angewendet und dadurch gefestigt
Drei bis zwei Monate vorherAdministrationVertiefung zu den Diensten aus der InventurZu diesem Zeitpunkt sind die konkreten Fragen aus dem Aufbau da
Acht bis vier Wochen vorherMultiplikatoren im FachbereichUmstiegswissen und Koexistenz mit den AltsystemenDiese Gruppe braucht Vorsprung, um in der Rollout-Woche Fragen zu beantworten
Zwei Wochen vor bis zur Rollout-WocheAnwendendeKurze Einheiten am eigenen ArbeitsplatzDirekt danach wird täglich damit gearbeitet
Vier bis acht Wochen nach dem RolloutAdministrationNacharbeit, offene Fragen, ZertifizierungsvorbereitungErst der Betrieb zeigt, welche Lücken wirklich existieren
06

Wissen im Haus halten

Nach der Schulung entscheidet sich, ob das Wissen bleibt. Der Unterschied liegt selten am Kurs, sondern daran, ob es einen Ort gibt, an dem Erfahrung landet.

Runbooks als Git-Repository, nicht als Wiki-Wildwuchs
/srv/runbooks/
|- 00-notfall/        Passwort zurücksetzen, System bootet nicht, Restore
|- 10-dienste/        je Dienst eine Datei: Zweck, Abhängigkeiten, Neustart, Prüfung
|- 20-entscheidungen/ warum es so aufgebaut ist, welche Alternative verworfen wurde
|- 30-checklisten/    Neuinstallation, Ausmusterung, Patchtag

Git statt Wiki, weil du damit sehen kannst, wer wann was geändert hat, und weil Änderungen an Runbooks im selben Review landen wie Änderungen an der Konfiguration.

Welche Runbooks hat seit einem Jahr niemand angefasst?
cd /srv/runbooks
git log --since='1 year ago' --name-only --pretty=format: | sort -u > aktuell.txt
find . -name '*.md' -printf '%P\n' | sort > alle.txt
comm -23 alle.txt aktuell.txt

Die Ausgabe ist deine Agenda für den nächsten Wartungstag. Ein Runbook, das ein Jahr lang niemand angefasst hat, beschreibt entweder einen Dienst, den es nicht mehr gibt, oder es wird im Ernstfall nicht benutzt.

Vier Gewohnheiten, die den Effekt halten

  • Jede Störung endet mit einem Absatz im passenden Runbook.Sonst löst dieselbe Person denselben Fehler zum vierten Mal, und niemand sonst im Team kann es. Der Absatz kostet fünf Minuten, die Wiederholung kostet Stunden.
  • Wer Rufbereitschaft hat, arbeitet nach Runbook und korrigiert es dabei.Nur unter echter Last zeigt sich, ob die Anleitung stimmt. Gleichzeitig lernt jede Person im Turnus die Dienste der anderen kennen.
  • Zertifizierungen bekommen einen festen Prüfungstermin.Ohne Termin verschiebt sich das Lernen hinter das Tagesgeschäft. Der Termin ist das einzige Mittel, das zuverlässig wirkt.
  • Neu Gelerntes wird innerhalb von vier Wochen an einer echten Aufgabe angewendet.Wissen ohne Anwendung ist nach einem Quartal weitgehend weg. Plane deshalb schon vor der Schulung, welche Aufgabe die Person danach übernimmt.
Gut zu wissen

Häufige Fragen zu Linux-Qualifizierung im Team

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie lange dauert es, ein Admin-Team von Windows auf Linux umzuschulen?
Für die tragfähigen Grundlagen solltest du mit den vier Kursen LPI01 bis LPI04 rechnen, verteilt über etwa drei bis sechs Monate, damit zwischen den Blöcken Zeit zum Anwenden bleibt. Wenn es schneller gehen muss, bündelt das Linux BootCamp zum LPIC-1 den Stoff in einem zusammenhängenden Zeitraum, verlangt den Teilnehmenden dafür aber volle Freistellung ab.
Müssen wirklich alle Mitarbeiter geschult werden?
Nein, aber der Zuschnitt muss stimmen. Anwender brauchen einen kurzen, auf ihren Arbeitsplatz bezogenen Kurs zu Desktop, LibreOffice, Mail und Ablage. Nur die IT und die Multiplikatoren in den Fachbereichen brauchen echtes Systemwissen. Alle über denselben Kamm zu scheren kostet Budget und bringt bei keiner der beiden Gruppen das gewünschte Ergebnis.
Lohnt sich eine LPIC-1 Zertifizierung oder reicht das Wissen aus dem Kurs?
Für den reinen Betrieb reicht das Wissen aus den Kursen. Die Zertifizierung ist dann sinnvoll, wenn du einen belastbaren Nachweis brauchst, etwa gegenüber Auftraggebern, in Ausschreibungen oder zur internen Absicherung von Personalentscheidungen. Sie sorgt außerdem dafür, dass der Stoff vollständig und nicht nur entlang der eigenen Tagesarbeit gelernt wird.
Inhouse schulen oder Teilnehmende in offene Kurse schicken?
Bei mehr als etwa fünf Personen pro Thema ist Inhouse in der Regel wirtschaftlicher, und du kannst deine eigene Distribution, deine Namenskonventionen und deine Verzeichnisstruktur in die Übungen holen. Einzelne Spezialisten fahren mit offenen Terminen besser, weil sie flexibler planen können. Beides gibt es bei uns auch Live-Online, was besonders bei verteilten Standorten hilft.
Wie halten wir das Wissen nach der Schulung im Haus?
Plane feste Anwendungszeit ein und gib den geschulten Admins früh eigene Verantwortungsbereiche, etwa Paketpflege, Monitoring oder Backup. Ergänzend hilft eine interne Wissensbasis mit den wiederkehrenden Fällen aus dem Servicedesk. Ohne diese Übertragung in den Alltag verfällt frisch gelerntes Linux-Wissen innerhalb weniger Monate.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Lass uns deinen Schulungsplan durchgehen

Schick uns kurz, wie viele Anwender und wie viele Administratoren betroffen sind und welche Distribution ihr einsetzt. Wir schlagen dir eine Reihenfolge aus unseren bestehenden Kursen vor, sagen dir ehrlich, was Inhouse und was im offenen Termin sinnvoller ist, und rechnen dir den Aufwand pro Welle durch.