Linux. Windows. Networking. Security. Observability. Automation. Cloud. Kubernetes. AI.

But above all:

🧠 Learn to understand systems — not just to operate them.

I’ve been thinking quite a lot about where I want to take my IT skills over the next several years.

My professional background already gives me a fairly broad foundation:

• 🐧 Linux system administration
• 📊 Monitoring
• 🚨 Technical event management
• 📝 Log management
• 🌐 Networking
• 🔐 Security

My current professional focus is increasingly around Graylog and log management.

Outside of work, I also have a strong interest in:

• Windows Server
• Active Directory
• Docker
• Kubernetes
• Git
• Automation
• Operating systems
• AI

I also have a fairly capable homelab consisting of three physical servers and two tower PCs.

So the question isn’t really:

“What technology should I learn next?”

The much more interesting question is:

“What kind of engineer do I want to become over the next five years?”

🎯 The Goal

My long-term goal is not to become the person who knows the most commands.

It is not to collect certifications like Pokémon.

And it certainly isn’t to learn every new technology that appears on Hacker News every Tuesday. 😄

I want to develop into someone who can:

• understand complex infrastructure
• design infrastructure
• operate infrastructure
• troubleshoot infrastructure
• automate infrastructure
• secure infrastructure
• monitor infrastructure
• understand dependencies
• analyse failures
• make architectural decisions
• evaluate technology choices
• use AI effectively as an engineering tool

In other words:

🏗️ Infrastructure Engineering

with a strong foundation in Linux, Windows, networking, security, observability, automation, cloud and cloud-native technologies.

🧠 The Most Important Part: How I Want to Learn

This is the foundation of the entire roadmap.

My learning approach is deliberately moving away from pure memorization.

Modern infrastructure is simply too complex to memorize every command, every API parameter and every configuration option.

And honestly:

man systemctl
man kubectl
Get-Help
documentation
Google
ChatGPT
Claude

...exist for a reason. 😎

So I want to move one abstraction layer upwards.

❌ The old approach

Problem
   ↓
Remember command
   ↓
Run command
   ↓
Hope

✅ The approach I want to develop

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

The actual command becomes only one part of the process.

The command is a tool. The understanding is the skill.

📐 My Learning Model: The 20 / 30 / 30 / 20 Rule

For the major topics in this roadmap, I want approximately this distribution:

This isn’t a rigid mathematical formula.

It is a reminder of where the emphasis should be.

If I finish a topic knowing 200 commands but cannot explain how the system works, I probably learned the wrong thing.

🔬 The Learning Cycle

Every major technology should go through the same cycle.

1️⃣ Understand

What is the technology?

2️⃣ Model

How is it architected?

3️⃣ Build

Deploy it in the homelab.

4️⃣ Observe

Monitor and inspect its behaviour.

5️⃣ Break

Intentionally create failures.

6️⃣ Troubleshoot

Find the cause systematically.

7️⃣ Automate

Turn repetitive work into code.

8️⃣ Document

Create architecture documentation and runbooks.

9️⃣ Explain

Be able to explain the system to another engineer.

🔟 Validate

Use certification, practical testing or a real project as the final checkpoint.

⏱️ My Realistic Weekly Time Budget

I don’t want this roadmap to become another full-time job.

A realistic average is:

Target: approximately 5–8 hours per week.

Before a certification, this can temporarily increase.

During busy periods it can decrease.

The important thing is the long-term consistency.

🗺️ THE FIVE-YEAR 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

🐧 YEAR 1 — Linux, Graylog, Git & Automation

📅 Target: September 2026 – August 2027

Primary objective: Build an extremely solid systems and automation foundation.

Estimated effort: 5–8 hours/week.

🐧 Phase 1 — Advanced Linux / Systems Engineering

Duration: approximately 6–9 months

Target: 120–180 hours

Topics I want to master

• Linux architecture
• boot process
• systemd
• processes and threads
• signals
• CPU scheduling
• memory management
• virtual memory
• filesystems
• LVM
• RAID
• ZFS
• networking
• DNS
• SSH
• permissions
• ACLs
• journald
• logging
• performance analysis
• kernel fundamentals
• security hardening

Especially important

I want to understand why Linux behaves the way it does.

For example:

Why is the server slow?

Instead of immediately running random commands, I want to learn to distinguish:

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

Certification milestone

🎓 LFCS — Linux Foundation Certified System Administrator.

Alternative:

🎓 RHCSA, especially if the Red Hat ecosystem becomes more important professionally.

End goal

Give me a broken Linux server and I can systematically find the root cause.

📊 Phase 2 — Graylog & Log Management

Duration: continuous throughout Year 1

Priority: VERY HIGH

This is my current professional specialization.

Topics

• Graylog architecture
• Graylog nodes
• Data Nodes
• OpenSearch
• shards
• replicas
• index sets
• streams
• pipelines
• parsers
• processing
• retention
• journal
• Fluent Bit
• syslog
• GELF
• Fluent Forward
• relays
• HA
• capacity planning
• performance
• security logging
• event detection

Architecture target

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

I want to be able to calculate

• daily ingestion
• storage requirements
• replication overhead
• retention
• hot storage
• cold storage
• cluster sizing
• failure scenarios

Professional milestone

Be able to design and defend a production-grade centralized logging architecture.

🌱 Phase 3 — Git & Ansible

Duration: 4–6 months

Git

• repositories
• branching
• merging
• rebasing
• tags
• pull requests
• GitLab
• CI/CD basics

Ansible

• inventory
• roles
• collections
• variables
• templates
• Jinja2
• Vault
• handlers
• idempotency
• testing
• AWX

Goal

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

I want to reach the point where I think:

“If I have to configure this manually twice, I’m doing it wrong.”

🪟 YEAR 2 — Windows Server, Active Directory & Architecture

📅 Target: September 2027 – August 2028

Primary objective: Expand from Linux administration into enterprise infrastructure.

🪟 Phase 4 — Windows Server

Duration: 4–6 months

Topics

• Windows Server architecture
• roles and features
• PowerShell
• Windows networking
• Windows storage
• Windows clustering
• Windows Event Logs
• WinRM
• services
• performance analysis
• security

🔐 Phase 5 — Active Directory

Duration: 5–7 months

Topics

• AD DS
• Forest
• Domain
• OU design
• Domain Controllers
• FSMO roles
• AD replication
• Sites & Services
• DNS
• Group Policy
• Kerberos
• LDAP
• SPNs
• service accounts
• gMSA
• AD CS
• PKI
• AD security

Important Linux connection

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

The goal isn’t to become a Windows administrator instead of a Linux administrator.

The goal is to understand both worlds and the interfaces between them.

Certification milestone

🎓 Microsoft Windows Server / Hybrid Administration certification path.

The exact exam should be selected when entering the phase because Microsoft regularly updates its certification portfolio.

🏗️ Phase 6 — Infrastructure Architecture

Duration: 6–12 months

This is one of the most important phases in the entire roadmap.

Topics

• architecture patterns
• hierarchy
• service dependencies
• failure domains
• HA
• redundancy
• load balancing
• storage architecture
• network architecture
• Multi-RZ
• disaster recovery
• RPO
• RTO
• capacity planning
• scalability
• backup architecture
• security architecture
• documentation

Major project

Design a fictional enterprise infrastructure for:

• 5,000 servers
• Linux + Windows
• two data centers
• central logging
• central monitoring
• identity services
• security monitoring
• backup
• HA
• DR

Produce:

• architecture diagrams
• network design
• dependency map
• HA concept
• DR concept
• capacity calculation
• security concept
• monitoring concept
• logging concept

This exercise is deliberately larger than a normal homelab project.

The objective is to learn to think like an infrastructure architect.

☁️ YEAR 3 — Infrastructure as Code & Kubernetes

📅 Target: September 2028 – August 2029

🏗️ Phase 7 — Terraform / OpenTofu

Duration: 4–6 months

Topics

• providers
• resources
• state
• modules
• variables
• outputs
• remote state
• secrets
• CI/CD
• infrastructure lifecycle

Goal

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

I want to clearly understand the difference between:

• provisioning
• configuration management
• orchestration
• application deployment

☸️ Phase 8 — Kubernetes

Duration: 8–12 months

Priority: HIGH

Topics

• control plane
• API Server
• etcd
• scheduler
• controllers
• kubelet
• container runtime
• networking
• DNS
• Services
• Ingress
• storage
• PVCs
• RBAC
• Secrets
• Helm
• Operators
• GitOps
• Flux
• security
• troubleshooting

Certification milestones

🎓 CKA — Kubernetes administration.

Later:

🎓 CKS — Kubernetes security.

The CKS is particularly attractive because it combines Kubernetes with my existing security background.

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

📅 Target: September 2029 – August 2030

☁️ Phase 9 — Azure

Duration: 6–9 months

Topics

• Azure architecture
• VNets
• subnets
• routing
• NSGs
• load balancing
• VMs
• storage
• identity
• security
• monitoring
• logging
• governance
• availability
• DR

Certification milestone

🎓 AZ-104 — Azure Administrator Associate

This fits the roadmap well because it combines Azure compute, storage, networking, identity and administration.

🔑 Phase 10 — Entra ID & Hybrid Identity

Duration: 3–5 months

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

Topics:

• • identity architecture

• • authentication

• • authorization

• • federation

• • hybrid identity

• • conditional access

• • RBAC

• • service identities

• • security

🏢 Phase 11 — Multi-RZ / Data Center Architecture

Duration: 4–6 months

This phase combines many previous topics.

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

Topics

• failure domains
• site redundancy
• load balancing
• replication
• backup
• RPO
• RTO
• DR
• split brain
• quorum
• network partitioning
• service dependencies
• capacity planning

This is where the earlier architecture work becomes practical.

📡 YEAR 5 — Observability, Platform Engineering & AI

📅 Target: September 2030 – August 2031

📊 Phase 12 — Modern Observability

Duration: 4–6 months

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

Topics

• metrics
• logs
• traces
• correlation
• distributed systems
• Prometheus
• Grafana
• Graylog
• OpenTelemetry
• alerting
• incident analysis

The objective is to move from:

“The server is red.”

to:

“The customer-facing service degraded because dependency X experienced latency after component Y exhausted resource Z.”

🤖 Phase 13 — AI & AIOps

Duration: ongoing

Topics

• LLMs
• prompt engineering
• AI APIs
• RAG
• embeddings
• vector databases
• local LLMs
• AI agents
• MCP
• AI-assisted troubleshooting
• AI-assisted documentation
• AI-assisted automation
• incident correlation
• AIOps

Example

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

AI should make me faster.

It should not make me intellectually lazy.

🏠 The Homelab — My Practical Training Environment

The homelab is an important part of the roadmap, but it deliberately has less priority than the actual learning objectives.

The learning plan comes first.

The homelab exists to turn theory into practical experience.

My hardware:

• 🖥️ 3 physical servers
• 🖥️ 2 tower PCs

This is more than enough to create a surprisingly capable infrastructure laboratory.

🧪 Homelab Rule #1

Don’t just run services. Build scenarios.

Instead of:

“I have a Kubernetes cluster.”

I want:

“I built a Kubernetes cluster, intentionally killed a node, observed the failure, analysed the behaviour and documented the recovery.”

That’s a completely different learning experience.

🖥️ Homelab Usage by Learning Phase

💥 The “Break It On Purpose” Program

One of the most important parts of the homelab will be deliberately creating failures.

Examples:

• break DNS
• fill a filesystem
• stop critical services
• break certificates
• remove network connectivity
• simulate storage failures
• kill Kubernetes nodes
• break RBAC
• break Active Directory replication
• break Graylog ingestion
• create excessive log volume
• introduce latency
• simulate packet loss

Then:

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

This is where I expect a large part of the actual learning to happen.

📚 The Homelab Should Produce Documentation

Every serious project should leave something behind.

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

That turns the homelab into a practical portfolio of engineering work.

🤖 AI as Part of the Learning Process

ChatGPT and Claude become part of the workflow across all five years.

But the workflow is important.

Bad workflow

Problem
 ↓
Ask AI
 ↓
Copy solution
 ↓
Done

Better workflow

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

Some of the questions I want to use regularly:

“What am I missing?”

“What are three plausible root causes?”

“What test would distinguish these hypotheses?”

“Critically review your previous answer.”

“What assumptions are you making?”

This should make AI a technical sparring partner, rather than a command generator.

🏆 Certification Strategy

Certifications are useful, but they should validate the roadmap rather than dictate it.

The rule is simple:

No certification just because it exists.

A certification should either:

• fill a real knowledge gap
• provide structure
• validate practical skills
• be professionally useful

Otherwise, the project itself is probably more valuable.

📈 The Capability Levels

I also want to measure progress by capability rather than simply by certificates.

Level 1 — Operator

I can follow documentation and operate the system.

Level 2 — Administrator

I understand configuration and can troubleshoot common problems.

Level 3 — Engineer

I understand architecture, dependencies and failure modes.

Level 4 — Designer

I can design the system and justify architectural decisions.

Level 5 — Architect

I can design complex systems across multiple technologies and failure domains.

The five-year roadmap is essentially about moving from:

Operator
   ↓
Administrator
   ↓
Engineer
   ↓
Designer
   ↓
Architect

🧠 What I Want to Be Able to Do After Five Years

Imagine somebody gives me this problem:

“We operate several thousand Windows and Linux systems across multiple data centers. We need centralized identity, monitoring, logging, security, automation, high availability and disaster recovery. Design the platform.”

I want to be able to reason about:

• Linux
• Windows
• Active Directory
• DNS
• networking
• security
• storage
• logging
• monitoring
• observability
• Kubernetes
• cloud
• identity
• automation
• HA
• DR
• capacity
• dependencies
• failure domains

And most importantly:

I want to understand why the architecture looks the way it does.

🚀 The Final Philosophy

There will always be another technology.

Another Kubernetes release.

Another cloud platform.

Another Linux distribution.

Another monitoring system.

Another AI framework.

Another certification.

And another command that I will forget tomorrow morning.

That’s okay.

Technologies change.

Engineering principles change much more slowly.

Systems still have:

• dependencies
• interfaces
• failure modes
• security boundaries
• capacity limits
• availability requirements
• data flows
• operational constraints

That’s where I want to invest my learning effort.

🐧 Less command memorization.

🏗️ More architecture.

🔍 More troubleshooting.

🤖 More automation.

☁️ More infrastructure thinking.

🧠 More understanding.

And yes…

I’ll still have a terminal, a cheat sheet, documentation, ChatGPT and Claude open at the same time.

Because:

Being a good infrastructure engineer doesn’t mean remembering everything.

It means knowing what matters, knowing how to find the rest, and knowing how to determine whether the answer is actually correct.

😎 Now let’s build it. And occasionally break it.