Meine 5-Jahres-Lern-Roadmap in der IT — vom Sysadmin zum Infrastructure Engineer

🌐 Auch auf: English · Français · Español

Linux. Windows. Netzwerk. Security. Observability. Automatisierung. Cloud. Kubernetes. KI.

Aber vor allem:

🧠 Systeme verstehen lernen — nicht nur bedienen.

Ich habe in letzter Zeit ziemlich viel darüber nachgedacht, wohin ich meine IT-Skills in den nächsten Jahren entwickeln will.

Mein beruflicher Hintergrund gibt mir schon eine recht breite Basis:

• 🐧 Linux-Systemadministration
• 📊 Monitoring
• 🚨 Technisches Event-Management
• 📝 Log-Management
• 🌐 Netzwerk
• 🔐 Security

Beruflich dreht sich bei mir aktuell immer mehr um Graylog und Log-Management.

Außerhalb der Arbeit interessiere ich mich außerdem stark für:

• Windows Server
• Active Directory
• Docker
• Kubernetes
• Git
• Automatisierung
• Betriebssysteme
• KI

Dazu habe ich ein ziemlich ordentliches Homelab aus drei physischen Servern und zwei Tower-PCs.

Die Frage ist also nicht wirklich:

„Welche Technologie soll ich als Nächstes lernen?“

Die viel spannendere Frage lautet:

„Was für ein Engineer will ich in den nächsten fünf Jahren werden?“

🎯 Das Ziel

Mein langfristiges Ziel ist nicht, derjenige zu werden, der die meisten Befehle kennt.

Es ist auch nicht, Zertifikate zu sammeln wie Pokémon.

Und schon gar nicht, jede neue Technologie zu lernen, die jeden Dienstag auf Hacker News auftaucht. 😄

Ich will mich zu jemandem entwickeln, der:

• komplexe Infrastruktur versteht
• Infrastruktur entwirft
• Infrastruktur betreibt
• Fehler in Infrastruktur findet
• Infrastruktur automatisiert
• Infrastruktur absichert
• Infrastruktur überwacht
• Abhängigkeiten versteht
• Ausfälle analysiert
• Architekturentscheidungen trifft
• Technologieentscheidungen bewertet
• KI effektiv als Engineering-Werkzeug einsetzt

Mit anderen Worten:

🏗️ Infrastructure Engineering

mit einem soliden Fundament in Linux, Windows, Netzwerk, Security, Observability, Automatisierung, Cloud und Cloud-native-Technologien.

🧠 Der wichtigste Teil: Wie ich lernen will

Das ist das Fundament der ganzen Roadmap.

Mein Lernansatz entfernt sich bewusst vom reinen Auswendiglernen.

Moderne Infrastruktur ist schlicht zu komplex, um jeden Befehl, jeden API-Parameter und jede Konfigurationsoption auswendig zu kennen.

Und mal ehrlich:

man systemctl
man kubectl
Get-Help
documentation
Google
ChatGPT
Claude

...exist for a reason. 😎

Deshalb will ich eine Abstraktionsebene nach oben wandern.

❌ Der alte Ansatz

Problem
   ↓
Remember command
   ↓
Run command
   ↓
Hope

✅ Der Ansatz, den ich entwickeln will

Problem
   ↓
Define the problem
   ↓
Understand the architecture
   ↓
Identify components
   ↓
Understand dependencies
   ↓
Collect evidence
   ↓
Form hypotheses
   ↓
Test hypotheses
   ↓
Find root cause
   ↓
Design solution
   ↓
Automate
   ↓
Document

Der eigentliche Befehl ist dann nur noch ein Teil des Prozesses.

Der Befehl ist das Werkzeug. Das Verständnis ist die Fähigkeit.

📐 Mein Lernmodell: die 20/30/30/20-Regel

Für die großen Themen dieser Roadmap strebe ich ungefähr diese Verteilung an:

Das ist keine starre mathematische Formel.

Es ist eine Erinnerung daran, wo der Schwerpunkt liegen sollte.

Wenn ich ein Thema abschließe und 200 Befehle kenne, aber nicht erklären kann, wie das System funktioniert, habe ich vermutlich das Falsche gelernt.

🔬 Der Lernzyklus

Jede größere Technologie soll denselben Zyklus durchlaufen.

1️⃣ Verstehen

Was ist das für eine Technologie?

2️⃣ Modellieren

Wie ist sie aufgebaut?

3️⃣ Bauen

Im Homelab ausrollen.

4️⃣ Beobachten

Ihr Verhalten überwachen und untersuchen.

5️⃣ Kaputtmachen

Absichtlich Fehler erzeugen.

6️⃣ Fehler suchen

Die Ursache systematisch finden.

7️⃣ Automatisieren

Wiederkehrende Arbeit in Code gießen.

8️⃣ Dokumentieren

Architekturdoku und Runbooks schreiben.

9️⃣ Erklären

Das System einem anderen Engineer erklären können.

🔟 Validieren

Zertifizierung, Praxistest oder ein echtes Projekt als letzter Checkpoint.

⏱️ Mein realistisches Zeitbudget pro Woche

Ich will nicht, dass diese Roadmap zum zweiten Vollzeitjob wird.

Ein realistischer Durchschnitt ist:

Ziel: etwa 5–8 Stunden pro Woche.

Vor einer Zertifizierung kann das vorübergehend mehr werden.

In stressigen Phasen auch weniger.

Wichtig ist die Beständigkeit auf lange Sicht.

🗺️ DIE FÜNFJAHRES-ROADMAP

2026
 │
 ├── Linux
 ├── Graylog
 ├── Git
 └── Ansible
       │
       ▼
2027
 │
 ├── Advanced Linux
 ├── Windows Server
 ├── Active Directory
 ├── Security
 └── Infrastructure Architecture
       │
       ▼
2028
 │
 ├── Terraform / OpenTofu
 ├── Infrastructure as Code
 ├── Kubernetes
 └── GitOps
       │
       ▼
2029
 │
 ├── Azure
 ├── Entra ID
 ├── Hybrid Cloud
 ├── Multi-RZ
 └── Disaster Recovery
       │
       ▼
2030
 │
 ├── Observability
 ├── OpenTelemetry
 ├── Platform Engineering
 ├── AI
 └── AIOps

🐧 JAHR 1 — Linux, Graylog, Git & Automatisierung

📅 Zeitraum: September 2026 – August 2027

Hauptziel: ein extrem solides Fundament in Systemen und Automatisierung aufbauen.

Geschätzter Aufwand: 5–8 Stunden/Woche.

🐧 Phase 1 — Linux für Fortgeschrittene / Systems Engineering

Dauer: etwa 6–9 Monate

Ziel: 120–180 Stunden

Themen, die ich beherrschen will

• Linux-Architektur
• Bootprozess
• systemd
• Prozesse und Threads
• Signale
• CPU-Scheduling
• Speicherverwaltung
• virtueller Speicher
• Dateisysteme
• LVM
• RAID
• ZFS
• Netzwerk
• DNS
• SSH
• Berechtigungen
• ACLs
• journald
• Logging
• Performance-Analyse
• Kernel-Grundlagen
• Security-Härtung

Besonders wichtig

Ich will verstehen, warum Linux sich so verhält, wie es sich verhält.

Zum Beispiel:

Warum ist der Server langsam?

Statt sofort wahllos Befehle abzufeuern, will ich lernen zu unterscheiden:

CPU?
RAM?
I/O?
Network?
Filesystem?
Process?
Kernel?
Application?
Dependency?
Configuration?

Zertifizierungs-Meilenstein

🎓 LFCS — Linux Foundation Certified System Administrator.

Alternative:

🎓 RHCSA, vor allem falls das Red-Hat-Ökosystem beruflich wichtiger wird.

Endziel

Gib mir einen kaputten Linux-Server, und ich finde systematisch die Ursache.

📊 Phase 2 — Graylog & Log-Management

Dauer: durchgehend in Jahr 1

Priorität: SEHR HOCH

Das ist meine aktuelle berufliche Spezialisierung.

Themen

• Graylog-Architektur
• Graylog-Nodes
• Data Nodes
• OpenSearch
• Shards
• Replicas
• Index Sets
• Streams
• Pipelines
• Parser
• Verarbeitung
• Retention
• Journal
• Fluent Bit
• Syslog
• GELF
• Fluent Forward
• Relays
• HA
• Kapazitätsplanung
• Performance
• Security-Logging
• Event-Erkennung

Zielarchitektur

Thousands of Servers
        │
        ▼
Agents / Syslog
        │
        ▼
Relay Tier
        │
        ▼
Graylog
        │
        ▼
OpenSearch
        │
        ▼
Hot / Cold Storage

Ich will berechnen können

• tägliches Ingest-Volumen
• Speicherbedarf
• Replikations-Overhead
• Retention
• Hot Storage
• Cold Storage
• Cluster-Dimensionierung
• Ausfallszenarien

Beruflicher Meilenstein

Eine produktionsreife zentrale Logging-Architektur entwerfen und verteidigen können.

🌱 Phase 3 — Git & Ansible

Dauer: 4–6 Monate

Git

• Repositories
• Branching
• Merging
• Rebasing
• Tags
• Pull Requests
• GitLab
• CI/CD-Grundlagen

Ansible

• Inventory
• Rollen
• Collections
• Variablen
• Templates
• Jinja2
• Vault
• Handler
• Idempotenz
• Testen
• AWX

Ziel

Manual configuration
       ↓
Ansible
       ↓
Git
       ↓
Version-controlled infrastructure
       ↓
Repeatable infrastructure

Ich will an den Punkt kommen, an dem ich denke:

„Wenn ich das zweimal von Hand konfigurieren muss, mache ich was falsch.“

🪟 JAHR 2 — Windows Server, Active Directory & Architektur

📅 Zeitraum: September 2027 – August 2028

Hauptziel: von der Linux-Administration in die Enterprise-Infrastruktur erweitern.

🪟 Phase 4 — Windows Server

Dauer: 4–6 Monate

Themen

• Windows-Server-Architektur
• Rollen und Features
• PowerShell
• Windows-Netzwerk
• Windows-Storage
• Windows-Clustering
• Windows-Ereignisprotokolle
• WinRM
• Dienste
• Performance-Analyse
• Security

🔐 Phase 5 — Active Directory

Dauer: 5–7 Monate

Themen

• AD DS
• Forest
• Domäne
• OU-Design
• Domain Controller
• FSMO-Rollen
• AD-Replikation
• Standorte & Dienste
• DNS
• Gruppenrichtlinien
• Kerberos
• LDAP
• SPNs
• Dienstkonten
• gMSA
• AD CS
• PKI
• AD-Security

Wichtige Verbindung zu Linux

                 Active Directory
                        │
             ┌──────────┼──────────┐
             │          │          │
            DNS      Kerberos     LDAP
             │          │          │
             └──────────┼──────────┘
                        │
              ┌─────────┴─────────┐
              │                   │
           Windows              Linux
              │                   │
             GPO             SSSD / PAM
          PowerShell          Kerberos
             WinRM               LDAP

Das Ziel ist nicht, Windows-Admin statt Linux-Admin zu werden.

Das Ziel ist, beide Welten und die Schnittstellen dazwischen zu verstehen.

Zertifizierungs-Meilenstein

🎓 Microsoft-Zertifizierungspfad Windows Server / Hybrid Administration.

Die genaue Prüfung wähle ich erst zu Beginn der Phase aus, weil Microsoft sein Zertifizierungsportfolio regelmäßig umbaut.

🏗️ Phase 6 — Infrastrukturarchitektur

Dauer: 6–12 Monate

Das ist eine der wichtigsten Phasen der ganzen Roadmap.

Themen

• Architekturmuster
• Hierarchie
• Dienstabhängigkeiten
• Failure Domains
• HA
• Redundanz
• Load Balancing
• Storage-Architektur
• Netzwerkarchitektur
• Multi-RZ
• Disaster Recovery
• RPO
• RTO
• Kapazitätsplanung
• Skalierbarkeit
• Backup-Architektur
• Security-Architektur
• Dokumentation

Großprojekt

Eine fiktive Enterprise-Infrastruktur entwerfen für:

• 5.000 Server
• Linux + Windows
• zwei Rechenzentren
• zentrales Logging
• zentrales Monitoring
• Identity-Dienste
• Security-Monitoring
• Backup
• HA
• DR

Ergebnisse:

• Architekturdiagramme
• Netzwerkdesign
• Abhängigkeitskarte
• HA-Konzept
• DR-Konzept
• Kapazitätsberechnung
• Security-Konzept
• Monitoring-Konzept
• Logging-Konzept

Diese Übung ist bewusst größer als ein normales Homelab-Projekt.

Das Ziel ist, wie ein Infrastrukturarchitekt denken zu lernen.

☁️ JAHR 3 — Infrastructure as Code & Kubernetes

📅 Zeitraum: September 2028 – August 2029

🏗️ Phase 7 — Terraform / OpenTofu

Dauer: 4–6 Monate

Themen

• Provider
• Ressourcen
• State
• Module
• Variablen
• Outputs
• Remote State
• Secrets
• CI/CD
• Infrastruktur-Lebenszyklus

Ziel

Git
 ↓
Infrastructure as Code
 ↓
Provisioning
 ↓
Ansible
 ↓
Configuration
 ↓
Monitoring
 ↓
Logging

Ich will den Unterschied klar verstehen zwischen:

• Provisionierung
• Konfigurationsmanagement
• Orchestrierung
• Application Deployment

☸️ Phase 8 — Kubernetes

Dauer: 8–12 Monate

Priorität: HOCH

Themen

• Control Plane
• API Server
• etcd
• Scheduler
• Controller
• kubelet
• Container-Runtime
• Netzwerk
• DNS
• Services
• Ingress
• Storage
• PVCs
• RBAC
• Secrets
• Helm
• Operators
• GitOps
• Flux
• Security
• Troubleshooting

Zertifizierungs-Meilensteine

🎓 CKA — Kubernetes-Administration.

Später:

🎓 CKS — Kubernetes-Security.

Die CKS reizt mich besonders, weil sie Kubernetes mit meinem bestehenden Security-Hintergrund verbindet.

☁️ JAHR 4 — Azure, Hybrid Cloud & Multi-RZ

📅 Zeitraum: September 2029 – August 2030

☁️ Phase 9 — Azure

Dauer: 6–9 Monate

Themen

• Azure-Architektur
• VNets
• Subnetze
• Routing
• NSGs
• Load Balancing
• VMs
• Storage
• Identity
• Security
• Monitoring
• Logging
• Governance
• Verfügbarkeit
• DR

Zertifizierungs-Meilenstein

🎓 AZ-104 — Azure Administrator Associate

Das passt gut in die Roadmap, weil es Azure-Compute, Storage, Netzwerk, Identity und Administration vereint.

🔑 Phase 10 — Entra ID & Hybrid Identity

Dauer: 3–5 Monate

On-Prem AD
    │
    │ Hybrid Identity
    ▼
Microsoft Entra ID
    │
    ▼
Azure
```

Themen:

• • Identity-Architektur

• • Authentifizierung

• • Autorisierung

• • Föderation

• • Hybrid Identity

• • Conditional Access

• • RBAC

• • Dienstidentitäten

• • Security

🏢 Phase 11 — Multi-RZ / Rechenzentrumsarchitektur

Dauer: 4–6 Monate

Diese Phase verbindet viele der vorherigen Themen.

                    Global Services
                           │
             ┌─────────────┴─────────────┐
             │                           │
            DC1                         DC2
             │                           │
      ┌──────┼──────┐             ┌──────┼──────┐
      │      │      │             │      │      │
   Compute Network Storage      Compute Network Storage
      │                           │
      └──────────────┬────────────┘
                     │
                 Services
                     │
          Monitoring / Logging / IAM

Themen

• Failure Domains
• Standortredundanz
• Load Balancing
• Replikation
• Backup
• RPO
• RTO
• DR
• Split Brain
• Quorum
• Netzwerkpartitionierung
• Dienstabhängigkeiten
• Kapazitätsplanung

Hier wird die frühere Architekturarbeit praktisch.

📡 JAHR 5 — Observability, Platform Engineering & KI

📅 Zeitraum: September 2030 – August 2031

📊 Phase 12 — Moderne Observability

Dauer: 4–6 Monate

                 Observability
                      │
          ┌───────────┼───────────┐
          │           │           │
       Metrics       Logs       Traces
          │           │           │
     Prometheus     Graylog   OpenTelemetry
          │           │           │
          └───────────┼───────────┘
                      │
                    Grafana

Themen

• Metriken
• Logs
• Traces
• Korrelation
• verteilte Systeme
• Prometheus
• Grafana
• Graylog
• OpenTelemetry
• Alerting
• Incident-Analyse

Das Ziel ist, wegzukommen von:

„Der Server ist rot.“

hin zu:

„Der kundenseitige Dienst ist eingebrochen, weil Abhängigkeit X Latenz hatte, nachdem Komponente Y Ressource Z aufgebraucht hat.“

🤖 Phase 13 — KI & AIOps

Dauer: fortlaufend

Themen

• LLMs
• Prompt Engineering
• KI-APIs
• RAG
• Embeddings
• Vektordatenbanken
• lokale LLMs
• KI-Agenten
• MCP
• KI-gestütztes Troubleshooting
• KI-gestützte Dokumentation
• KI-gestützte Automatisierung
• Incident-Korrelation
• AIOps

Beispiel

Monitoring Alert
       │
       ▼
Context Collection
       │
       ▼
AI Analysis
       │
       ▼
Possible Causes
       │
       ▼
Diagnostic Tests
       │
       ▼
Human Validation
       │
       ▼
Automation

KI soll mich schneller machen.

Sie soll mich nicht geistig faul machen.

🏠 Das Homelab — meine praktische Trainingsumgebung

Das Homelab ist ein wichtiger Teil der Roadmap, hat aber bewusst weniger Priorität als die eigentlichen Lernziele.

Der Lernplan kommt zuerst.

Das Homelab ist dazu da, aus Theorie praktische Erfahrung zu machen.

Meine Hardware:

• 🖥️ 3 physische Server
• 🖥️ 2 Tower-PCs

Das reicht locker für ein überraschend leistungsfähiges Infrastruktur-Labor.

🧪 Homelab-Regel Nr. 1

Nicht einfach Dienste laufen lassen. Szenarien bauen.

Statt:

„Ich habe einen Kubernetes-Cluster.“

will ich:

„Ich habe einen Kubernetes-Cluster gebaut, absichtlich einen Node abgeschossen, den Ausfall beobachtet, das Verhalten analysiert und die Wiederherstellung dokumentiert.“

Das ist eine völlig andere Lernerfahrung.

🖥️ Homelab-Einsatz nach Lernphase

💥 Das „Mach es absichtlich kaputt“-Programm

Einer der wichtigsten Teile des Homelabs wird sein, absichtlich Fehler zu erzeugen.

Beispiele:

• DNS kaputtmachen
• ein Dateisystem volllaufen lassen
• kritische Dienste stoppen
• Zertifikate kaputtmachen
• Netzwerkverbindung kappen
• Storage-Ausfälle simulieren
• Kubernetes-Nodes abschießen
• RBAC kaputtmachen
• Active-Directory-Replikation kaputtmachen
• Graylog-Ingest kaputtmachen
• übermäßiges Log-Volumen erzeugen
• Latenz einbauen
• Paketverlust simulieren

Danach:

Failure
  ↓
Symptoms
  ↓
Evidence
  ↓
Hypotheses
  ↓
Tests
  ↓
Root Cause
  ↓
Fix
  ↓
Prevention
  ↓
Documentation

Hier, schätze ich, passiert ein großer Teil des eigentlichen Lernens.

📚 Das Homelab soll Dokumentation produzieren

Jedes ernsthafte Projekt sollte etwas hinterlassen.

homelab/
│
├── ansible/
├── terraform/
├── opentofu/
├── kubernetes/
├── monitoring/
├── logging/
├── security/
├── networking/
│
├── architecture/
│   ├── network.md
│   ├── storage.md
│   ├── logging.md
│   ├── kubernetes.md
│   └── disaster-recovery.md
│
└── incidents/
    ├── dns-failure.md
    ├── storage-failure.md
    ├── ad-failure.md
    └── kubernetes-node-failure.md

So wird das Homelab zu einem praktischen Portfolio meiner Engineering-Arbeit.

🤖 KI als Teil des Lernprozesses

ChatGPT und Claude werden über alle fünf Jahre Teil des Workflows.

Aber auf den Workflow kommt es an.

Schlechter Workflow

Problem
 ↓
Ask AI
 ↓
Copy solution
 ↓
Done

Besserer Workflow

Problem
 ↓
My own hypothesis
 ↓
AI challenge
 ↓
Alternative hypotheses
 ↓
Diagnostic tests
 ↓
Evidence
 ↓
My decision
 ↓
Implementation
 ↓
Validation

Ein paar Fragen, die ich regelmäßig stellen will:

„Was übersehe ich?“

„Was sind drei plausible Ursachen?“

„Welcher Test würde diese Hypothesen unterscheiden?“

„Prüf deine vorherige Antwort kritisch.“

„Von welchen Annahmen gehst du aus?“

So wird KI zum technischen Sparringspartner statt zum Befehlsgenerator.

🏆 Zertifizierungsstrategie

Zertifizierungen sind nützlich, aber sie sollen die Roadmap bestätigen, nicht diktieren.

Die Regel ist einfach:

Keine Zertifizierung, nur weil es sie gibt.

Eine Zertifizierung sollte entweder:

• eine echte Wissenslücke schließen
• Struktur geben
• praktische Fähigkeiten bestätigen
• beruflich nützlich sein

Ansonsten ist das Projekt selbst vermutlich wertvoller.

📈 Die Kompetenzstufen

Ich will Fortschritt außerdem an Fähigkeiten messen und nicht nur an Zertifikaten.

Stufe 1 — Operator

Ich kann der Dokumentation folgen und das System betreiben.

Stufe 2 — Administrator

Ich verstehe die Konfiguration und kann typische Probleme beheben.

Stufe 3 — Engineer

Ich verstehe Architektur, Abhängigkeiten und Fehlerbilder.

Stufe 4 — Designer

Ich kann das System entwerfen und Architekturentscheidungen begründen.

Stufe 5 — Architekt

Ich kann komplexe Systeme über mehrere Technologien und Failure Domains hinweg entwerfen.

In der Fünfjahres-Roadmap geht es im Kern darum, sich zu bewegen von:

Operator
   ↓
Administrator
   ↓
Engineer
   ↓
Designer
   ↓
Architect

🧠 Was ich nach fünf Jahren können will

Stell dir vor, jemand gibt mir dieses Problem:

„Wir betreiben mehrere tausend Windows- und Linux-Systeme in mehreren Rechenzentren. Wir brauchen zentrales Identity-Management, Monitoring, Logging, Security, Automatisierung, Hochverfügbarkeit und Disaster Recovery. Entwirf die Plattform.“

Ich will fundiert nachdenken können über:

• Linux
• Windows
• Active Directory
• DNS
• Netzwerk
• Security
• Storage
• Logging
• Monitoring
• Observability
• Kubernetes
• Cloud
• Identity
• Automatisierung
• HA
• DR
• Kapazität
• Abhängigkeiten
• Failure Domains

Und vor allem:

Ich will verstehen, warum die Architektur so aussieht, wie sie aussieht.

🚀 Die Philosophie dahinter

Es wird immer eine weitere Technologie geben.

Ein weiteres Kubernetes-Release.

Eine weitere Cloud-Plattform.

Eine weitere Linux-Distribution.

Ein weiteres Monitoring-System.

Ein weiteres KI-Framework.

Eine weitere Zertifizierung.

Und einen weiteren Befehl, den ich morgen früh wieder vergessen habe.

Das ist okay.

Technologien ändern sich.

Engineering-Prinzipien ändern sich viel langsamer.

Systeme haben immer noch:

• Abhängigkeiten
• Schnittstellen
• Fehlerbilder
• Sicherheitsgrenzen
• Kapazitätsgrenzen
• Verfügbarkeitsanforderungen
• Datenflüsse
• betriebliche Randbedingungen

Genau da will ich meine Lernzeit investieren.

🐧 Weniger Befehle auswendig lernen.

🏗️ Mehr Architektur.

🔍 Mehr Troubleshooting.

🤖 Mehr Automatisierung.

☁️ Mehr Denken in Infrastruktur.

🧠 Mehr Verständnis.

Und ja …

Ich werde trotzdem gleichzeitig ein Terminal, einen Spickzettel, die Doku, ChatGPT und Claude offen haben.

Denn:

Ein guter Infrastructure Engineer zu sein heißt nicht, sich alles zu merken.

Es heißt zu wissen, was wichtig ist, wie man den Rest findet und wie man prüft, ob die Antwort tatsächlich stimmt.

😎 Dann lass es uns bauen. Und ab und zu kaputtmachen.