Projekte und Werdegang

Azure-Plattform mit Landing Zones für zehn Teams

Ausgangslage

Die IT eines großen Handelskonzerns wollte zehn Produktteams eine gemeinsame Azure-Plattform bereitstellen, auf der jedes Team eigenständig arbeiten kann, ohne dass Governance, Security und Compliance in jedem Projekt neu erfunden werden. Gleichzeitig sollte die Bereitstellung neuer Kubernetes-Cluster von einem manuellen Vorgang zu einem reproduzierbaren Prozess werden.

Umsetzung

• Azure Landing Zones: Aufbau einer Management-Group-Hierarchie mit Subscriptions je Team und Umgebung. Azure Policy erzwingt Namenskonventionen, erlaubte Regionen, Tagging und Netzwerkregeln, Role-Based Access Control trennt Verantwortlichkeiten sauber. So entstehen Umgebungen, die Teams per Self-Service beziehen und die dennoch den Konzernvorgaben entsprechen.
• Terraform: Die gesamte Plattform, von Netzwerk und Identitäten bis zu den Kubernetes-Clustern, liegt als versionierte Terraform-Module vor. Neue Cluster entstehen aus denselben Modulen, Abweichungen zwischen Umgebungen sind ausgeschlossen. Das verkürzte die Bereitstellungszeit neuer Cluster erheblich.
• Kubernetes mit Istio: Das Service Mesh übernimmt mTLS zwischen Diensten, Traffic-Steuerung und einheitliche Telemetrie, ohne dass Anwendungsteams Netzwerklogik in ihren Code schreiben müssen.
• Observability mit OpenTelemetry und Datadog: Logs, Metriken und Traces werden über den OpenTelemetry Collector standardisiert erfasst und in Datadog zusammengeführt. Teams sehen einen Request über alle Dienste hinweg, was die mittlere Fehlerbehebungszeit (MTTR) um 20 Prozent gesenkt hat.
• GitOps mit Kuberpult und HashiCorp Vault: Releases wandern kontrolliert durch fünf Umgebungen. Kuberpult verwaltet, welche Version wo läuft, und macht Freigaben nachvollziehbar. Vault liefert Secrets zur Laufzeit, statt sie in Repositories oder Pipelines abzulegen.
• MongoDB und external-dns: Hochverfügbare MongoDB-Cluster wurden als Plattformdienst integriert. external-dns legt DNS-Einträge automatisch an, sobald ein Service veröffentlicht wird, und räumt sie wieder ab.
• KI-gestützte Entwicklung: Integration von KI-Werkzeugen in den Entwicklungsprozess für Code-Reviews, Qualitätsverbesserung und schnellere Umsetzung wiederkehrender Aufgaben in Infrastruktur-Code.
• Technische Führung: Definition der Architekturstandards, Moderation von Designentscheidungen und Coaching der Teams beim Übergang auf die neue Plattform.

• Azure
• Landing Zones
• Azure Policy
• Terraform
• Kubernetes
• Istio
• OpenTelemetry
• Datadog
• Kuberpult
• HashiCorp Vault
• MongoDB
• external-dns
• KI-Tooling

CI/CD und Automatisierung auf AWS

Ausgangslage

Ein großes Verkehrsunternehmen betrieb Anwendungen auf AWS ECS und EC2, deren Auslieferung und Konfiguration noch überwiegend manuell erfolgte. Wiederkehrende Betriebsaufgaben banden Personal, und Datenbanken sowie Zugangsdaten sollten nach einheitlichen Sicherheitsstandards verwaltet werden.

Umsetzung

• GitLab CI und AWS CloudFormation: Konzeption einer Pipeline, die Anwendung und Infrastruktur gemeinsam ausliefert. CloudFormation-Stacks beschreiben ECS-Services, Task Definitions, EC2-Ressourcen und Netzwerk; die Pipeline validiert Änderungen, erzeugt Change Sets und rollt sie kontrolliert aus. Konfiguration wird versioniert mitgeführt, statt auf Instanzen von Hand gepflegt.
• Lambda und Python: Manuelle Prozesse, etwa wiederkehrende Datenaufbereitungen und Betriebsroutinen, wurden als ereignisgesteuerte Lambda-Funktionen in Python umgesetzt. Das eliminierte rund zwei Wochen manuellen Aufwand.
• AWS RDS und Secrets Manager: Relationale Datenbanken laufen als verwaltete RDS-Instanzen mit Verschlüsselung im Ruhezustand und in der Übertragung. Zugangsdaten liegen im Secrets Manager, werden rotiert und zur Laufzeit von den Anwendungen abgerufen, nicht in Konfigurationsdateien.
• CloudWatch: Logs und Metriken aller Komponenten landen zentral in CloudWatch, mit Alarmen auf die relevanten Kennzahlen.

• AWS
• GitLab CI
• CloudFormation
• ECS
• EC2
• Lambda
• Python
• RDS
• Secrets Manager
• CloudWatch

CI/CD und GitOps über 15 Rancher-Kubernetes-Cluster

Ausgangslage

Ein kommunaler IT-Dienstleister betreibt für seine Kunden eine Vielzahl von Kubernetes-Clustern auf vSphere. Deployments sollten über alle Cluster hinweg einheitlich, nachvollziehbar und ohne manuelle Eingriffe erfolgen, mit zentraler Überwachung und einem gemeinsamen Identitätsdienst.

Umsetzung

• Rancher und Fleet: Rancher verwaltet die 15 Kubernetes-Cluster zentral. Fleet, Ranchers GitOps-Engine, überwacht Git-Repositories und bringt jeden Cluster in den dort beschriebenen Zustand. Cluster-Gruppen und Labels steuern, welche Workloads wohin ausgerollt werden, Abweichungen werden erkannt und korrigiert.
• GitLab CI, Terraform und Ansible: Terraform provisioniert die virtuellen Maschinen auf vSphere, Ansible richtet Betriebssystem und Cluster-Knoten ein, GitLab-Pipelines orchestrieren beides. Jede Änderung an der Infrastruktur läuft als Merge Request mit Review.
• Docker-Build-Pipelines: Container-Images entstehen reproduzierbar in der Pipeline, werden gescannt, versioniert und in einer Registry abgelegt, aus der Fleet sie bezieht.
• Python und Bash: Eigene Werkzeuge für Cluster-Wartung, Migrationen und Reporting ergänzen die Pipelines dort, wo Standardwerkzeuge nicht ausreichen.
• Grafana-Stack: Prometheus sammelt Metriken aller Cluster, Loki die Logs, Grafana führt beides in Dashboards zusammen. Alerts gehen an die zuständigen Teams.
• Keycloak: Bereitstellung und Wartung von Keycloak als zentralem Identitätsdienst mit SAML und OAuth für Rancher, Grafana und Anwendungen, mit sauberer Rollen- und Gruppenzuordnung.

• Rancher
• Fleet
• GitLab CI
• Terraform
• Ansible
• vSphere
• Docker
• Python
• Bash
• Grafana
• Prometheus
• Loki
• Keycloak

Hybride OpenShift-Plattform über zwei Standorte

Ausgangslage

Eine Bank mit hohen regulatorischen Anforderungen wollte kritische Anwendungen ausfallsicher betreiben und dafür ein eigenes Rechenzentrum mit der Public Cloud kombinieren, ohne zwei getrennte Plattformen mit unterschiedlichen Prozessen zu bekommen.

Umsetzung

• On-Premises OpenShift und Azure Red Hat OpenShift: Beide Cluster wurden nach demselben Bauplan aufgesetzt, sodass Anwendungen ohne Anpassung an beiden Standorten laufen. Der Cloud-Cluster dient als zweiter Standort für fünf kritische Anwendungen.
• GitLab, Terraform und Ansible: Terraform provisioniert die Azure-Ressourcen, Ansible die On-Premises-Seite, GitLab-Pipelines führen beides zusammen. Die Plattform selbst ist damit versionskontrolliert und jederzeit nachbaubar.
• Ansible, Helm und OpenShift Lifecycle Manager: Plattformdienste und Operatoren werden über OLM installiert und aktualisiert, Anwendungen über Helm-Charts, der Rollout ist mit Ansible automatisiert.
• GitOps mit ArgoCD und Cluster-API: ArgoCD hält beide Cluster synchron zum Git-Zustand. Cluster-API beschreibt die Cluster selbst deklarativ, sodass auch der Lebenszyklus der Plattform per GitOps gesteuert wird.
• Red Hat Data Foundation: Persistenter Speicher auf Basis von Rook und Ceph, damit Anwendungen mit Zustand an beiden Standorten laufen können.
• Kyverno: Sicherheitsrichtlinien als Code, etwa erlaubte Registries, Ressourcenlimits und Pod-Security-Vorgaben, werden vom Cluster erzwungen statt nur dokumentiert.
• Dynatrace und OpenTelemetry: Standortübergreifendes Monitoring mit Traces über beide Cluster, damit Ausfälle und Latenzen dort sichtbar werden, wo sie entstehen.
• Keycloak: Benutzer und Gruppen werden zwischen Keycloak und OpenShift synchronisiert, Berechtigungen folgen damit zentral gepflegten Gruppen.

• Red Hat OpenShift
• Azure Red Hat OpenShift
• GitLab
• Terraform
• Ansible
• Helm
• OLM
• ArgoCD
• Cluster-API
• Rook / Ceph
• Kyverno
• Dynatrace
• OpenTelemetry
• Keycloak

Azure-Infrastruktur als Code mit AKS

Ausgangslage

Eine Landesbank baute ihre Azure-Nutzung aus und brauchte eine belastbare Grundlage, um Kubernetes-Umgebungen wiederholbar bereitzustellen. Offen war zudem, ob Azure-Ressourcen künftig direkt aus Kubernetes heraus verwaltet werden sollten.

Umsetzung

• Terraform-Module: Entwicklung wiederverwendbarer Module für Netzwerk, AKS-Cluster, Identitäten und Plattformdienste, mit klaren Schnittstellen und Versionierung, damit Teams sie ohne Spezialwissen einsetzen können.
• GitHub und Helm: Infrastruktur-Änderungen laufen als Pull Requests mit automatischem Plan und Review über GitHub Actions. Plattformkomponenten auf AKS werden per Helm ausgerollt.
• Azure Service Operator: Evaluierung, ob Azure-Ressourcen wie Datenbanken oder Storage als Kubernetes-Objekte verwaltet werden sollten. Ergebnis war eine fundierte Empfehlung mit Abgrenzung zu Terraform, inklusive Bewertung von Reifegrad, Betriebsaufwand und Sicherheitsaspekten.

• Azure
• AKS
• Terraform
• Helm
• GitHub
• Azure Service Operator

CI/CD mit GitLab, Terraform, AWS und ArgoCD

Ausgangslage

Eine Bank entwickelte Java- und Node.js-Anwendungen für mehrere OpenShift-Cluster und wollte Infrastruktur, Anwendungskonfiguration und Auslieferung nach einem einheitlichen, revisionssicheren Prinzip verwalten.

Umsetzung

• GitOps als Betriebsmodell: Der Sollzustand jeder Umgebung liegt in Git. Änderungen erfolgen ausschließlich über Merge Requests, was für eine Bank auch die Anforderungen an Nachvollziehbarkeit und Vier-Augen-Prinzip erfüllt.
• Terraform auf AWS: Die zugrunde liegende Infrastruktur wird definitionsgesteuert bereitgestellt und ist als Stufe in die Pipeline eingebunden, sodass Infrastruktur- und Anwendungsänderungen gemeinsam getestet werden.
• GitLab CI: Build, Tests, Image-Erstellung und Bereitstellung der Java- und Node.js-Anwendungen laufen automatisiert, mit Umgebungsstufen und Freigaben.
• ArgoCD: Rollt Anwendungen anhand des Repositories auf die OpenShift-Cluster aus, erkennt Drift und stellt den Sollzustand wieder her.
• Eigene Ansible-Module in Python: Für Aufgaben, die kein Standardmodul abdeckt, wurden eigene Module entwickelt, mit Idempotenz und Tests, damit sie sich wie Bordmittel verhalten.
• Grafana-Dashboards als Code: Dashboards für Metriken und Leistungsdaten liegen ebenfalls im Repository und werden per GitOps ausgerollt, damit alle Cluster dieselbe Sicht haben.

• AWS
• GitLab CI
• Terraform
• ArgoCD
• OpenShift
• Ansible
• Python
• Grafana
• Java
• Node.js

Zentrale Logging-Lösung für Java- und Node.js-Anwendungen

Ausgangslage

Ein Hersteller von Verkehrstechnik betrieb Anwendungen auf Kubernetes, deren Logs verteilt und schwer auswertbar waren. Fehleranalyse bedeutete, sich durch einzelne Container zu arbeiten.

Umsetzung

• Loki und Promtail: Loki speichert Logs indexiert nach Labels und damit kostengünstig und skalierbar, Promtail sammelt sie von allen Knoten ein. Abfragen laufen über Grafana, mit denselben Labels wie die Metriken.
• Banzai Logging Operator: Log-Flüsse werden als Kubernetes-Ressourcen beschrieben: welche Namespaces, welche Filter, welches Ziel. Der Operator konfiguriert die Sammlung daraus automatisch, neue Anwendungen sind ohne manuelle Konfiguration angebunden.
• Log-Appender und Kafka: Für Java-Anwendungen wurde Logback so konfiguriert, dass strukturierte Logs entstehen, Node.js-Anwendungen erhielten ein passendes Gegenstück. Ein Kafka-Pfad entkoppelt Erzeugung und Verarbeitung, sodass Lastspitzen keine Logs verlieren.

• Loki
• Promtail
• Banzai Logging Operator
• Kafka
• Logback
• Spring Boot
• Node.js
• Grafana

Rancher-Umgebungen auf OpenStack mit eigenem Keycloak-Operator

Ausgangslage

Für einen Kunden im öffentlichen Sektor sollte eine Microservices-Plattform auf einem OpenStack-Cluster entstehen, mit getrennten Umgebungen für Entwicklung, Test, Pre-Produktion und Produktion und einem Betrieb, der ohne Handarbeit auskommt.

Umsetzung

• Ansible und OpenStack: Ansible provisioniert Netze, Instanzen und Volumes in OpenStack und installiert darauf Rancher und die Kubernetes-Cluster. Alle vier Umgebungen entstehen aus demselben Code, unterschieden nur durch Variablen.
• Gitea und Jenkins: Gitea als selbst gehostete Git-Plattform, Jenkins-Pipelines für Build, Test und Auslieferung, beides innerhalb der Kundenumgebung, wie es die Anforderungen des öffentlichen Sektors verlangen.
• Helm, ArgoCD, Kustomize und Operatoren: Anwendungen werden als Helm-Charts paketiert, per Kustomize je Umgebung angepasst und von ArgoCD nach GitOps-Prinzip ausgerollt. Plattformdienste laufen als Operatoren.
• Eigener Keycloak-Management-Operator: Mit dem Ansible Operator Framework entstand ein Operator, der Keycloak-Instanzen, Realms und Clients über eine Custom Resource Definition verwaltet. Teams beschreiben, was sie brauchen, der Operator setzt es um und hält es konsistent.
• RabbitMQ: Der Message Broker der Microservices wird über den RabbitMQ Operator bereitgestellt, skaliert und gewartet.
• Grafana-Stack: Prometheus für Metriken, Loki und Promtail für Logs, Grafana für Dashboards und Alerts über alle vier Umgebungen.

• Rancher
• OpenStack
• Ansible
• Gitea
• Jenkins
• Helm
• ArgoCD
• Kustomize
• Ansible Operator Framework
• Keycloak
• RabbitMQ
• Grafana
• Prometheus
• Loki

OpenShift-Plattformen als Infrastructure as Code für sicherheitskritische Kunden

Ausgangslage

Als Architekt bei einem IT-Dienstleister habe ich mehrere Kunden im öffentlichen Dienst mit sicherheitskritischen Anforderungen betreut. Gemeinsamer Nenner: OpenShift-Plattformen, die vollständig aus Code entstehen und deren Betrieb nachweisbar kontrolliert ist.

Umsetzung

• Ansible, AWX und Terraform: Terraform und Ansible beschreiben die Infrastruktur, AWX führt Playbooks zentral, protokolliert und mit Berechtigungen aus. So ist jeder Eingriff dokumentiert, was in sicherheitskritischen Umgebungen Pflicht ist.
• OpenShift auf VMware: Reproduzierbarer Aufbau eines hochperformanten Clusters mit Puppet und Ansible als Grundlage für die Anwendungslandschaft eines Kunden im öffentlichen Dienst.
• GitOps mit ArgoCD und OpenShift-Operatoren: Plattformdienste und Anwendungen werden aus Git ausgerollt, Operatoren übernehmen den Lebenszyklus von Kafka, Storage und Identitätsdienst.
• Red Hat Data Foundation: Persistenter Speicher auf Rook und Ceph, betrieben mit Blick auf Ausfallsicherheit und Datenschutz.
• Strimzi Kafka: Kafka als zentrales Nachrichtensystem, per Operator verwaltet, mit Topics und Zugriffsrechten als Code.
• Keycloak: Authentifizierung per OAuth mit User- und Group-Sync, sodass Berechtigungen in OpenShift zentral gepflegten Gruppen folgen.
• Elastic-Stack, Grafana und Thanos: Logs im Elastic-Stack, Metriken mit Prometheus, langfristig und clusterübergreifend gespeichert über Thanos, Auswertung in Grafana.

• OpenShift
• Ansible
• AWX
• Terraform
• Puppet
• VMware
• ArgoCD
• Operatoren
• Rook / Ceph
• Strimzi Kafka
• Keycloak
• Elastic-Stack
• Grafana
• Thanos

Plattformbetrieb für über 300 Server und mandantenfähiges IDM

Ausgangslage

Ein Softwarehersteller betreibt seine Produkte für Kunden selbst. Mit dem Wachstum stieg die Zahl der Systeme auf über 300 Server und virtuelle Maschinen. Die Infrastruktur sollte vom manuell gepflegten Bestand zu einer als Code beschriebenen, automatisierten Plattform werden, inklusive einer zentralen Anmeldung für alle Kunden.

Umsetzung

• Terraform, Proxmox, KVM und VMware: Virtuelle Maschinen entstehen aus Terraform-Definitionen, gleich ob auf Proxmox, KVM oder VMware. Der Bestand ist damit dokumentiert, reproduzierbar und im Fehlerfall schnell wiederherstellbar.
• GitLab CI: Gemeinsam mit den Entwicklerteams wurden CI/CD-Konzepte eingeführt: automatisierte Builds, Tests und Auslieferung statt manueller Releases.
• Rancher und Docker: Kubernetes-Rollouts wurden über Rancher automatisiert, Anwendungen in Container überführt und einheitlich betrieben.
• Keycloak-IDM: Aufbau eines mandantenfähigen Identitätsdienstes für über 10.000 Nutzer, mit getrennten Realms je Kunde, Single Sign-on und Anbindung der Produkte.
• Elastic-Stack, Ceph und MariaDB/Galera: Zentrale Logs und Suche im Elastic-Stack, gemeinsamer Speicher auf Ceph, hochverfügbare Datenbanken als Galera-Cluster.
• Firewalls: Netzwerksicherheit mit Cisco, strongSwan für VPN-Verbindungen und Shorewall auf Linux-Systemen, mit dokumentierten Regelwerken.

• Terraform
• Proxmox
• KVM
• VMware
• GitLab CI
• Rancher
• Docker
• Keycloak
• Elastic-Stack
• Ceph
• MariaDB / Galera
• Cisco
• strongSwan
• Shorewall

Vom Monolithen zur Microservices-Architektur

Ausgangslage

Das Kernprodukt des Herstellers war als Monolith gewachsen. Skalierung, Releases und Wartung wurden zunehmend aufwendig. Ziel war eine flexible, skalierbare Microservices-Struktur auf eigener Infrastruktur, ergänzt um Cloud-Dienste dort, wo sie Vorteile bringen.

Umsetzung

• Domänenschnitt: Identifikation der fachlichen Domänen im Monolithen, die als eigenständige Services funktionieren, und schrittweise Herauslösung, damit das Produkt während der Migration lauffähig bleibt.
• Rancher, Helm und Kubernetes auf Proxmox: Jeder Service erhält eine eigene Helm-Chart, Rancher verwaltet die Kubernetes-Workloads. Deployments sind damit reproduzierbar, Skalierung erfolgt je Service.
• Spring Boot und Service Discovery: Die Services basieren auf Spring Boot, die interne Kommunikation läuft über Kubernetes Service Discovery mit Load Balancing und Routing ohne eigene Verzeichnisdienste.
• ActiveMQ: Asynchrone Kommunikation zwischen den Services über einen zentralen Message Broker, was Kopplung reduziert und die Reaktionsfähigkeit der Gesamtanwendung verbessert.
• AWS S3, SNS und SES: S3 als skalierbarer Objektspeicher, SNS für Benachrichtigungen zwischen Services, SES für zuverlässigen E-Mail-Versand.
• Elasticsearch: Cluster als NoSQL-Datenbank für große Mengen an Protokolldaten sowie für Such- und Analysefunktionen. Dazu eine Backup- und Disaster-Recovery-Strategie mit regelmäßigen Snapshots und ein Performance-Tuning, bei dem Shards und Replicas je Index auf Datenlast und Ausfallsicherheit abgestimmt wurden.

• Kubernetes
• Rancher
• Helm
• Proxmox
• Spring Boot
• ActiveMQ
• AWS S3 / SNS / SES
• Elasticsearch
• Backup & DR

Migration von AD, Exchange und Skype for Business zu Microsoft 365

Ausgangslage

Die On-Premises-Infrastruktur des Unternehmens, 2012 von mir aufgebaut und bis zur letzten verfügbaren Version 2019 aktuell gehalten, umfasste Active Directory, Exchange und Skype for Business (vormals Lync) mit Asterisk-Telefonie. Ziel war der vollständige Umzug in die Cloud mit Microsoft 365 und Teams, ohne Unterbrechung des Arbeitsalltags.

Umsetzung

1. Analyse und Vorbereitung: Bestandsaufnahme der AD-, Exchange- und Skype-Umgebung, Bewertung der Versionen und Aktualisierung auf die neuesten Releases als Voraussetzung für eine saubere Hybridphase.
2. Migrationsplan: Detaillierter Plan für Benutzerdaten, Postfächer, Gruppen und Konferenzlösungen, mit Reihenfolge, Rollback-Optionen und Kommunikation an die Anwender.
3. Active Directory: Schrittweise, abgesicherte Übernahme von Benutzern, Gruppen und Richtlinien in die Cloud-Identität.
4. Exchange Online: Postfachmigration bei durchgehender Datenintegrität und Verfügbarkeit, Anpassung von Mail-Routing und Sicherheitsrichtlinien.
5. Teams: Ablösung von Skype for Business durch Microsoft Teams für Chat, Konferenzen und Zusammenarbeit.
6. Telefonie: Die frühere Asterisk-Integration für Skype for Business wurde durch einen Session Border Controller für Teams ersetzt, sodass das bestehende Telefoniesystem weiter nutzbar blieb.
7. Mailsicherheit: Absicherung des Mailverkehrs mit DKIM, DMARC und SPF, damit Zustellbarkeit und Schutz vor Absenderfälschung nach dem Umzug gewährleistet sind.
8. Betrieb, Schulung, Dokumentation: Laufende Überwachung und Optimierung der Microsoft-365-Umgebung, Schulung der Anwender und vollständige Dokumentation aller Schritte und Konfigurationen.

• Active Directory
• Exchange Online
• Microsoft Teams
• Skype for Business
• Asterisk
• Session Border Controller
• DKIM / DMARC / SPF

Second-Level-Support für Cisco-Netzwerke und Firewalls

Ausgangslage

Bei einem großen IT-Dienstleister im Telekommunikationsumfeld war ich im Second-Level-Support für die Netzwerkinfrastruktur von Unternehmenskunden zuständig.

Umsetzung

• Cisco-Switche: Analyse und Behebung von Störungen in Switching-Infrastrukturen, VLAN- und Port-Konfiguration, Änderungen nach Change-Prozess mit Dokumentation.
• Firewalls: Bearbeitung von Regelwerksänderungen und Störungen, Nachvollziehen von Verbindungsproblemen über Logs und Paketanalysen, Eskalation an den Third-Level mit sauber aufbereiteten Befunden.

• Cisco
• Switching
• Firewalls
• VLAN
• ITIL-Prozesse

Betrieb eines Supercomputers und der Institutsinfrastruktur

Ausgangslage

Ein universitäres Institut für numerische Simulation betrieb einen eigenen Supercomputer für rechenintensive Forschung. Der Betrieb musste stabil laufen, damit Rechenzeit für die Wissenschaft nicht verloren geht.

Umsetzung

• HPC-Betrieb: Überwachung und Wartung des Rechenclusters, Knotenverwaltung, Job-Scheduling und Unterstützung der Wissenschaftler bei der Nutzung.
• Webserver und Lizenzsysteme: Betrieb der Webserver des Instituts und der Lizenzserver für wissenschaftliche Software.
• Backup: Aufbau und Betrieb der Sicherungssysteme für Forschungsdaten, mit regelmäßigen Wiederherstellungstests.

• HPC
• Linux
• Cluster-Betrieb
• Webserver
• Lizenzserver
• Backup

Netzwerk- und Active-Directory-Infrastruktur für Unternehmenskunden

Ausgangslage

Bei zwei IT-Systemhäusern habe ich für kleine und mittlere Unternehmen die komplette IT-Infrastruktur aufgebaut und betreut, vom Netzwerk bis zum Verzeichnisdienst.

Umsetzung

• Netzwerk: Planung und Aufbau von LAN-Infrastrukturen, Switching, Routing und Internetanbindung, inklusive Firewall und Fernzugriff.
• Active Directory und Windows Server: Aufbau von Domänen, Gruppenrichtlinien, Datei- und Druckdiensten sowie Mailsystemen, mit Migrationen zwischen Server-Generationen.
• Betrieb und Support: Wartung, Monitoring, Backup und Anwendersupport, mit dem Anspruch, dass Kunden ihre IT nicht bemerken müssen.

• Active Directory
• Windows Server
• Netzwerk
• Firewall
• Backup
• Support

Studium und Ausbildung

• Sportmedizintechnik, Hochschule für Angewandte Wissenschaften, Remagen (2009 bis 2011)
• Informatik / Bio-Medical Computer Science, Hochschule für Angewandte Wissenschaften, Bonn (2006 bis 2009)
• Informationstechnischer Assistent, Heinrich-Hertz-Berufskolleg, Bonn (2002 bis 2005)

Zertifizierungen

• Certified Kubernetes Administrator (CKA), The Linux Foundation, 2021
• Certified Kubernetes Application Developer (CKAD), The Linux Foundation, 2022
• ITIL® 4 Foundation, PeopleCert, 2021
• MCSE Messaging & Productivity, MCSA Windows Server, Microsoft