Welche Probleme löse ich – und für wen?

Thorsten Geppert

Ich werde immer wieder gefragt, was ich eigentlich genau mache. Die kurze Antwort: Ich entwickle Software und administriere Systeme, vornehmlich unter FreeBSD. Die längere Antwort ist dieser Beitrag.

Meine Arbeit bewegt sich im Spannungsfeld zwischen Softwareentwicklung, Infrastruktur und Systemarchitektur. Ich helfe dabei, Systeme zu bauen oder zu stabilisieren, die langfristig funktionieren – technisch sauber, verständlich und wartbar.

Softwareentwicklung: Qualität statt Fließband

In meinen Blog-Artikeln über Softwareentwicklung habe ich viel darüber geschrieben, was in Unternehmen schief läuft: unlesbarer Code, fehlende Architektur, technische Schulden, die niemand mehr anfasst, und ein Fokus auf Prozesse statt auf das Produkt selbst. Das ist keine abstrakte Kritik, sondern Dinge, die ich über viele Jahre hinweg in verschiedenen Unternehmen hautnah erlebt habe.

Daraus folgt, was ich anbiete: saubere, lesbare, wartbare Software. Code, den auch jemand anderes in fünf Jahren noch versteht. Ich habe langjährige Erfahrung in verschiedenen Programmiersprachen – von der systemnahen Programmierung bis hin zu komplexen GUI-Anwendungen mit Qt und wxWidgets. Datenbanken (insbesondere PostgreSQL) gehören ebenso dazu wie Server-Client-Architekturen und Netzwerkprogrammierung.

Wenn du ein Projekt hast, das aus dem Ruder gelaufen ist, das von einer Einzelperson entwickelt wurde und jetzt kaum noch jemand durchblickt, oder das dringend eine saubere Neuarchitektur braucht – dann bin ich die richtige Ansprechperson.

FreeBSD-Administration: Stabil, sicher, durchdacht

FreeBSD begleitet mich seit Version 4, also seit über zwei Jahrzehnten. Ich betreibe eigene Server damit, kenne ZFS mit RAIDz, FreeBSD-Jails, Bhyve, pf, CARP, HAST und die gängigen Netzwerkdienste (DNS, DHCP, NTP, NFS, Samba, LDAP u.v.m.) aus der täglichen Praxis – nicht nur aus der Dokumentation.

Was ich löse: Du brauchst einen stabilen, sicheren Server oder eine skalierbare Serverinfrastruktur unter FreeBSD? Du möchtest Dienste in Jails isolieren? Du hast ein laufendes System, das Pflege oder Erweiterung braucht? Oder du stehst vor einem konkreten Problem, das sich partout nicht lösen lässt? Ich bin mit solchen Situationen vertraut – und finde pragmatische Lösungen.

Für Unternehmen

Falls du als Unternehmen schaust: Ich bringe Softwareentwicklung und Systemadministration zusammen. Ich bin kein Spezialist, der nur eine Schraube dreht, sondern jemand, der Systeme im Ganzen versteht. Ich habe in Firmen gearbeitet, in denen beides gefragt war, und weiß, wie wichtig es ist, dass Entwicklung und Infrastruktur zusammenpassen.

Ich schätze eine Unternehmenskultur, in der Fehler als Lernmöglichkeit begriffen werden, Kompetenzen sinnvoll eingesetzt werden und das Produkt im Mittelpunkt steht – nicht das Verwalten von Tickets. Wenn das auch dein Ansatz ist, sollten wir sprechen (E-Mail: thorsten@tgeppert.de).

Hier meine Referenzen in Kurzform

Thorsten Geppert

Lebenslauf

OpenSource-Projekte

Verschiedenes

  • YouTube-Kanal (mit Themen über Programmierung, FreeBSD und verschiedene andere Dinge)

Warum viele IT-Infrastrukturen unnötig komplex geworden sind

Thorsten Geppert Schreib einen Kommentar

Es gibt einen Moment, der in fast jeder IT-Abteilung irgendwann kommt. Etwas geht schief — ein Dienst fällt aus, eine Datenbank ist nicht erreichbar, eine Anmeldung funktioniert nicht — und niemand kann erklären, warum. Nicht, weil die Leute inkompetent sind. Sondern weil niemand mehr versteht, wie die Systeme zusammenhängen. Die Infrastruktur ist gewachsen, nicht geplant. Und was gewachsen ist, hat Wurzeln, die niemand kennt.

Das ist kein Einzelfall. Es ist der Normalfall.

Einleitung

Viele IT-Landschaften sind über Jahre gewachsen. Jedes Mal, wenn ein neues Problem auftrat, wurde ein neues System eingeführt. Jedes Mal, wenn ein Dienstleister wechselte, brachte er seine eigenen Tools mit. Jedes Mal, wenn eine Abteilung eine Lösung brauchte, kaufte sie eine — ohne die anderen zu fragen. Das Ergebnis ist eine Infrastruktur, die zwar funktioniert — aber kaum noch jemand vollständig versteht.

Die Komplexität ist nicht das Ergebnis von Dummheit. Sie ist das Ergebnis von Hunderten einzelnen Entscheidungen, die im Moment alle sinnvoll waren. Jedes neue Tool löste ein Problem. Jede neue Integration brachte einen Mehrwert. Jede neue Plattform hatte ihre Berechtigung. Aber die Summe dieser Entscheidungen ist eine Landschaft, in der niemand den Überblick hat.

Und das ist gefährlich. Nicht weil es unordentlich ist — sondern weil es fehleranfällig ist. Jede Abhängigkeit, die niemand kennt, ist eine Fehlermöglichkeit, die niemand testen kann. Jede Konfiguration, die nur eine Person versteht, ist ein Single Point of Failure, der nicht in der Architektur, sondern im Personal liegt.

Wie Infrastruktur langsam unwartbar wird

Komplexität entsteht nicht über Nacht. Sie schleicht sich ein, Entscheidung für Entscheidung, Tool für Tool, Migration für Migration. Es ist ein schleichender Prozess, den man im Moment selten bemerkt — und im Nachhinein kaum noch rekonstruieren kann.

Phase 1: Das grüne Feld

Am Anfang ist alles einfach. Ein Server, eine Anwendung, eine Datenbank. Alles ist überschaubar. Die Admins kennen jedes System, jede Konfiguration, jeden Cron-Job. Änderungen sind trivial, weil die Auswirkungen vorhersehbar sind.

In dieser Phase wird oft der Grundstein für spätere Komplexität gelegt — durch Entscheidungen, die für den Moment passen, aber nicht skalieren. Eine Quick-and-Dirty-Integration hier, ein Workaround dort, ein Skript, das „nur temporär“ ist und dann fünf Jahre läuft.

Phase 2: Das Wachstum

Die Firma wächst. Neue Mitarbeiter, neue Abteilungen, neue Anforderungen. Jede Anforderung bringt ein neues System:

  • Marketing braucht ein CMS. Also wird eines eingeführt.
  • Vertrieb braucht ein CRM. Also wird eines gekauft.
  • Entwicklung braucht CI/CD. Also wird ein Pipeline-System aufgesetzt.
  • HR braucht ein Onboarding-Tool. Also wird eines abonniert.

Jedes dieser Systeme ist isoliert betrachtet sinnvoll. Aber niemand fragt: Wie integriert es sich in das Bestehende? Wer betreibt es? Wer dokumentiert es? Was passiert, wenn der SaaS-Anbieter seinen Service einstellt?

In dieser Phase verdoppelt sich die Komplexität — nicht weil die Systeme kompliziert sind, sondern weil die Verbindungen zwischen ihnen wachsen. Jedes neue System braucht Authentifizierung, braucht Daten-Synchronisation, braucht Monitoring, braucht Backup. Und jede dieser Verbindungen ist eine neue Abhängigkeit.

Phase 3: Die Ablagerungen

Alte Systeme werden nicht abgeschafft. Sie werden ergänzt. Das alte CMS läuft weiter, weil drei Seiten noch darauf basieren. Das alte CRM läuft weiter, weil der Vertrieb die alten Daten braucht. Das alte Mail-System läuft weiter, weil die Compliance-Abteilung die Archivierung braucht.

Niemand traut sich, etwas abzuschalten, weil niemand weiß, was davon abhängt. Also läuft alles weiter — das Alte und das Neue, nebeneinander, mit Brücken, Workarounds und Cron-Jobs, die Daten zwischen Systemen hin- und herschieben, die niemand mehr versteht.

Phase 4: Die Unwartbarkeit

Irgendwann ist der Punkt erreicht, an dem niemand mehr die Infrastruktur vollständig versteht. Die Dokumentation ist lückenhaft, veraltet oder existiert gar nicht. Das Wissen steckt in den Köpfen von drei Personen — und wenn eine davon in Urlaub ist, kann niemand den Dienst restarten, der seit zwei Jahren nicht mehr neu gestartet wurde und dessen Start-Skript einen Bug hat, der beim Neustart zu einem Datenverlust führt.

In dieser Phase passieren die Dinge, die Karrieren beenden: Produktionsausfälle, die Tage dauern. Datenverluste, die nicht wiederhergestellt werden können. Security-Lücken, die monatelang unentdeckt bleiben, weil niemand das System patchen kann, ohne das Ganze zum Absturz zu bringen.

Typische Symptome

Die Symptome einer überkomplexen Infrastruktur sind universell. Sie zeigen sich in jeder Firma, die diesen Weg gegangen ist — unabhängig von Größe, Branche oder Technologie-Stack.

Systeme hängen voneinander ab — und niemand weiß wie

Das Authentifizierungssystem ist mit dem LDAP verbunden, das LDAP repliziert in die Cloud, die Cloud synchronisiert mit dem HR-System, das HR-System triggert einen Webhook, der einen Workflow in einer Automatisierungs-Plattform startet, die ein Ticket im Ticketsystem erstellt, das eine E-Mail über den Relay-Server verschickt, der auf einem alten Postfix läuft, den niemand angefasst hat, seit 2019.

Wenn der Relay-Server ausfällt, funktioniert das Onboarding nicht mehr. Aber niemand verbindet den Ausfall eines Mail-Servers mit einem Onboarding-Problem, weil die Kette zu lang ist und nicht dokumentiert wurde.

Dokumentation fehlt

Die Dokumentation existiert in drei Zuständen: gar nicht, veraltet oder falsch. Die einzige verlässliche Dokumentation ist die Infrastruktur selbst — und die ist undokumentiert. Wenn jemand wissen will, wie ein System konfiguriert ist, muss er sich auf dem Server anmelden und nachschauen. Und wenn der Server nicht mehr erreichbar ist, ist die Konfiguration auch nicht mehr erreichbar.

Updates machen Angst

Updates sollten Routine sein. In einer komplexen Infrastruktur sind sie ein Risiko. Nicht, weil die Updates selbst gefährlich sind, sondern weil niemand weiß, welche Abhängigkeiten bestehen. Was passiert, wenn ich die Datenbank aktualisiere? Breche ich die Anwendung, die darauf zugreift? Breche ich den Dienst, der die Daten repliziert? Breche ich den Cron-Job, der die Daten jeden Nacht exportiert?

Die Antwort ist oft: „Wir machen die Updates, wenn es nicht mehr anders geht.“ Und das bedeutet: Sicherheitslücken bleiben offen, weil die Angst vor Nebenwirkungen größer ist als die Angst vor der Lücke.

Know-how steckt in Einzelpersonen

Es gibt in jeder Firma die Person, die alles weiß. Die seit 15 Jahren dabei ist. Die weiß, dass Server X nur hochfährt, wenn Service Y manuell gestartet wird, weil das Init-Skript einen Bug hat. Die weiß, dass die Datenbank auf Server Z nie neu gestartet werden darf, weil die Replikation sonst aus dem Takt kommt. Die weiß, dass der Cron-Job um 3 Uhr morgens nicht verschoben werden darf, weil er mit dem Backup auf Server W kollidiert.

Wenn diese Person kündigt, geht das Wissen. Nicht das dokumentierte Wissen — das existiert ja nicht. Das implizite Wissen, das in Jahren der Trial-and-Error-Erfahrung entstanden ist. Und das ist das teuerste Wissen, weil es das einzige ist, das die Infrastruktur am Laufen hält.

Warum das passiert

Die Ursachen für überkomplexe Infrastruktur sind nicht technisch. Sie sind organisatorisch, kulturell und ökonomisch.

Kurzfristige Entscheidungen

Die meisten Systeme wurden eingeführt, weil ein akutes Problem gelöst werden musste. Der Vertrieb brauchte sofort ein CRM — also wurde eines gekauft, schnell, ohne Integrationsplan. Die Entwickler brauchten sofort CI/CD — also wurde ein System aufgesetzt, das funktioniert, aber nicht in die bestehende Infrastruktur passt.

Kurzfristige Entscheidungen sind nicht falsch. Sie werden falsch, wenn sie nicht langfristig korrigiert werden. Wenn das „temporäre“ System drei Jahre später immer noch läuft, ist es nicht mehr temporär — aber die Architektur wurde nie an die neue Realität angepasst.

Tool-getriebene IT

Viele IT-Abteilungen entscheiden nicht über Architektur, sondern über Tools. Ein Problem wird identifiziert, ein Tool wird evaluiert, das Tool wird eingeführt. Die Frage „Wie passt das in unsere Gesamtarchitektur?“ wird selten gestellt — oft, weil es keine Gesamtarchitektur gibt.

Das Ergebnis ist eine Landschaft von Insellösungen, die jeweils ihr eigenes Problem lösen, aber zusammen ein neues Problem schaffen: Komplexität. Jedes Tool hat seine eigene Konfiguration, seine eigenen Abhängigkeiten, seine eigene Update-Politik, seine eigene Art, Dinge zu tun. Die Überschneidungen sind enorm — aber niemand sieht sie, weil jeder nur sein eigenes Tool kennt.

Fehlende Architektur

Architektur ist nicht das, was am Ende dazukommt. Architektur ist das, was am Anfang stehen sollte. Die Frage ist nicht: „Welches Tool löst unser Problem?“ Die Frage ist: „Wie soll unsere Infrastruktur aussehen, damit sie unsere Anforderungen erfüllt — heute und in drei Jahren?“

Fehlende Architektur bedeutet: Jede Entscheidung wird isoliert getroffen. Jede Lösung ist eine Punkt-Lösung. Das Gesamtbild entsteht nicht durch Planung, sondern durch Ablagerung. Wie Sedimentgestein — Schicht auf Schicht, ohne Struktur, ohne Plan.

Externe Dienstleister ohne Gesamtblick

Externe Dienstleister sind nicht per se ein Problem. Sie werden zum Problem, wenn sie keinen Anreiz haben, die Gesamtarchitektur zu verbessern. Ihr Job ist es, ihr Teil zu betreiben — nicht, die Integration mit dem Rest zu verstehen.

Das Ergebnis: Ein Dienstleister betreibt die Mail-Infrastruktur. Ein anderer das Monitoring. Ein dritter die Backup-Lösung. Und wenn etwas zwischen den Systemen schiefgeht, ist es niemandes Verantwortung. Jeder sagt: „Mein Teil funktioniert.“ Und trotzdem funktioniert das Ganze nicht.

Die absurde Vielfalt — Beispiele aus der Praxis

Um zu verstehen, wie Komplexität entsteht, reicht es, sich alltägliche Bereiche anzusehen, in denen die Tool-Vielfalt aus dem Ruder gelaufen ist.

Kommunikation

Unternehmen nutzen gleichzeitig:

  • E-Mail — weil jeder E-Mail hat und es formell ist
  • Microsoft Teams — weil der Vertrieb es fordert
  • Mattermost — weil die Entwickler Slack nicht bezahlen wollen
  • Signal — weil manche Vertraulichkeit brauchen
  • Wire — weil der Vorstand Ende-zu-Ende-Verschlüsselung will
  • Telefon — weil manche Leute einfach anrufen

Sechs Kanäle für Kommunikation. Keiner ist der offizielle. Die Frage „Wo wurde das besprochen?“ hat keine Antwort, weil die Antwort sein kann: In der E-Mail, im Teams-Chat, im Mattermost-Kanal, in der Signal-Gruppe, im Wire-Anruf oder am Telefon. Entscheidungen sind verteilt über sechs Systeme, und niemand hat den Überblick.

Die Lösung wäre: Einen Kanal für Formelles (E-Mail), einen für Kollaboration (ein einziges Chat-System), einen für Vertrauliches (verschlüsselt). Drei Systeme, klar getrennt, klar dokumentiert. Stattdessen: Sechs Systeme, überlappend, niemand zuständig.

Datenablage

Unternehmen nutzen gleichzeitig:

  • SMB/NFS-Share — weil es schon immer da war
  • OneDrive — weil Microsoft 365 es mitbringt
  • Nextcloud — weil Datenschutz wichtig ist
  • SharePoint — weil der Vertrieb Dokumenten-Workflows braucht
  • Git-Repositories — weil Entwickler Konfigurationen versionieren
  • S3-Buckets — weil die Cloud-Anwendungen Speicher brauchen

Sechs Speicherorte für Daten. Keiner ist der offizielle. Die Frage „Wo ist das Dokument?“ hat keine Antwort, weil die Antwort sein kann: Auf dem Share, in OneDrive, in Nextcloud, in SharePoint, im Git-Repo oder im S3-Bucket. Versionen sind verteilt, Zugriffsrechte sind inkonsistent, Backups sind fragmentiert.

Die Lösung wäre: Einen primären Speicher für Dokumente, einen für Konfigurationen, einen für Objekte. Drei Systeme, klar getrennt, klar dokumentiert.

Identitätsmanagement

Unternehmen nutzen gleichzeitig:

  • Active Directory — weil Windows
  • LDAP — weil Linux
  • Keycloak — weil OAuth
  • Azure AD — weil Cloud
  • GitHub Organizations — weil Entwicklung
  • SaaS-eigene Benutzerdatenbanken — weil jedes Tool seine eigene Auth hat

Sechs Identitätsquellen. Keine ist die autoritative. Wenn ein Mitarbeiter geht, muss er in sechs Systemen deaktiviert werden — und wenn eines vergessen wird, hat er weiterhin Zugriff. Wenn ein Passwort geändert werden muss, muss es in sechs Systemen geändert werden — und wenn eines vergessen wird, ist es ein Sicherheitsrisiko.

Die Lösung wäre: Ein Identitäts-Provider. EINE Quelle der Wahrheit. Alle anderen Systeme delegieren an diesen Provider. Aber das erfordert Architektur, und Architektur erfordert, dass jemand die Entscheidung trifft und sie durchsetzt.

Monitoring

Unternehmen nutzen gleichzeitig:

  • Nagios — weil es schon immer lief
  • Prometheus + Grafana — weil die Entwickler es eingeführt haben
  • Datadog — weil der Cloud-Migration-Berater es empfohlen hat
  • Zabbix — weil der Linux-Admin damit angefangen hat
  • CloudWatch — weil die AWS-Services es mitbringen

Fünf Monitoring-Systeme. Fünf Dashboards. Fünf Alerting-Ketten. Wenn etwas ausfällt, gehen die Alerts in fünf verschiedene Richtungen, und niemand weiß, welches Dashboard die Wahrheit zeigt. Das Monitoring ist so komplex wie die Infrastruktur, die es überwachen soll — und deshalb überwacht es sie nicht mehr effektiv.

Warum „noch ein Tool“ selten hilft

Die häufigste Reaktion auf ein Infrastruktur-Problem ist: ein neues Tool. Das Ticket-System ist zu kompliziert? Wir führen ein neues ein. Das Monitoring zeigt nicht die richtigen Metriken? Wir installieren ein neues. Die Kommunikation ist chaotisch? Wir evaluieren eine neue Plattform.

Das Problem ist nicht das Tool. Das Problem ist die Komplexität. Und ein neues Tool erhöht die Komplexität, es reduziert sie nicht.

Das Werkzeug-Fetischismus-Problem

Die IT-Branche hat ein instrumentelles Verhältnis zu Werkzeugen. Jedes Problem hat ein Tool, das es löst. Jedes Tool hat eine Evaluierung, eine Einführung, eine Lernkurve. Und jedes Tool fügt eine weitere Abhängigkeit hinzu, eine weitere Konfiguration, eine weitere Update-Pflicht, eine weitere Schnittstelle.

Was fehlt, ist nicht ein weiteres Tool. Was fehlt, ist die Entscheidung, welche Tools man nicht braucht. Die Reduktion der Komplexität beginnt nicht mit einer neuen Lösung — sie beginnt mit dem Abbau der alten.

Der Sunk-Cost-Fehler

„Wir haben so viel Geld in System X investiert, wir können es nicht abschaffen.“ Das ist der Sunk-Cost-Fehler. Das Geld ist ausgegeben. Die Frage ist nicht, ob die Investition sich lohnt — sie ist weg. Die Frage ist, ob das System heute einen Mehrwert bietet, der die Komplexität rechtfertigt, die es verursacht. Wenn die Antwort nein ist, muss es weg. Unabhängig davon, wie viel es gekostet hat.

Das Integrations-Paradoxon

Jedes neue Tool verspricht Integration. „Verbindet sich mit allem!“ steht auf der Website. Und das stimmt — es verbindet sich mit allem. Aber jede Integration ist eine neue Abhängigkeit. Jede Schnittstelle ist eine neue Fehlermöglichkeit. Das Tool, das alle Probleme löst, indem es sich mit allem verbindet, löst sein eigenes Problem — und schafft zehn neue.

Warum einfache Systeme stabiler sind

Weniger bewegliche Teile

Jedes System, jeder Dienst, jede Integration, jede Konfiguration ist ein bewegliches Teil. Und bewegliche Teile können kaputtgehen. Die Wahrscheinlichkeit eines Ausfalls steigt mit der Anzahl der Komponenten — nicht linear, sondern exponentiell, weil die Wechselwirkungen zwischen den Komponenten schneller wachsen als die Komponenten selbst.

Zehn Server, die voneinander abhängen, haben nicht zehn Fehlermöglichkeiten. Sie haben bis zu 45 möglichen Paar-Abhängigkeiten und hunderte von Kaskaden-Effekten. Wenn Server A ausfällt, kann das Server B beeinträchtigen, was Server C zum Stillstand bringt, der die Datenbank D zum Timeout bringt, die den Cache E zum Überlaufen bringt, der den Load Balancer F zum Ausfall bringt, der den gesamten Traffic auf Server G leitet, der nicht für diese Last dimensioniert ist.

Einfache Systeme haben weniger bewegliche Teile. Weniger Abhängigkeiten. Weniger Fehlermöglichkeiten. Das ist keine Philosophie — es ist Mathematik.

Verständlichkeit als Stabilitätsfaktor

Ein System, das jemand versteht, kann repariert werden. Ein System, das niemand versteht, kann nur neu gestartet werden. Und neu starten ist keine Reparatur — es ist eine Vertagung des Problems.

Einfache Systeme sind verständlich. Jeder Administrator kann erklären, wie sie funktionieren. Jeder Administrator kann abschätzen, was passiert, wenn eine Komponente ausfällt. Jeder Administrator kann das System dokumentieren, weil die Komplexität der Dokumentation proportional zur Komplexität des Systems ist.

Komplexe Systeme sind unverständlich — nicht weil die Admins nicht schlau genug sind, sondern weil die kognitive Kapazität des Menschen begrenzt ist.

Der Beweis: Einfache Systeme in der Praxis

Die stabilsten Systeme, die die IT-Geschichte hervorgebracht hat, sind einfache Systeme:

  • SMTP — ein einfaches Protokoll, das seit über 40 Jahren funktioniert
  • DNS — ein hierarchisches Namenssystem, das das Internet trägt
  • HTTP — ein zustandsloses Request-Response-Protokoll, das das Web ermöglicht hat
  • Unix-Philosophie — ein Programm, eine Aufgabe, gut gemacht
  • ZFS — ein Storage-System, das Datenintegrität, Snapshots und Replikation vereint, ohne dass man 15 separate Tools braucht

Diese Systeme sind nicht einfach, weil sie primitiv sind. Sie sind einfach, weil sie das Richtige abstrahieren und das Falsche weglassen. Ihre Stabilität resultiert nicht aus Komplexität — sie resultiert trotz fehlender Komplexität.

Wie man Infrastruktur wieder stabil bekommt

Systeme reduzieren

Der erste Schritt ist nicht, etwas hinzuzufügen. Der erste Schritt ist, etwas wegzunehmen.

Inventar erstellen. Jedes System, jeder Dienst, jede Integration dokumentieren. Wer betreibt es? Wer nutzt es? Wann wurde es zuletzt angefasst? Gibt es eine Dokumentation? Gibt es einen Verantwortlichen?

Kategorisieren. Welche Systeme sind kritisch? Welche sind wichtig? Welche sind nice-to-have? Welche laufen, weil sie schon immer laufen?

Abschaffen. Jedes System, das nicht mehr genutzt wird oder dessen Funktion von einem anderen System erfüllt wird, wird abgeschaltet. Nicht in einem Jahr. Nicht nach der nächsten Release. Jetzt.

Konsolidieren. Drei Chat-Systeme werden eins. Fünf Monitoring-Lösungen werden eine. Vier Speicherorte werden zwei. Das bedeutet Kompromisse. Nicht jeder bekommt sein Lieblings-Tool. Aber jeder bekommt eine Infrastruktur, die funktioniert.

Klare Verantwortlichkeiten

Jedes System hat genau einen Verantwortlichen. Nicht zwei. Nicht eine Gruppe. Einen. Der Verantwortliche ist nicht derjenige, der alles macht — er ist derjenige, der weiß, wer was macht und ob es gemacht wird.

Ohne klare Verantwortlichkeiten passiert das, was immer passiert: Jeder denkt, der andere ist zuständig. Und am Ende ist niemand zuständig. Die Verantwortlichkeit muss benannt sein, nicht implizit. Wenn der Verantwortliche Urlaub hat, muss es eine Vertretung geben — eine Person, nicht ein Team.

Saubere Dokumentation

Dokumentation ist kein Afterthought. Sie ist Teil des Setups. Jedes System wird mit Dokumentation eingeführt, nicht danach. Die Dokumentation umfasst:

  • Was ist das? Name, Zweck, Abhängigkeiten
  • Wie hängt es zusammen? Architektur-Diagramm, Datenflüsse, Schnittstellen
  • Wie wird es betrieben? Update-Prozedur, Backup-Prozedur, Restore-Prozedur
  • Was passiert bei Ausfall? Failover, Recovery-Time-Objective, Verantwortlicher
  • Wie wird es ersetzt? Migrationsszenario, Alternativen, Daten-Export

Die Dokumentation wird versioniert, gepflegt und regelmäßig überprüft. Veraltete Dokumentation ist schlimmer als keine Dokumentation — weil sie falsches Vertrauen erzeugt.

Robuste Plattformen statt Fragmente

Die Wahl der Plattform ist eine der wichtigsten Architektur-Entscheidungen. Und die Entscheidung sollte auf Stabilität, Einfachheit und Langfristigkeit fallen — nicht auf Hype, Feature-Liste oder Marketing-Budget.

FreeBSD + ZFS ist ein Beispiel für eine Plattform, die Komplexität reduziert, statt sie zu addieren:

  • ZFS vereint Dateisystem, Volume-Manager, RAID, Snapshot-Management, Replikation, Kompression und Caching in einem System. Statt separate Tools für RAID (mdadm), LVM, Snapshot (LVM-snapshot), Backup (Bacula/Borg) und Caching (bcache) zu betreiben, hat man alles in einem. Weniger Systeme. Weniger Komplexität. Mehr Stabilität.
  • FreeBSD bietet ein kohärentes Betriebssystem — nicht eine Sammlung von Paketen, die jemand zusammengebaut hat. Das Basis-System und die Ports sind getrennt. Updates sind vorhersehbar. Das System ist auf Stabilität ausgelegt, nicht auf das neueste Feature.
  • pkgbase (seit FreeBSD 15) aktualisiert das Basis-System wie ein Paket-Manager. Kein freebsd-update mehr, keine manuellen Patches. Das System ist einheitlich, konsistent und automatisierbar.
  • jails bieten Isolation ohne den Overhead von Containern. Ein Jail ist eine leichtgewichtige, sichere Isolation, die keine eigene Kernel-Instanz braucht und in Sekunden erstellt oder geklont werden kann.

Robuste Plattformen sind nicht die mit den meisten Features. Sie sind die mit den wenigsten Überraschungen.

Der Weg zurück zur Einfachheit

Einfachheit ist kein Zustand. Einfachheit ist eine Entscheidung, die man jeden Tag treffen muss. Bei jedem Tool, das evaluiert wird. Bei jedem System, das eingeführt wird. Bei jeder Integration, die gebaut wird. Die Frage ist nicht: „Können wir das machen?“ Die Frage ist: „Müssen wir das machen? Und wenn ja: Was nehmen wir dafür weg?“

Die Rückkehr zur Einfachheit ist kein Sprint. Es ist ein Marathon. Es dauert Monate oder Jahre, eine überkomplexe Infrastruktur zu reduzieren. Aber jeder Schritt zählt. Jedes System, das abgeschafft wird, reduziert die Angriffsfläche. Jede Integration, die vereinfacht wird, reduziert die Fehlermöglichkeiten. Jede Dokumentation, die geschrieben wird, reduziert das Single-Point-of-Failure-Risiko im Personal.

Der erste Schritt ist die Inventur. Der zweite ist die Entscheidung. Der dritte ist die Konsequenz.

Und die Konsequenz lautet: Weniger ist mehr. Nicht als Buzzword, sondern als Architekturprinzip.

Fazit

IT muss nicht kompliziert sein. Sie wird kompliziert, wenn Architektur fehlt. Wenn jede Entscheidung isoliert getroffen wird. Wenn jedes Problem mit einem neuen Tool gelöst wird, statt die Ursache zu adressieren. Wenn kurzfristige Lösungen zu langfristigen Belastungen werden.

Die Infrastruktur ist das Fundament. Wenn das Fundament instabil ist, stürzt alles ein, was darauf aufbaut — egal wie modern die Werkzeuge sind, die man darauf installiert hat. Die stabilsten Systeme der Welt sind nicht die mit den meisten Features. Sie sind die mit der klarsten Architektur. Die mit den wenigsten Abhängigkeiten. Die, die man erklären kann, ohne ein Whiteboard voll zu zeichnen.

Die Wahl der Plattform entscheidet mit darüber, ob Komplexität entsteht oder vermieden wird. FreeBSD mit ZFS ist eine Entscheidung für Einfachheit: ein Betriebssystem, das auf Stabilität designed ist, ein Dateisystem, das Storage-Management integriert statt zu fragmentieren, eine Infrastruktur, die man verstehen kann, weil sie nicht aus hundert Einzelteilen besteht, die niemand mehr überschaut.

Die Frage ist nicht, ob man die Komplexität reduzieren kann. Die Frage ist, ob man es tut, bevor die Komplexität die Infrastruktur reduziert — auf einen Haufen Systeme, die niemand mehr versteht, niemand mehr betreibt und niemand mehr reparieren kann.

Es ist Zeit, Einfachheit ernst zu nehmen. Nicht als Buzzword. Als Architekturprinzip.

Digitale Souveränität: Warum On-Premise wieder relevant wird

Thorsten Geppert Schreib einen Kommentar

Zehn Jahre lang war die Antwort auf fast jede IT-Frage dieselbe: Cloud. Neue Applikation? Cloud. Altes System migrieren? Cloud. Storage wächst? Cloud. Skalierung nötig? Cloud. Die Cloud war nicht nur eine Technologie — sie war eine Ideologie. „Cloud-first“ stand in den Strategiepapieren von Unternehmen, die nicht einmal verstanden hatten, was „first“ in diesem Kontext bedeutet.

Jetzt, zehn Jahre später, kommt die Ernüchterung. Nicht bei allen, aber bei vielen. Die Rechnungen sind da. Die Abhängigkeiten sind da. Die Fragen, die man hätte stellen sollen, bevor man migriert hat, sind immer noch da — nur dass sie jetzt teurer zu beantworten sind.

Einleitung

Die Migration in die Cloud war die dominierende IT-Strategie der letzten Dekade. Getrieben von Versprechen wie „unbegrenzter Skalierung“, „pay-as-you-go“ und „Zero Administration“ haben Unternehmen aller Größen Systeme, Daten und Prozesse in die Cloud verlagert — oft ohne die langfristigen Konsequenzen zu verstehen.

Heute beginnt eine Gegenbewegung. Nicht weil die Cloud gescheitert ist — sie hat ihre Vorteile —, sondern weil die Unternehmen, die in den letzten Jahren massiv in die Cloud gewandert sind, feststellen, dass die versprochene Einfachheit mit einem Preis kommt, der nicht nur finanziell ist.

Die Frage ist nicht mehr: „Cloud oder nicht?“ Die Frage ist: „Wofür Cloud, wofür On-Premise, und wie beides so kombinieren, dass die Souveränität über die eigenen Daten und Prozesse erhalten bleibt?“

Die Cloud-Revolution — und was sie wirklich verändert hat

Was die Cloud versprach

Die Argumente für die Cloud waren — und sind — attraktiv:

Skalierung. Mehr Last? Ein paar Klicks, und die Ressourcen sind da. Keine neue Hardware bestellen, kein Rack einbauen, kein Kabel ziehen. Die Cloud skaliert theoretisch unbegrenzt, und diese Skalierung ist innerhalb von Minuten verfügbar, nicht Wochen oder Monaten.

Geschwindigkeit. Eine neue Instanz starten, ein neues Deployment ausrollen, einen neuen Service aufsetzen — in der Cloud geht das in Minuten. On-Premise brauchte früher Tage oder Wochen für Hardware-Beschaffung und Einrichtung. In der Cloud ist alles sofort verfügbar.

Weniger Betriebsaufwand. Keine Server, die man warten muss. Keine Klimaanlage im Serverraum. Keine Hardware-Reparaturen am Freitagabend. Keine Ersatzteil-Lieferketten. Der Cloud-Provider kümmert sich um alles — Strom, Kühlung, Hardware, Netzwerk, physische Sicherheit.

Kapex vs. Opex. Statt hoher Investitionskosten (Capital Expenditure) für Hardware gibt es monatliche Betriebskosten (Operational Expenditure). Das ist für die Finanzabteilung attraktiv: planbare Kosten, keine Abschreibungen, keine Restwerte.

Managed Services. Datenbanken, Message Queues, Container-Orchestrierung, Authentication — alles als Service verfügbar. Kein Betrieb, keine Patches, keine Skalierungssorgen. Der Provider macht das.

Was die Cloud wirklich verändert hat

Die Cloud hat die Einstiegshürde massiv gesenkt. Das ist ihr größter Verdienst. Startups können heute innerhalb von Stunden eine Produktionsinfrastruktur aufbauen, die früher Wochen gedauert hätte. Kleine Unternehmen können auf Enterprise-Grade-Services zugreifen, ohne Enterprise-Grade-Personal zu brauchen.

Aber die Cloud hat auch die Wahrnehmung von IT-Kosten verzerrt. Die monatliche Rechnung fühlt sich anders an als eine einmalige Hardware-Investition — aber über drei bis fünf Jahre gerechnet ist sie oft teurer. Viel teurer. Und das ist nicht die einzige Überraschung.

Die Nachteile — die Rechnung kommt

Kostenentwicklung

Die Cloud ist billig, wenn man klein anfängt. Und sie wird teuer, wenn man wächst. Nicht linear teuer — exponentiell teuer.

Daten-Egress. Daten in die Cloud zu schicken ist kostenlos. Daten aus der Cloud herauszuholen kostet Geld. Das ist kein Zufall — es ist das Geschäftsmodell. AWS berechnet $0.09 pro GB für Daten-Transfer nach draußen. Bei einem Terabyte sind das $90. Bei zehn Terabyte $900. Und das ist nicht die einmalige Migration — das ist jede Replikation, jeder Backup-Restore, jeder Datenabgleich.

Storage-Kosten. S3-Storage kostet $0.023 pro GB und Monat (Standard-Tier). Das klingt wenig. Bei 50 TB sind das $1.150 pro Monat. Bei 500 TB — und das ist für mittelständische Unternehmen keine ungewöhnliche Größenordnung — sind es $11.500 pro Monat. $138.000 pro Jahr. Für Storage. Ohne Compute, ohne Netzwerk, ohne Managed Services.

Compute-Kosten. Eine m5.xlarge-Instanz bei AWS kostet ca. $0,192 pro Stunde. Das sind $1.682 pro Jahr. Eine vergleichbare Dedizierte-Server-Miete kostet ca. $200–400 pro Jahr. Faktor 4–8. Und bei Dediziert-Servern ist die Rechenleistung garantiert, nicht geteilt mit anderen Instanzen auf derselben Hardware.

Lizenz-Kosten. Microsoft-Lizenzen in der Cloud sind oft teurer als on-prem. Oracle-Lizenzen in der Cloud sind ein Albtraum. Red Hat Subscriptions in der Cloud kosten mehr als on-prem. Die Cloud macht Softwarelizenzen nicht billiger — sie macht sie teurer, weil die Cloud-Provider ihre Margen draufschlagen.

Der Faktor 3–10. Studien von 451 Research, IDC und mehreren Cloud-Financial-Management-Firmen zeigen konsistent: Über einen Zeitraum von 3–5 Jahren sind Cloud-Kosten für dauerhaft laufende Workloads 3- bis 10-mal höher als vergleichbare On-Premise-Kosten. Das gilt nicht für kurzlebige Workloads, nicht für Burst-Szenarien, nicht für Startups in der Wachstumsphase — aber für den typischen Dauerbetrieb mittelständischer und großer Unternehmen.

Vendor Lock-in

Die Cloud ist wie ein Hotel: Check-in ist einfach. Check-out ist das Problem.

Proprietäre Services. Wer AWS Lambda, DynamoDB, S3 Event Notifications, SQS, SNS und CloudFormation einsetzt, hat eine Architektur gebaut, die auf AWS funktioniert — und nur auf AWS. Die Migration weg davon ist nicht nur technisch aufwendig, sie ist organisatorisch eine Katastrophe, weil jede Komponente berührt werden muss.

Datenformate. Selbst wenn die Daten theoretisch portabel sind — SQL ist SQL, oder? —, sind die Unterschiede zwischen AWS Aurora, Google Cloud SQL und Azure Database für PostgreSQL substanziell genug, dass eine Migration kein einfacher Dump/Restore ist.

Operational Lock-in. Wer CloudFormation, Terraform-Provider-spezifische Module oder AWS CDK einsetzt, hat Infrastruktur-Code, der nicht portabel ist. Die IaC-Abstraktion, die eigentlich Unabhängigkeit schaffen sollte, ist selbst abhängig vom Provider.

Vertragsstrukturen. Reserved Instances, Savings Plans, Enterprise Agreements — die Vertragsstrukturen der Cloud-Provider sind darauf ausgelegt, Kunden langfristig zu binden. Der Rabatt für ein 3-Jahres-Commitment ist attraktiv, aber er bedeutet: Drei Jahre lang bezahlt man für Ressourcen, unabhängig davon, ob man sie noch braucht.

Datenhoheit

Wer seine Daten in der Cloud hat, hat sie nicht. Der Cloud-Provider hat sie. Und der Cloud-Provider hat eine Rechtsordnung, der er unterliegt.

Cloud Act. Der US-Cloud-Act von 2018 ermächtigt US-Behörden, Daten von US-Unternehmen auch dann einzufordern, wenn die Daten in einem Rechenzentrum außerhalb der USA liegen. AWS, Azure und Google sind US-Unternehmen. Das bedeutet: Daten, die bei diesen Providern liegen — egal ob in Frankfurt, Tokio oder Sydney — können von US-Behörden angefordert werden, ohne dass der Kunde davon erfährt.

GDPR. Die DSGVO verlangt, dass personenbezogene Daten in der EU verarbeitet werden oder ein angemessenes Schutzniveau besteht. Der EU-US Data Privacy Framework ist die aktuelle Lösung — aber er ist ein politisches Abkommen, kein technisches. Und er kann, wie sein Vorgänger (Privacy Shield), jederzeit für ungültig erklärt werden.

Datenzugriff durch Provider. Die AGB der großen Cloud-Provider erlauben ihnen Zugang zu Kunden-Daten in bestimmten Fällen — etwa bei Verdacht auf Missbrauch oder auf Anordnung eines Gerichts. Die Verschlüsselung der Daten ändert daran nichts, wenn der Provider die Schlüssel verwaltet.

Souveränität ist kein theoretisches Konzept. Für Unternehmen im öffentlichen Sektor, im Gesundheitswesen, in der Finanzindustrie und in kritischen Infrastrukturen ist Datenhoheit keine Frage der Präferenz, sondern der regulatorischen Pflicht. Wer Patientendaten, Finanzdaten oder Regierungsdaten in einer US-Cloud speichert, riskiert nicht nur Bußgelder — er riskiert den Entzug der Betriebserlaubnis.

Datenschutz

Datenschutz ist nicht dasselbe wie Datenhoheit. Datenhoheit fragt: Wer kann rechtlich auf meine Daten zugreifen? Datenschutz fragt: Wie schütze ich meine Daten vor unbefugtem Zugriff?

In der Cloud teilt man die Verantwortung mit dem Provider. Das „Shared Responsibility Model“ von AWS, Azure und Google ist klar definiert: Der Provider sichert die Infrastruktur, der Kunde sichert die Daten. Aber in der Praxis bedeutet das:

  • Der Provider hat physischen Zugriff auf die Hardware.
  • Der Provider kontrolliert das Hypervisor-Management.
  • Der Provider kann Memory-Dumps erstellen.
  • Der Provider hat Zugriff auf verschlüsselte Daten, wenn die Entschlüsselung in der Cloud stattfindet.

Das ist kein Misstrauen gegen die Provider. Es ist die Anerkennung einer Tatsache: Wer die Schlüssel nicht selbst verwaltet, hat keine volle Kontrolle über den Zugriff. Und „volle Kontrolle“ ist genau das, was Datenschutz in vielen Szenarien verlangt.

On-Premise ist nicht tot

Die Proklamation „On-Premise ist tot“ war die am häufigsten wiederholte Unwahrheit der letzten zehn Jahre. On-Premise war nie tot. On-Premise war nur nicht mehr sexy.

Was sich geändert hat

On-Premise bedeutet nicht mehr: Ein kalter Keller, ein Rack, ein überlasteter Administrator. Moderne On-Premise-Infrastruktur sieht anders aus:

Infrastructure as Code. Ansible, Terraform, Salt, Puppet — die gleichen Tools, die in der Cloud verwendet werden, funktionieren on-prem. Die Konfiguration ist versioniert, reproduzierbar, automatisiert. Der Unterschied zwischen Cloud und On-Premise ist nicht mehr die Automatisierung — es ist nur noch der Ort, wo die Hardware steht.

Virtualisierung ist gereift. Proxmox, bhyve, KVM — moderne Virtualisierungslösungen bieten Snapshots, Live-Migration, Resource-Pooling und Hochverfügbarkeit. Der Funktionsumfang ist mit Cloud-Virtualisierung vergleichbar, nur dass man die Hardware selbst kontrolliert.

ZFS. ZFS als Storage-Grundlage bietet Datenintegrität, Snapshots, inkrementelle Replikation, Kompression und Caching — alles, was man für robusten On-Premise-Storage braucht. ZFS macht den Unterschied zwischen „ein Filesystem“ und „ein Storage-Management-System“.

Container. Docker, Podman, Kubernetes on-prem — Container laufen nicht nur in der Cloud. Ein On-Premise-Kubernetes-Cluster mit Terraform-Provisioning und Ansible-Konfiguration ist kein Hexenwerk mehr.

Automatisches Patching. FreeBSD mit pkgbase, Ubuntu mit unattended-upgrades, Red Hat mit auto-updates — die Automatisierung von Security-Patches ist on-prem genauso möglich wie in der Cloud.

Stabilität

On-Premise-Infrastruktur ist stabil, wenn sie richtig gebaut ist. „Richtig gebaut“ heißt:

  • ZFS mit Redundanz. Mirror oder RAID-Z vdevs, reguläre Scrubs, Snapshots, Replikation auf einen zweiten Server.
  • CARP oder keepalived für Hochverfügbarkeit. Automatisches Failover bei Server-Ausfall.
  • Monitoring. Prometheus, Grafana, Alertmanager — die gleichen Tools wie in der Cloud.
  • Proaktive Wartung. ZFS-Scrubs wöchentlich, Smart-Monitoring für Disk-Failures, Firmware-Updates planvoll, nicht panisch.

Die Unterscheidung ist wichtig: Instabile On-Premise-Infrastruktur ist kein Argument gegen On-Premise. Es ist ein Argument gegen instabile Infrastruktur.

Sicherheit

On-Premise ist sicherer als die Cloud — wenn man die Security-Kontrolle nutzt, die man hat. In der Cloud gibt man physische Sicherheit und Netzwerk-Sicherheit an den Provider ab. On-Premise behält man beides:

  • Physische Kontrolle. Der Server steht im eigenen Rack. Kein fremder Administrator hat Zugriff. Kein Cloud-Provider-Mitarbeiter kann ein Image erstellen.
  • Netzwerk-Kontrolle. Die Firewall ist die eigene Firewall. Die Netzwerkstruktur ist die eigene Netzwerkstruktur. Es gibt keinen Shared-Tenant-Netzwerk-Pfad, über den ein anderer Cloud-Kunde Angriffe durchführen kann.
  • Verschlüsselung. Daten können on-prem verschlüsselt werden, mit eigenen Schlüsseln, eigener Verwaltung, eigenem KMS. Die Entschlüsselung findet auf der eigenen Hardware statt, nicht auf einem Server, der einem US-Konzern gehört.

Kosteneffizienz

Die Rechnung ist einfach, wenn man sie ehrlich macht:

  • Hardware-Anschaffung. Ein Server mit 256 GB RAM, 2x 1 TB NVMe und 4x 8 TB HDD kostet ca. 8.000–15.000 € — je nach Spezifikation. Geschrieben über 5 Jahre: 1.600–3.000 € pro Jahr.
  • Strom und Kühlung. Ca. 500–1.500 € pro Jahr pro Server, je nach Effizienz.
  • Netzwerk und Housing. Wenn man nicht selbst hostet: Colocation kostet ca. 100–300 € pro Monat pro HE. 1.200–3.600 € pro Jahr.
  • Personal. Das ist der größte Kostenfaktor — aber das Personal braucht man in der Cloud auch. Cloud-Infrastruktur managt sich nicht selbst.

Vergleich: Dieselbe Rechenleistung und denselben Storage in der Cloud kosten — konservativ geschätzt — 30.000–80.000 € pro Jahr. Bei wachsendem Storage-Volumen wird der Unterschied größer, nicht kleiner.

Der Break-Even liegt typischerweise bei 18–24 Monaten. Danach ist On-Premise günstiger. Und der Kostenvorteil wächst, weil die Hardware bezahlt ist, während die Cloud-Rechnung jeden Monat kommt.

Wann Cloud sinnvoll ist

Die Cloud ist nicht schlecht. Sie ist das falsche Default.

Cloud ist sinnvoll, wenn:

Burst-Workloads. Lastspitzen, die unvorhersehbar sind und kurzfristig viel Ressourcen brauchen. Black Friday, eine virale Kampagne, ein einmaliger Daten-Processing-Job. Die Cloud kann in Minuten skalieren und danach wieder schrumpfen. On-Premise muss die Hardware für den Worst Case vorhalten.

Prototyping und MVPs. Wenn man nicht weiß, ob ein Produkt funktioniert, ist die Cloud der richtige Ort. Keine Hardware-Investition, keine Verpflichtung. Wenn das Produkt funktioniert und die Last stabil wird, kann man migrieren.

Globale Verteilung. Wenn man Server in Singapur, São Paulo und Frankfurt braucht — in der nächsten Woche —, ist die Cloud die einzige Option. On-Premise braucht Zeit für Standortsuche, Hardware-Lieferung und Einrichtung.

Managed Services, die man selbst nicht betreiben will. Wenn man kein Elasticsearch-Expertise hat und nicht aufbauen will, dann ist AWS OpenSearch eine vernünftige Wahl. Wenn man kein Kafka-Cluster betreiben kann, dann ist Confluent Cloud eine Lösung. Der Schlüssel ist: Man wählt den Service bewusst, nicht als Default.

Kurzlebige Umgebungen. Test, Staging, CI/CD-Runner — Umgebungen, die man hochfährt, benutzt und wieder abschaltet. Die Cloud ist ideal für Ressourcen, die nicht 24/7 laufen müssen.

Wann On-Premise besser ist

On-Premise ist besser, wenn:

Dauerhafte Workloads. Workloads, die 24/7/365 laufen und deren Ressourcenbedarf vorhersehbar ist. Webserver, Datenbanken, Dateispeicher, interne Anwendungen — das ist das Kerngeschäft, und das gehört on-prem.

Große Datenmengen. Storage ist in der Cloud teuer. Bei 100+ TB wird die Rechnung absurd. On-Premise mit ZFS und großen Platten ist wirtschaftlich, und die Daten liegen dort, wo man sie kontrolliert.

Regulatorische Anforderungen. DSGVO, B3S, Kritis, Medizinprodukte-Verordnung — wenn der Gesetzgeber Datenhoheit verlangt, ist On-Premise keine Option, sondern eine Pflicht.

Langfristige Kosteneffizienz. Wenn man die Last für die nächsten 3–5 Jahre abschätzen kann, ist On-Premise günstiger. Deutlich günstiger.

Latenz-empfindliche Anwendungen. Die Netzwerk-Latenz zwischen Rechenzentrum und Nutzer ist on-prem minimiert. In der Cloud gibt es die Latenz zum nächsten Cloud-Region-Endpoint — und die ist für Echtzeit-Anwendungen nicht immer akzeptabel.

Daten, die nicht die Firma verlassen dürfen. Geheimnisse, Patente, Forschungsdaten, Kunden-Personas — es gibt Daten, die aus rechtlichen, ethischen oder strategischen Gründen nicht auf fremder Infrastruktur liegen dürfen.

Hybridmodelle — oft die beste Lösung

Die falsche Debatte ist „Cloud oder On-Premise“. Die richtige Debatte ist: „Was gehört wo hin?“

Das Prinzip der minimalen Cloud

Nutze die Cloud für das, was sie besser kann als On-Premise. Nutze On-Premise für alles andere. Das klingt banal, ist aber die Konsequenz einer ehrlichen Bewertung:

  • Stabile Kern-Workloads → On-Premise. Datenbanken, Dateispeicher, interne Anwendungen, Identity Management.
  • Burst- und Spitzenlast → Cloud. Zusätzliche Compute-Kapazität bei Lastspitzen, CI/CD-Runner, temporäre Testumgebungen.
  • Datenhoheit-kritische Daten → On-Premise. Alles, was regulatorisch oder strategisch geschützt werden muss.
  • Globale Services → Cloud. CDN, Edge-Computing, globale API-Endpunkte.
  • Managed Spezial-Services → Cloud. ML-Training, spezialisierte Datenbanken, Services, die man selbst nicht betreiben kann oder will.

Praktisches Hybrid-Setup

Ein konkretes Beispiel für ein mittelständisches Unternehmen:

On-Premise:

  • ZFS-Storage-Server mit 200 TB (Datenbanken, Dateispeicher, Backups)
  • Proxmox- oder bhyve-Cluster für interne Anwendungen
  • Git-Server (Gitea oder GitLab)
  • Identity Management (FreeIPA, Keycloak)
  • Monitoring (Prometheus, Grafana)
  • E-Mail-Server

Cloud:

  • CDN für die Website und statische Assets
  • Cloud-Runner für CI/CD (nur bei Bedarf)
  • Disaster Recovery: Replikation der kritischsten Daten in einen Cloud-Object-Store (verschlüsselt, mit eigenen Schlüsseln)
  • Burst-Compute für Lastspitzen (z.B. Quartalsende-Reporting)

Die monatliche Cloud-Rechnung für dieses Setup: vielleicht 500–2.000 €. Nicht 20.000 €. Nicht 50.000 €. Weil das Kerngeschäft on-prem läuft, und die Cloud nur das macht, was sie gut kann.

Die Rückkehr-Strategie

Für Unternehmen, die bereits massiv in der Cloud sind und die Kostenstruktur hinterfragen:

1. Inventur. Welche Workloads laufen in der Cloud? Welche davon laufen dauerhaft? Welche kosten am meisten?

2. Klassifikation. Welche Workloads sind Cloud-native (Lambda, DynamoDB, SQS)? Welche sind portabel (Docker-Container, Standard-Datenbanken, Webserver)?

3. Identifikation der Migrationskandidaten. Portable, dauerhafte Workloads mit hohem Daten-Volumen sind die besten Kandidaten für eine Rückkehr on-prem.

4. Pilot-Migration. Eine Workload auswählen, migrieren, Kosten vergleichen. Nicht alles auf einmal — iterativ vorgehen.

5. Optimierung. Nach der Migration: Cloud-Kosten für die verbleibenden Workloads optimieren. Reserved Instances, Spot-Instances, Right-Sizing.

Digitale Souveränität — mehr als ein Buzzword

Digitale Souveränität bedeutet: Die Fähigkeit, über die eigenen Daten, Prozesse und Infrastruktur selbst zu bestimmen. Nicht abhängig zu sein von einem einzelnen Provider, einem einzelnen Land, einer einzelnen Rechtsordnung.

Das ist kein nationalistisches Konzept. Es ist ein pragmatisches. Wer seine Infrastruktur nicht kontrolliert, kontrolliert sein Geschäft nicht. Wer seine Daten nicht kontrolliert, kontrolliert seine Zukunft nicht.

Die Cloud hat die Illusion erzeugt, dass Infrastruktur kein Problem mehr ist — man mietet sie ja einfach. Aber Infrastruktur war nie das Problem. Das Problem ist die Abhängigkeit. Und die Abhängigkeit ist in den letzten zehn Jahren größer geworden, nicht kleiner.

On-Premise ist die Antwort auf diese Abhängigkeit. Nicht als Absolutum — „alles on-prem“ ist genauso dogmatisch wie „alles Cloud“ —, sondern als bewusste Entscheidung: Was muss ich selbst kontrollieren? Was kann ich auslagern? Und wie stelle ich sicher, dass ich das Ausgelagerte bei Bedarf zurückholen kann?

Fazit

Die Cloud hat die IT-Landschaft verändert. Sie hat den Einstieg erleichtert, die Skalierung beschleunigt und die Betriebsmodelle transformiert. Aber sie hat auch Abhängigkeiten geschaffen, Kosten getrieben und Datenhoheit aufgeweicht.

On-Premise ist die Rückbesinnung auf das, was wirklich zählt: Kontrolle über die eigenen Daten, Kosteneffizienz für dauerhafte Workloads und Unabhängigkeit von einzelnen Providern.

Die beste Lösung ist Hybrid: Cloud für das, was die Cloud besser kann. On-Premise für alles andere. Und eine Architektur, die beides verbindet, ohne die Souveränität aufzugeben.

Die Unternehmen, die das verstehen, werden die nächsten zehn Jahre dominieren. Die anderen werden weiter monatliche Cloud-Rechnungen bezahlen — und sich fragen, warum ihre IT so teuer ist.

FreeBSD Wochenrückblick – 14. bis 20. April 2026

Thorsten Geppert Schreib einen Kommentar

Eine Übersicht der wichtigsten Entwicklungen, Sicherheitsmeldungen und Diskussionen rund um FreeBSD in der vergangenen Woche.

Release Engineering: 15.1 nähert sich der Slush-Phase

Am 17. April begann die stable/15-Slush-Phase im Vorfeld von FreeBSD 15.1. Der Zeitplan, den Release Engineering Lead Colin Percival bereits im Januar veröffentlicht hat, sieht wie folgt aus:

MeilensteinDatum
Ports Quarterly Branch1. April 2026
stable/15 Slush17. April 2026
doc/ Tree Slush24. April 2026
releng/15.1 Branch1. Mai 2026
BETA11. Mai 2026
BETA28. Mai 2026
BETA315. Mai 2026
RC122. Mai 2026
RELEASE Build29. Mai 2026
RELEASE Ankündigung2. Juni 2026

Percival hatte bereits im Januar angemerkt, dass 15.1 angesichts der Erfahrungen mit 15.0 ein „relativ holpriges“ Minor Release werden könnte, insbesondere wegen weiterer pkgbase-Änderungen. Zeitgleich erreicht stable/13 Ende April sein End-of-Life – die wöchentlichen Snapshot-Builds für diesen Branch werden dann eingestellt.

Sicherheit: SA-26:08 – Kritischer Stack-Overflow in rpcsec_gss

Die wohl bemerkenswerteste sicherheitsrelevante Meldung der letzten Wochen betrifft FreeBSD Security Advisory SA-26:08, das einen Stack-Overflow in svc_rpc_gss_validate() beschreibt. Die Schwachstelle ermöglicht Remote Code Execution und betrifft alle unterstützten FreeBSD-Versionen. Patches sind verfügbar für 15.0-RELEASE-p5 und die 14.x-Serie.

Das besondere an diesem Advisory: Die Schwachstelle wurde von Nicholas Carlini mithilfe von Claude AI (Anthropic) entdeckt und exploitbar gemacht – ein frühes Beispiel dafür, wie KI-gestützte Sicherheitsforschung reale Kernel-Schwachstellen aufdeckt. Der Fix-Commit von Mark Johnston (143293c) behebt den Pufferüberlauf in der GSS-Validierungsroutine.

Q1-2026 Statusbericht veröffentlicht

Die FreeBSD Statusberichte für das erste Quartal 2026 sind nun online, darunter ein Update der Release Engineering Team, das die erfolgreiche Veröffentlichung von 14.4-RELEASE im März und die Planung für 15.1 dokumentiert.

Laptop-Projekt: Community-Testing aufgerufen

Die FreeBSD Foundation hat am 6. April einen Call for Testing für das Laptop Integration Testing Project veröffentlicht. Nach dem Year-One-Update im Februar wurde seit Januar an der Test-Infrastruktur gearbeitet. Nun können Community-Mitglieder ihre Laptops testen:

pkg install python hw-probe
git clone https://github.com/FreeBSDFoundation/freebsd-laptop-testing
cd freebsd-laptop-testing
make

Das Test-Tool erfasst automatisch Hardware-Funktionen und erstellt anonymisierte Berichte, die per Pull Request eingereicht werden. Die Ergebnisse fließen in eine öffentliche Kompatibilitätsmatrix unter freebsdfoundation.github.io/freebsd-laptop-testing.

OpenZFS: Native relatime-Eigenschaft

Am 1. April wurde in OpenZFS die native relatime-Eigenschaft implementiert (Commit 1685849 von @amotin). Relatime (relative atime) aktualisiert die Zugriffszeit einer Datei nur, wenn sie älter ist als die Änderungs- oder Statusänderungszeit. Das reduziert unnötige Schreibzugriffe erheblich – besonders auf SSDs und in Caches – und war bisher nur über Mount-Optionen konfigurierbar. Mit der neuen Eigenschaft kann relatime nun nativ pro Dataset gesetzt werden.

Ports: GNU-ld-Checks entfernt

Brooks Davis hat am 13. April einen umfangreichen Cleanup-Commit (d87609e) in die Ports eingebracht, der alle Überprüfungen entfernt, ob der Basis-Linker GNU ld ist oder nicht. Hintergrund: Seit FreeBSD den LLVM-Linker lld als Standard verwendet, sind diese Checks obsolet geworden. Der Commit betrifft Ports tree-weit zahlreiche Makefiles.

Mailinglisten

IPv6-Only-RA: Wechsel zu RFC 8925 vorgeschlagen

Pouria Mousavizadeh Tehrani hat auf freebsd-current einen Vorschlag eingereicht, die experimentelle Implementierung des IETF-Drafts DRAFT_IETF_6MAN_IPV6ONLY_FLAG zu entfernen und stattdessen RFC 8925 (IPv6-Only-Präferenz über DHCP-Option) zu übernehmen. Die Geschichte dahinter ist interessant: Bjoern Zeeb hatte ursprünglich die Idee, Netzwerke über ein RA-Flag als IPv6-Only zu markieren. Der Draft wurde jedoch verworfen, weil RAs trivial gefälscht werden können – ein Angreifer könnte IPv4-Netzwerke böswillig abschalten. Später reichte Google die gleiche Idee als DHCP-Option ein, was zu RFC 8925 wurde. Pouria bittet um Feedback zur Entfernung der Draft-spezifischen Codepfade aus Kernel und Userland.

Kqueue-Panic: knlist-Assertionen nachgerüstet

Auf freebsd-current wurde ein Kernel-Panic gemeldet: „knote was already on knlist“ nach dem Build main-n284826. Kyle Evans (kevans91) hat daraufhin Assertionen in knlist_add() und knlist_remove_kq() nachgerüstet (Commit 306c904), um solche Fehlerzustände früher und zuverlässiger zu erkennen. Der zugehörige Bugreport (Bug 293382) beschreibt Deadlocks und Abstürze rund um closefp_impl – ein Hinweis darauf, dass das Problem mit dem Schließen von File Descriptoren und der kqueue-Registrierung zusammenhängt.

Warum robuste Infrastruktur wichtiger ist als moderne Tools

Thorsten Geppert Schreib einen Kommentar

Jedes Jahr erscheinen hunderte neue Frameworks, Plattformen und Tools. Jedes verspricht mehr Produktivität, schnellere Entwicklung, bessere Zusammenarbeit. Und jedes Jahr investieren Firmen Zeit und Geld in die Evaluierung, Einführung und Migration auf das nächste große Ding — während die Grundlagen ihrer Infrastruktur vor sich hin rotten.

Das ist kein rhetorisches Bild. Das ist Beobachtung.

Die Versuchung des Neuen

Es ist verständlich. Ein neues CI/CD-Tool verspricht, Deployments von 45 Minuten auf 3 Minuten zu reduzieren. Ein neues Monitoring-Tool verspricht bessere Dashboards. Ein neues Container-Orchestrierungstool verspricht Skalierbarkeit auf Knopfdruck. Das sind attraktive Versprechen, und sie sind oft sogar echt.

Das Problem ist nicht, dass neue Tools schlecht sind. Das Problem ist, dass sie von den Grundlagen ablenken. Denn die Frage, ob ein Deployment 3 Minuten oder 45 Minuten dauert, ist irrelevant, wenn die Datenbank bei einem Disk-Ausfall weg ist und kein Backup existiert.

Die Frage, ob man Kubernetes oder Nomad oder Docker Swarm einsetzt, ist zweitrangig, wenn der Storage darunter mit einem Filesystem läuft, das keine Prüfsummen bildet, keine Snapshots kann und bei einem Bit-Flip einfach korrupte Daten durchreicht.

Die Frage, welches Monitoring-Tool das schönste Dashboard hat, ist nachrangig, wenn es niemanden gibt, der die Alerts versteht und weiß, was zu tun ist, wenn sie auslösen.

Was Firmen ignorieren

Storage-Architektur

Storage ist das Fundament. Alles, was eine IT-Infrastruktur leistet, landet irgendwann auf Storage. Datenbanken, Konfigurationen, Logs, Benutzerdaten, Backups — alles. Und trotzdem wird Storage oft behandelt wie Strom aus der Steckdose: Man geht davon aus, dass es da ist, und denkt nicht weiter darüber nach.

Die Realität sieht anders aus. In vielen Firmen läuft der Storage auf Hardware-RAID-Controllern, die niemand überwacht. Auf Filesystemen, die keine Datenintegrität garantieren. Auf LVM-Volumes, die bequem zu verwalten sind, aber bei einem Ausfall keine Recovery-Option bieten. Auf NFS-Shares, deren Performance bei Concurrent Access zusammenbricht, aber niemand hat je getestet, was passiert, wenn 50 Entwickler gleichzeitig bauen.

Und dann passiert das Unvermeidliche: Ein Disk-Set fällt aus. Ein RAID-5 verliert eine zweite Platte während des Rebuilds. Ein Controller-Firmware-Bug korruptiert den Write-Cache. Und plötzlich ist die Frage nicht mehr, wie schnell das Deployment ist, sondern ob die Daten noch existieren.

Backup

Backup ist der am häufigsten ignorierte Bestandteil einer Infrastruktur. Nicht, weil niemand weiß, dass man Backups braucht — sondern weil Backup langweilig ist. Es gibt keine Konferenz-Talks über Backup-Strategien. Es gibt keine Hacker News-Diskussionen über inkrementelle Sicherung. Es gibt keine X-Threads über den Unterschied zwischen Voll-, Differenzial- und Inkrementell-Backup.

Was es gibt: Firmen, die nach einem Ausfall feststellen, dass ihre Backups seit Monaten nicht mehr liefen. Firmen, die ihre Backups nie getestet haben und beim Restore feststellen, dass die Bänder leer sind. Firmen, die ihre Backups auf demselben Storage liegen haben wie die Produktionsdaten und bei einem Ransomware-Angriff alles verlieren.

Die drei unbequemen Wahrheiten über Backup:

  1. Ein Backup, das nicht getestet wurde, ist kein Backup. Es ist ein Hoffnungsspeicher.
  2. Ein Backup auf demselben System wie die Quelldaten ist kein Backup. Es ist eine Kopie, die denselben Risiken ausgesetzt ist.
  3. Ein Backup ohne definierte Retention-Policy ist kein Backup. Es ist ein wachsender Haufen von Daten, den irgendwann niemand mehr versteht.

Filesystem-Konfiguration

Das Filesystem ist die Schicht zwischen der Hardware und allem, was darauf läuft. Es entscheidet, ob Daten sicher geschrieben werden, ob sie nach einem Crash noch lesbar sind, ob sie vor stiller Korruption geschützt sind.

Die meisten Server laufen auf ext4 oder XFS. Das sind solide Filesysteme, aber sie haben eine entscheidende Einschränkung: Sie haben keine eingebaute Datenintegritätsprüfung. Wenn ein Bit auf der Platte kippt — und das passiert häufiger, als man denkt — dann liest ext4 einfach das falsche Datum und reicht es durch. Kein Fehler. Keine Warnung. Nur stille Korruption.

ZFS löst dieses Problem. ZFS bildet Prüfsummen über alle Datenblöcke und verifiziert sie bei jedem Lesezugriff. Wenn ein Bit kippt, bemerkt ZFS es — und repariert es automatisch, wenn Redundanz vorhanden ist. Das ist kein theoretisches Risiko: Studien von CERN und NetApp zeigen Bit-Error-Raten von 10^-16 bis 10^-17 pro Bit gelesener Daten. Bei einem Petabyte an Daten bedeutet das: Es passiert. Regelmäßig.

Aber ZFS ist mehr als Prüfsummen. Es ist Snapshots, die in Sekunden erstellt werden und null Space kosten. Es ist Send und Recv für inkrementelle Replikation. Es ist Compression, die Storage spart und Lese-Performance verbessert. Es ist Copy-on-Write, das bei einem Crash nie ein inkonsistentes Filesystem hinterlässt.

Wer ZFS nicht nutzt, nutzt meist kein Filesystem mit Datenintegritätsgarantie. Das ist eine bewusste Entscheidung gegen Datenintegrität.

Systemarchitektur

Architektur ist nicht dasselbe wie Design. Design ist: Welche Technologie setze ich ein? Architektur ist: Wie hängen die Dinge zusammen? Was passiert, wenn etwas ausfällt? Wer ist für was verantwortlich? Wie kommunizieren die Komponenten?

Viele Firmen haben keine Architektur. Sie haben eine historisch gewachsene Ansammlung von Servern, Services und Abhängigkeiten, die niemand vollständig überblickt. Dokumentation existiert nicht oder ist veraltet. Abhängigkeiten sind implizit: Service A braucht Service B, aber das steht nirgends, und wenn Service B ausfällt, fragt sich Service A, warum es nicht mehr funktioniert.

Die Konsequenz: Jeder Ausfall wird zum Abenteuer. Nicht, weil das Problem schwer wäre, sondern weil niemand weiß, wie die Systeme zusammenhängen und wo man ansetzen muss.

Was robuste Infrastruktur ausmacht

ZFS — Das Fundament

ZFS ist nicht nur ein Filesystem. Es ist ein Storage-Manager, der Datenintegrität, Snapshots, Replikation, Kompression und Caching in einem System vereint. Wer ZFS einsetzt, hat eine Antwort auf die Fragen, die andere nicht einmal stellen:

  • Sind meine Daten noch intakt? Ja, weil ZFS Prüfsummen bildet und bei jedem Lesen verifiziert.
  • Kann ich einen Snapshot machen? Ja, in Sekunden, ohne Downtime, ohne Space-Kosten für unveränderte Blöcke.
  • Kann ich replizieren? Ja, inkrementell, mit zfs send und zfs recv, lokal oder remote.
  • Was passiert bei einem Crash? Das Filesystem ist immer konsistent, weil Copy-on-Write atomar schreibt.

ZFS ist die Grundlage, auf der alles andere aufbaut. Backup-Strategien werden mit Snapshots trivial. Disaster Recovery wird mit Replikation planbar. Storage-Performance wird mit ARC und L2ARC vorhersehbar.

Saubere Backup-Strategien

Backup ist keine Technologie, es ist eine Strategie. Die Technologie — ob Bacula, Borg, Restic, Amanda, oder einfach zfs send — ist der einfache Teil. Die Strategie ist die Entscheidung:

  • Was wird gesichert? Nicht alles ist gleich wichtig. Datenbanken sind kritischer als Log-Dateien. Konfigurationen sind kritischer als temporäre Dateien. Die Klassifikation entscheidet über Häufigkeit und Aufbewahrungsdauer.
  • Wie oft? Stündlich, täglich, wöchentlich — je nach Änderungsrate und Kritikalität. Eine Datenbank, die sich jede Sekunde ändert, braucht andere Backup-Frequenzen als eine Konfigurationsdatei, die sich einmal im Monat ändert.
  • Wohin? Die 3-2-1-Regel gilt: 3 Kopien, auf 2 verschiedenen Medien, 1 Offsite. Wer diese Regel nicht einhält, hat keine Backup-Strategie — er hat Datenkopien.
  • Wird getestet? Restore-Tests müssen regelmäßig stattfinden. Nicht einmal im Jahr. Mindestens einmal im Quartal, besser öfter. Denn ein ungetestetes Backup ist kein Backup.

Klare Systemarchitektur

Eine klare Architektur beantwortet drei Fragen:

  1. Was hängt wovon ab? Abhängigkeitsgraphen müssen dokumentiert sein. Wenn Service A Service B braucht, muss das explizit sein — nicht implizit durch einen irgendwo konfigurierten Connection String.
  2. Was passiert bei Ausfall? Für jede Komponente muss klar sein, was passiert, wenn sie ausfällt: Failover-Mechanismus, Graceful Degradation, oder Totalausfall. Und wer zuständig ist, wenn es passiert.
  3. Wie wird deployt? Deployment muss reproduzierbar sein. Ob via Ansible, Puppet, Salt, oder ein Shell-Skript — wichtig ist, dass der Zustand eines Servers aus der Konfiguration abgeleitet werden kann, nicht aus der Erinnerung des Administrators.

Die Praxis

Ausfälle verkraften

Robuste Infrastruktur ist nicht Infrastruktur, die nie ausfällt. Das gibt es nicht. Robuste Infrastruktur ist Infrastruktur, die Ausfälle verkraftet — ohne Datenverlust, ohne langwierige Recovery, ohne Panik.

Was das konkret heißt:

  • Storage-Redundanz. ZFS mit Mirror oder RAID-Z vdevs. Kein Single-Point-of-Failure auf Plattendenebene.
  • Service-Redundanz. CARP, keepalived, oder DNS-Failover für kritische Services. Kein Single-Server-Setup für etwas, das immer verfügbar sein muss.
  • Netzwerk-Redundanz. Mindestens zwei Uplinks, zwei Switches, zwei Pfad. LACP für Link-Aggregation. OSPF oder BGP für Routing-Failover, wenn die Infrastruktur groß genug ist.
  • Power-Redundanz. Zwei Stromkreise, USV, Generator — je nach kritikalität. Wer seinen Serverraum an eine einzige Phase anschließt, hat kein Power-Konzept.

Reproduzierbar sein

Wenn ein Server ausfällt und ein neuer aufgesetzt werden muss, darf die Frage nicht sein: „Wie war das konfiguriert?“ Die Antwort muss sein: „Konfiguration aus dem Repository ziehen und anwenden.“

Infrastructure as Code ist kein Buzzword, es ist eine Notwendigkeit. Wer Server manuell konfiguriert, hat eine Infrastruktur, die nicht reproduzierbar ist. Und eine Infrastruktur, die nicht reproduzierbar ist, ist eine Infrastruktur, die bei Ausfall nicht wiederhergestellt werden kann — nicht innerhalb eines vertretbaren Zeitrahmens.

Die Tools dafür existieren: Ansible für Konfigurationsmanagement, Terraform für Infrastruktur-Provisioning, Packer für Image-Erstellung. Aber das Wichtigste ist nicht das Tool — es ist die Disziplin, jedes Change durch die Pipeline zu schicken, nicht direkt auf dem Server.

Verständlich bleiben

Die wichtigste Eigenschaft einer Infrastruktur ist nicht ihre Eleganz, sondern ihre Verständlichkeit. Wenn ein neuer Administrator die Infrastruktur erklärt bekommt und innerhalb einer Woche produktiv arbeiten kann, ist die Architektur gut. Wenn er nach drei Monaten noch nicht versteht, wie die Systeme zusammenhängen, ist die Architektur schlecht.

Verständlichkeit entsteht durch:

  • Dokumentation. Nicht als Afterthought, sondern als Teil des Setups. Jeder Service bekommt eine Dokumentation: Was ist das? Wie hängt es zusammen? Wie wird es deployt? Was passiert bei Ausfall?
  • Konsistenz. Gleiche Konventionen überall. Gleiche Verzeichnisstrukturen, gleiche Benennungsschemata, gleiche Prozesse. Wer bei jedem Server nachdenken muss, wo die Konfiguration liegt, verschwendet Zeit.
  • Einfachheit. Kein Kubernetes-Cluster für drei Container. Kein Service-Mesh für eine interne Anwendung. Kein verteiltes System, wo ein einzelner Server reicht. Komplexität ist der Feind von Verständlichkeit.

Die unbequeme Wahrheit

Moderne Tools sind attraktiv, weil sie sichtbare Ergebnisse liefern. Ein neues Deployment-Tool zeigt sofort: Das Deployment ist schneller. Ein neues Monitoring-Tool zeigt sofort: Die Dashboards sind schöner. Ein neues Framework zeigt sofort: Die Features sind da.

Infrastruktur-Grundlagen sind unsichtbar. ZFS-Prüfsummen zeigen keinen Unterschied, solange alles funktioniert. Backup-Strategien zeigen keinen Unterschied, solange kein Ausfall passiert. Architektur-Dokumentation zeigt keinen Unterschied, solange dieselben Leute arbeiten.

Der Unterschied zeigt sich erst, wenn etwas schiefgeht. Und dann ist es zu spät, die Grundlagen nachzuholen.

Die unbequeme Wahrheit ist: Die Zeit, die man in Storage, Backup, Filesystem und Architektur investiert, zahlt sich nicht in Sprint-Demos aus. Sie zahlt sich nicht in Quarterly Business Reviews aus. Sie zahlt sich nicht in Twitter-Threads aus.

Sie zahlt sich aus, wenn der Storage ausfällt und die Daten noch da sind. Sie zahlt sich aus, wenn Ransomware zuschlägt und das Restore in Stunden statt Wochen läuft. Sie zahlt sich aus, wenn der Hauptadministrator kündigt und der neue innerhalb einer Woche produktiv ist.

Das ist nichts, was man in einem Slide-Deck zeigen kann. Aber es ist alles, was zählt.

Fazit

Investiert in die Grundlagen. Nicht als Ersatz für moderne Tools — sondern als Voraussetzung. Ein neues CI/CD-System auf einer Infrastruktur ohne Backup ist wie ein Rennmotor in einem Auto ohne Bremsen. Schnell, solange alles funktioniert. Tödlich, wenn nicht.

Die Reihenfolge ist:

  1. Storage — ZFS, Redundanz, Datenintegrität
  2. Backup — 3-2-1-Regel, Restore-Tests, Offsite-Kopie
  3. Architektur — Abhängigkeiten, Failover, Dokumentation
  4. Reproduzierbarkeit — Infrastructure as Code, kein manuelles Konfigurieren
  5. Verständlichkeit — Konsistenz, Einfachheit, Dokumentation

Und dann, wenn das Fundament steht: Die modernen Tools. Aber auf einem Fundament, das hält.

Welche Programmiersprache für Einsteiger? Ein ehrlicher Überblick

admin Schreib einen Kommentar

Jeder, der anfängt zu programmieren, stellt dieselbe Frage: Welche Sprache soll ich lernen? Und jedes Mal bekommt man unterschiedliche Antworten — weil die Antwort davon abhängt, was man bauen will, woher man kommt und wie viel Frustration man bereit ist zu ertragen.

Ich mache es einfach. Hier ist meine Einschätzung, basierend auf zwanzig Jahren Erfahrung damit, Code zu schreiben und zu erklären. Keine akademische Rangliste. Sondern: Was ist nützlich? Was ist zugänglich? Und wo verbringt man mehr Zeit mit Kämpfen gegen die Sprache als mit dem eigentlichen Problem?

Python — Der empfohlene Einstieg

Python ist die Sprache, die ich jedem nenne, der fragt. Nicht weil sie die beste ist — sondern weil sie am wenigsten im Weg steht.

Die Syntax ist minimal: Keine Klammern, keine Semikolons, Einrückung ist Struktur. Man liest Python-Code wie englische Anweisungen. Das klingt banal, ist aber der wichtigste Faktor für Anfänger: Wenn man den Code lesen kann, kann man ihn verstehen. Wenn man ihn versteht, kann man ihn verändern. Und verändern ist wie Programmieren.

print("Hallo, Welt!")

Das ist ein vollständiges Python-Programm. Eine Zeile. Keine Importe, keine Klassendefinition, keine main-Funktion. Man speichert es als hallo.py und führt es aus mit python hallo.py. Fertig.

Nützlich ist Python für fast alles: Skripte, Automatisierung, Web-Backend (Django, Flask), Datenanalyse (Pandas, NumPy), Machine Learning (PyTorch, scikit-learn), Systemadministration. Die Standardbibliothek ist absurd umfangreich — man bekommt oft ohne ein einziges pip install erstaunlich viel erledigt.

Der Nachteil: Python ist langsam. Nicht „ein bisschen langsamer“ — richtig langsam, oft 10-100x gegenüber kompilierten Sprachen. Aber für den Einstieg ist das irrelevant. Wenn man an den Punkt kommt, wo Geschwindigkeit zählt, hat man schon längst verstanden, wie man programmiert.

Lernkurve: Flach. Die ersten Ergebnisse kommen in Minuten. Komplexere Konzepte (OOP, Generatoren, Dekoratoren) brauchen Zeit, aber man kommt sehr weit ohne sie.

JavaScript — Weil der Browser überall ist

JavaScript ist die einzige Sprache, die auf jedem Rechner der Welt läuft, ohne dass man etwas installieren muss. Jeder Browser ist eine JavaScript-Laufzeitumgebung. Das macht sie zur einzigen Sprache, bei der man sein Ergebnis sofort teilen kann — einfach eine HTML-Datei, aufgemacht im Browser, fertig.

console.log("Hallo, Welt!");

Im Browser:

<!DOCTYPE html>
<html>
<body>
<script>
  document.body.textContent = "Hallo, Welt!";
</script>
</body>
</html>

Speichern als .html, Doppelklick, Ergebnis. Kein Server, kein Build-Schritt, kein nichts.

JavaScript hat zwei Gesichter: Im Browser ist es die DOM-Manipulation, Event-Handling, UI-Logik. Auf dem Server (Node.js) ist es ein vollwertiges Backend mit Zugriff auf Dateisystem, Netzwerk, Datenbanken. Dasselbe Sprache, zwei Welten.

Das Problem mit JavaScript: Die Sprache hat viele historische Macken. == vs. ===, das Verhalten von this, var vs. let vs. const, die ganze Asynchronität mit Callbacks, Promises, async/await — das ist eine Menge, die man nicht sofort verstehen muss, die aber irgendwann auf einen wartet. Und das Ökosystem ist berüchtigt für seine Abhängigkeitshölle: Ein npm install zieht hundert Pakete, und man versteht kein einziges.

Trotzdem: Wenn man Dinge bauen will, die im Browser laufen, gibt es keine Alternative. Und der Browser ist der Ort, wo Menschen Software erleben.

Lernkurve: Mittel. Der Einstieg ist einfach (öffne die Konsole, tippe console.log), aber die Tiefe ist tückisch. Man kommt schnell zu Ergebnissen, aber man schreibt lange Zeit Code, den man nicht vollständig versteht.

Rust — Für die, die es richtig lernen wollen

Rust ist die schwerste Sprache in dieser Liste und diejenige, die ich am spätesten nenne. Aber ich nenne sie, weil sie etwas lehrt, das andere Sprachen vernachlässigen: Wie Speicher funktioniert.

fn main() {
    println!("Hallo, Welt!");
}

Sieht einfach aus. Ist es aber nicht. Das ! hinter println verrät es schon: Das ist ein Makro, keine Funktion. Rust hat Makros, Traits, Lifetimes, Ownership, Borrowing — Konzepte, die man in Python oder JavaScript nie sieht, weil die Laufzeitumgebung sie versteckt.

Warum sollte man das als Anfänger lernen wollen? Weil man versteht, was unter der Abstraktion passiert. Wenn man in Python eine Liste an eine Funktion übergibt, fragt man sich nicht, ob das eine Kopie oder eine Referenz ist. In Rust muss man das wissen. Das ist anstrengend. Aber es macht einen zu einem besseren Programmierer in jeder anderen Sprache.

Rust ist die Sprache, die den Compiler als Lehrer nutzt. Der Compiler lehnt Code ab, der Speicherprobleme haben könnte. Die Fehlermeldungen sind legendarisch gut — sie erklären nicht nur, was falsch ist, sondern auch, wie man es fixt. Man kämpft gegen den Compiler. Und dabei lernt man.

Praktisch ist Rust für Systemnahe Programmierung: Betriebssystem-Komponenten, Treiber, CLIs, WebAssembly, Netzwerk-Dienste, die Performance brauchen. Firefox‘ Rendering-Engine Servo ist in Rust. Teile von Windows, Linux und FreeBSD sind in Rust. Die Sprache hat Momentum.

Lernkurve: Steil. Die ersten Wochen sind frustrierend, weil der Compiler fast alles ablehnt. Aber wenn es klickt, klickt es richtig.

Go — Einfach, aber nicht primitiv

Go (Golang) ist die Sprache, die Google gemacht hat, weil C++ zu komplex und Python zu langsam war. Das Design ist radikal minimalistisch: Keine Vererbung, keine Generics (bis vor kurzem), keine Exceptions, keine drei Wege, dasselbe zu tun.

package main

import "fmt"

func main() {
    fmt.Println("Hallo, Welt!")
}

Mehr Boilerplate als Python — aber immer noch überschaubar. Das package main, das import, die func main() — das ist ein festes Gerüst, das man einmal lernt und dann immer wieder verwendet.

Go glänzt dort, wo man Concurrent-Programmierung braucht: Webserver, APIs, Microservices, Kommandozeilen-Tools. Goroutinen und Channels sind das eleganteste Concurrency-Modell, das ich in einer imperativen Sprache gesehen habe. Statt Threads und Locks schreibt man:

go func() {
    ch <- result
}()

Und das war’s. Kein Thread-Pool, kein Mutex, kein Deadlock-Risiko.

Was Go für Anfänger attraktiv macht: Die Sprache ist klein. Die Spezifikation hat weniger als 100 Seiten. Man kann die gesamte Sprache in einem Wochenende lesen und verstehen. Das bedeutet, dass man schnell produktiv ist — und dass es keine überraschenden Ecken gibt, die man noch nicht kennt.

Der Nachteil: Go ist pragmatisch, nicht elegant. Fehlerbehandlung ist if err != nil auf jeder zweiten Zeile. Keine Sum Types, keine Pattern Matching, keine Algebriaischen Datentypen. Wer aus der funktionalen Welt kommt, wird frustriert sein. Wer aus der Systemwelt kommt, wird begeistert sein.

Lernkurve: Flach bis mittel. Die Sprache ist schnell gelernt. Das Concurrency-Modell braucht mehr Zeit, um es richtig zu verstehen.

C — Weil man verstehen sollte, worauf alles läuft

C ist die Sprache, die man lernen sollte, wenn man verstehen will, wie Computer wirklich funktionieren. Nicht als erste Sprache — aber als zweite oder dritte.

#include <stdio.h>

int main(void) {
    printf("Hallo, Welt!\n");
    return 0;
}

Kompilieren mit gcc -o hallo hallo.c, ausführen mit ./hallo. Das ist mehr Aufwand als Python. Aber man sieht: Hier gibt es kein Automatisches Speichermanagement. Es gibt Pointer. Es gibt manuelle Speicherallokation mit malloc und free. Es gibt Buffer Overflows. Es gibt Segmentation Faults.

Und genau deshalb sollte man C lernen: Um zu verstehen, was unter den Abstraktionen passiert, die Python, JavaScript und Go bieten. Wenn man einmal einen Segfault debuggt hat, versteht man, warum Rusts Ownership-Modell existiert. Wenn man einmal malloc und free manuell verwaltet hat, versteht man, warum Garbage Collection nützlich ist.

Praktisch: C ist überall. Betriebssysteme (FreeBSD, Linux, Windows), eingebettete Systeme, Treiber, Datenbanken, Netzwerk-Stacks. Wenn man tief genug graben will, kommt man an C nicht vorbei.

Lernkurve: Mittel, aber mit Fallgruben. Die Syntax ist simpel. Die Semantik ist tief. Pointer und Speichermanagement sind die härteste Hürde für Anfänger.

Was ich nicht empfehle (und warum)

Java — Nicht weil Java schlecht ist, sondern weil der Einstiegs-Overhead frustrierend ist. Klassendefinition, public static void main(String[] args), javac, java — für ein Hello World braucht man mehr Boilerplate als in jeder anderen Sprache hier. Java lehrt OOP, aber OOP ist nicht das erste, was ein Anfänger braucht.

C++ — C++ ist mächtig, aber die Komplexität ist für Anfänger grausam. Die Sprache hat zu viele Wege, Dinge zu tun. Smart Pointers, Move Semantics, Templates, RAII — alles wichtig, alles überwältigend. Wer C++ lernen will, sollte zuerst C können.

PHP — PHP hat sich mit Version 8 deutlich verbessert. Aber das Ökosystem und die Kultur sind immer noch geprägt von einer Zeit, in der Sicherheit und Code-Qualität nachrangig waren. Als Einstiegssprache würde ich es heute nicht mehr empfehlen.

Die Reihenfolge, die ich vorschlage

  1. Python — Lernen, wie man denkt. Wie man Probleme in Schritte zerlegt. Wie man Code liest und schreibt.
  2. JavaScript — Lernen, wie man Dinge baut, die Menschen sehen und benutzen.
  3. C — Lernen, was unter der Haube passiert.
  4. Rust oder Go — Je nachdem, ob man Sicherheit (Rust) oder Einfachheit (Go) priorisiert.

Die wichtigste Erkenntnis: Die erste Sprache ist nicht die letzte. Man wird mehrere lernen. Die Frage ist nicht, welche Sprache man wählt, sondern ob man anfängt.

Und dafür gilt: Je weniger im Weg steht, desto besser. Deshalb Python.

Hello-World-Vergleich

SpracheZeilenKompilieren?Typsystem
Python1NeinDynamisch
JavaScript1NeinDynamisch
Go5JaStatisch
Rust3JaStatisch
C5JaStatisch

Weniger Zeilen bedeuten nicht zwingend eine einfachere Sprache. Aber für den Einstieg zählt: Wie schnell komme ich vom Öffnen des Editors zum ersten laufenden Programm? Und da gewinnt Python.

Autisten in der IT: Warum man sie einstellen sollte und was sie brauchen

admin Schreib einen Kommentar

Autismus und IT — das ist keine Zufallsbeziehung. Studien zeigen konsistent, dass Autisten in der IT-Branche überrepräsentiert sind. Das ist kein Klischee. Es ist eine Beobachtung, die sich in den Daten wiederfindet und die sich erklären lässt, wenn man versteht, was Autismus eigentlich ist: eine andere kognitive Architektur. Nicht besser. Nicht schlecher. Anders.

Und diese Andersartigkeit ist in der IT besonders wertvoll — weil die IT ein Feld ist, in dem Systemdenken, Mustererkennung und tiefes Eintauchen in komplexe Sachverhalte nicht nur nützlich sind, sondern die eigentliche Arbeitsgrundlage.

Aber es gibt auch eine Kehrseite: Die Arbeitswelt ist nicht für Autisten gebaut. Und das ist kein metaphorischer Satz — es ist eine konkrete Feststellung über Beleuchtung, Geräusche, Kommunikationsstrukturen, Erwartungshaltungen und Prozesse, die neurotypische Normalität als Default setzen.

Dieser Artikel beschreibt beides: Was Autisten in der IT leisten und was sie brauchen, um es leisten zu können.

Was Autismus in der IT bedeutet

Autismus ist ein Spektrum. Das bedeutet: Keine zwei Autisten sind gleich. Die folgenden Beschreibungen sind Muster, keine Diagnosekriterien, und sie treffen nicht auf jeden zu. Aber sie sind Muster, die sich in der Praxis häufig zeigen.

Wie Autisten denken

Systemdenken. Autisten tendieren dazu, Systeme als Ganzes zu erfassen — die Beziehungen zwischen Komponenten, die Regeln, die ein System steuert, die Architektur. Das ist nicht dasselbe wie „gut im Programmieren“. Es ist eine bestimmte Art, die Welt in Ordnung zu bringen: Wenn man die Regeln kennt, kann man das System verstehen. Wenn man das System versteht, kann man es verändern.

Mustererkennung. Autisten bemerken Muster, die andere übersehen. In Logfiles, in Codebases, in Fehlern, in Prozessen. Das ist keine übernatürliche Fähigkeit — es ist ein kognitiver Stil, der darauf ausgerichtet ist, Regelmäßigkeiten und Abweichungen zu identifizieren. In der IT ist das Gold wert: Debugging, Code-Review, Security-Analyse, Monitoring — alles Tätigkeiten, bei denen es darauf ankommt, das Anormale im Normalen zu finden.

Hyperfokus. Wenn ein Autist sich für ein Thema interessiert, kann er sich stundenlang damit beschäftigen, ohne Unterbrechung, ohne Langeweile, mit einer Intensität, die neurotypische Menschen selten erreichen. Das nennt man „Special Interest“ — und es ist kein Hobby, es ist eine kognitive Modalität. In der Praxis bedeutet das: Ein Autist, der sich für eine Codebase interessiert, wird sie verstehen — wirklich verstehen — auf eine Tiefe, die Wochen oder Monate normalem Lernfortschritt entspricht.

Detailorientierung. Autisten arbeiten oft von den Details nach oben: Erst die Einzelteile verstehen, dann das Gesamtsystem. Neurotypische Menschen tendieren zum umgekehrten Weg: Erst das Große, dann die Details. Beide Ansätze haben Berechtigung. Aber in der IT — wo ein fehlendes Semikolon eine Produktionsstörung verursacht, wo eine falsche Berechtigung ein Sicherheitsloch öffnet, wo ein Overflow einen Kernel-Crash auslöst — ist der detailorientierte Ansatz nicht nur nützlich, sondern notwendig.

Wo Autisten besonders wertvoll sind

Debugging und Fehleranalyse

Debugging ist Mustererkennung in Reinform: Etwas verhält sich anders als erwartet, und man muss herausfinden, warum. Autisten sind oft herausragend im Debugging, weil sie die Geduld haben, Schicht für Schicht abzutragen, und weil ihr Gehirn darauf programmiert ist, Abweichungen von Mustern zu bemerken.

Das ist kein Mythos. Es ist eine Konsequenz der Art, wie autistische Wahrnehmung funktioniert: Wenn man die Welt in Mustern wahrnimmt, fällt ein Musterbruch sofort auf.

Code-Review und Qualitätssicherung

Code-Review erfordert dieselben Fähigkeiten: Lesen, Verstehen, Abweichungen identifizieren. Autisten lesen Code oft anders als neurotypische Entwickler — sie nehmen ihn strukturierter, systematischer wahr. Sie bemerken Inkonsistenzen, die andere übersehen, weil für sie die innere Logik des Codes genauso präsent ist wie die Oberflächenbedeutung.

Systemadministration und Infrastruktur

Systemadministration ist ein Gebiet, in dem Autisten traditionell stark vertreten sind. Das ist kein Zufall: Die Arbeit erfordert tiefes Verständnis komplexer, vernetzter Systeme, Präzision in der Konfiguration und die Fähigkeit, bei Ausfällen ruhig und systematisch vorzugehen. Die Belohnung ist ein System, das funktioniert — ein klares, messbares Ergebnis. Das passt.

Security

Informationssicherheit ist ein Bereich, in dem autistische Stärken besonders zur Geltung kommen: Mustererkennung in Netzwerkverkehr, Analyse von Exploit-Ketten, Penetration Testing (systematisches Vorgehen nach klaren Regeln), Code-Audit (Abweichungen von sicheren Mustern finden). Die Hackerkultur war schon immer ein Ort, an dem neurodiverse Menschen willkommen waren — lange bevor Unternehmens-IT den Begriff „Diversity“ entdeckte.

Architektur und Design

Softwarearchitektur ist Systemdenken auf einer höheren Ebene: Wie interagieren Komponenten? Was sind die Abhängigkeiten? Wo sind die Engpässe? Autisten, die von Natur aus Systeme denken, haben hier einen echten Vorteil — besonders wenn die Architektur komplex ist und klare Struktur erfordert.

Dokumentation und Wissensmanagement

Autisten neigen dazu, Dinge vollständig und präzise zu dokumentieren — weil für sie eine unvollständige Dokumentation ein fehlerhaftes System ist. Das kann zu Perfektionismus führen (ein Risiko), aber es kann auch zu Dokumentation führen, die tatsächlich nützlich ist. In einer Branche, in der Dokumentation oft das Stiefkind ist, ist das wertvoll.

Die Herausforderungen

Jetzt der schwierige Teil. Denn die gleichen Eigenschaften, die Autisten in der IT wertvoll machen, können in einer Arbeitsumgebung, die nicht für sie gebaut ist, zu massiven Problemen führen.

Sensorische Überlastung

Das ist das Problem, das am meisten unterschätzt wird und das am häufigsten zu Burnout führt.

Büros sind für neurotypische Menschen gebaut: Offene Raumkonzepte, Neonbeleuchtung, Hintergrundmusik, Gespräche, Tastaturklackern, Klimaanlagenbrummen. Für Autisten ist das keine Unannehmlichkeit — es ist ein permanenter Angriff auf das sensorische System. Das Gehirn muss kontinuierlich filtern, was für neurotypische Menschen automatisch gefiltert wird. Das kostet Energie. Energie, die dann für die eigentliche Arbeit fehlt.

Die Konsequenz: Ein Autist, der in einem Open-Office acht Stunden arbeitet, leistet nicht 80% von dem, was er in einem ruhigen Raum leisten könnte. Sondern vielleicht 30%. Weil der Großteil der kognitiven Kapazität in die Sensorik-Filterung geht.

Kommunikationsstrukturen

Neurotypische Kommunikation ist implizit: Tonfall, Mimik, Kontext, das Ungesagte zwischen den Zeilen. Autistische Kommunikation ist explizit: Man sagt, was man meint, und meint, was man sagt. Das führt zu Missverständnissen in beide Richtungen:

  • Autist zu neurotypisch: „Das wird nicht funktionieren.“ — Gemeint: Die Architektur hat ein grundlegendes Problem. — Verstanden: Der Autist ist negativ und unmotiviert.
  • Neurotypisch zu Autist: „Wir sollten uns das mal ansehen.“ — Gemeint: Mach das bitte bis morgen. — Verstanden: Irgendwann, wenn es passt, soll man sich das ansehen.

Die Implizitheit neurotypischer Kommunikation ist für Autisten eine ständige Quelle von Unsicherheit. Man weiß nie genau, was gemeint ist. Man rät. Man rät oft falsch. Das erzeugt Stress. Und Stress erzeugt Fehler.

Meetings

Meetings sind für viele Autisten eine Qual. Nicht, weil sie nicht zuhören können — sondern weil sie zu gut zuhören. Jedes Nebengeräusch, jede Unterbrechung, jedes gleichzeitige Gespräch wird wahrgenommen und verarbeitet. Nach einem einstündigen Meeting ist ein Autist oft erschöpft, ohne auch nur eine produktive Zeile Code geschrieben zu haben.

Dazu kommt: Meetings verlangen schnelles Reagieren. „Was denkst du dazu?“ — und man hat drei Sekunden Zeit. Autisten brauchen oft länger, um eine Antwort zu formulieren — nicht, weil sie langsamer denken, sondern weil sie gründlicher denken. Sie wollen die vollständige Antwort, nicht die schnelle.

Wechselnde Anforderungen und Kontextwechsel

Autisten bevorzugen Vorhersehbarkeit. Ein Arbeitstag, der um 9:00 mit einer bekannten Aufgabe beginnt und um 17:00 mit einem fertigen Ergebnis endet, ist ideal. Ein Arbeitstag, der um 9:00 mit einer Aufgabe beginnt, um 10:30 mit einem „Kannst du kurz in dieses Meeting?“ unterbrochen wird, um 11:15 eine Slack-Nachricht mit einer „dringenden“ Frage bekommt, und um 14:00 erfährt, dass die Anforderungen geändert wurden — das ist nicht „normaler Arbeitstag“. Das ist ein kognitiver Angriff.

Jeder Kontextwechsel kostet autistischen Menschen mehr Energie als neurotypischen. Das ist kein Mythos, es ist messbar in den kognitiven Ressourcen, die für das Umschalten aufgewendet werden müssen. Das bedeutet: Ein Arbeitstag mit drei Unterbrechungen ist produktiver als ein Arbeitstag mit dreißig — und der Unterschied ist nicht marginal.

Masking

Masking ist der Versuch, neurotypisch zu erscheinen: Blickkontakt simulieren, Smalltalk führen, unauffällig sein. Fast alle Autisten in der IT machen es. Es ist Überlebensstrategie, nicht Wahl.

Das Problem: Masking kostet enorme Mengen Energie. Energie, die für die eigentliche Arbeit fehlt. Und es führt zu langfristigen psychischen Belastungen — Burnout, Depression, Identitätsverlust. Autisten, die jahrelang gemasked haben, berichten davon, dass sie irgendwann nicht mehr wissen, wer sie eigentlich sind.

Unklare Erwartungen

„Sei ein Teamplayer.“ „Zeige Initiative.“ „Kommunikation ist wichtig.“ — Das sind keine klaren Erwartungen. Das sind Interpretationsspielräume. Für Autisten ist das ein Minenfeld: Was heißt „Teamplayer“? Soll man Meetings besuchen? Soll man helfen? Soll man Freundschaften schließen? Was heißt „Initiative“? Soll man Aufgaben übernehmen, die niemand zugewiesen hat? Soll man Vorschläge machen? Wie oft? In welchem Format?

Neurotypische Menschen verstehen diese Implizitheiten intuitiv. Autisten verstehen sie nicht — und werden oft als „schwierig“ oder „nicht kooperativ“ wahrgenommen, weil sie nachfragen, was genau gemeint ist.

Wie man Autisten unterstützt

Die gute Nachricht: Die meisten Maßnahmen, die Autisten helfen, sind weder teuer noch aufwendig. Sie erfordern nur das Bewusstsein, dass die Default-Einstellungen der Arbeitswelt nicht für alle optimal sind.

Räumliche Anpassungen

Ruhige Arbeitsplätze. Ein eigenes Büro, ein ruhiger Winkel, Noise-Cancelling-Kopfhörer — das ist keine „Sonderbehandlung“, es ist eine sinnvolle Arbeitsplatzgestaltung. Ein Autist in einem ruhigen Raum leistet mehr als zwei Autisten in einem Open-Office.

Beleuchtung. Neonröhren, die flackern, können für Autisten körperlich schmerzhaft sein. Dimmbare LED-Panels, Tageslichtlampen, die Möglichkeit, das Licht anzupassen — kleine Änderungen, große Wirkung.

Sitzplatzwahl. Nicht mit dem Rücken zur Tür. Nicht direkt neben dem Kaffeeautomaten. Nicht am Durchgang. Das sind keine Vorlieben — das sind Anforderungen.

Kommunikative Anpassungen

Explizit sein. „Bitte erledige das bis Freitag 17:00 Uhr“ statt „Wir brauchen das bald.“ „Schreib eine E-Mail mit den drei wichtigsten Punkten“ statt „Kommunikation wäre gut.“ Je präziser, desto besser.

Schriftlich bevorzugen. Asynchrone Kommunikation — E-Mails, Tickets, Dokumentation — ist für Autisten oft viel besser als synchrone — Meetings, Telefonate, spontane Gespräche. Nicht weil sie nicht kommunizieren wollen, sondern weil schriftliche Kommunikation ihnen die Zeit gibt, die sie brauchen, um präzise zu antworten.

Nicht auf sofortige Antworten bestehen. Wenn man jemanden in einem Meeting fragt und keine sofortige Antwort bekommt, heißt das nicht, dass er nichts zu sagen hat. Es heißt, dass er nachdenkt. „Lass uns das nach dem Meeting schriftlich klären“ ist eine einfache und wirkungsvolle Anpassung.

Strukturelle Anpassungen

Vorhersehbarkeit. Klare Arbeitszeiten, klare Aufgaben, klare Deadlines. Änderungen frühzeitig ankündigen, nicht spontan überstülpen. Sprint-Planung statt Ad-hoc-Zuweisung.

Geschützte Fokuszeiten. Blöcke von 2-4 Stunden, in denen keine Meetings angesetzt werden und Slack auf stumm geschaltet ist. Das ist kein Luxus — es ist die Zeit, in der die eigentliche Arbeit passiert.

Onboarding anpassen. Autisten brauchen oft länger für das Onboarding, weil sie ein System vollständig verstehen wollen, bevor sie damit arbeiten. Das ist kein Nachteil — es bedeutet, dass sie nach dem Onboarding tiefer verstehen als jemand, der sich schnell zurechtfindet.

Kulturelle Anpassungen

Masking nicht erwarten. Wenn ein Autist keinen Blickkontakt macht, ist das kein Zeichen von Desinteresse. Wenn er keinen Smalltalk macht, ist das kein Zeichen von Unhöflichkeit. Es ist ein Zeichen dafür, dass er Energie für die eigentliche Arbeit aufspart.

Direkte Kommunikation zulassen. „Das wird nicht funktionieren“ ist kein Angriff. Es ist eine Einschätzung. Wer direkte Kommunikation als Konflikt wahrnimmt, muss seine Konfliktwahrnehmung kalibrieren — nicht den Autisten bitten, diplomatischer zu sein.

Spezialinteressen ernst nehmen. Wenn ein Autist sich für ein Thema begeistert, ist das keine „Obsession“. Es ist eine Ressource. Ein Entwickler, der sich tief für Compilerbau interessiert, wird ein besseres Build-System bauen als jemand, dem es egal ist.

Warum man Autisten einstellen sollte

Jetzt die wirtschaftliche Perspektive, weil die menschliche offensichtlich sein sollte, es aber leider oft nicht ist.

Autisten sind keine Diversitäts-Checkbox

Wenn Unternehmen Autisten einstellen, um eine Diversitätskennzahl zu erfüllen, haben sie schon verloren. Nicht weil Diversität unwichtig wäre — sondern weil der Ansatz das Problem ist. Man stellt Autisten ein, weil sie exzellent sind. Weil sie Dinge können, die andere nicht können. Weil sie Probleme lösen, die andere nicht einmal sehen.

Die Diversität ist ein Nebeneffekt, kein Ziel.

Messbare Vorteile

Tiefe Expertise. Ein Autist, der sich auf ein Gebiet spezialisiert hat, hat oft ein Wissensniveau, das Neurotypische in derselben Zeit nicht erreichen. Das Hyperfokus-Phänomen ist real: Wenn jemand 16 Stunden am Tag in eine Codebase vertieft ist, versteht er sie besser als jemand, der 8 Stunden mit Unterbrechungen arbeitet.

Geringere Fluktuation. Autisten wechseln seltener den Arbeitgeber, wenn die Rahmenbedingungen stimmen. Nicht aus Loyalität — aus Pragmatismus: Einen Arbeitsplatz, der funktioniert, wechselt man nicht für ein höheres Gehalt. Das spart Recruiting-Kosten, Onboarding-Zeit und implizites Wissen, das mit jedem Wechsel verloren geht.

Innovation durch andere Perspektive. Autisten denken anders. Das ist kein Buzzword — es ist eine Konsequenz einer anderen kognitiven Architektur. Wenn ein Team aus lauter Menschen besteht, die ähnlich denken, entstehen blinde Flecken. Ein Autist im Team kann den blinden Flecken sichtbar machen — weil für ihn das, was für alle „offensichtlich“ ist, oft nicht offensichtlich ist.

Präzision und Qualität. Autisten haben oft einen höheren Qualitätsanspruch als ihre neurotypischen Kollegen. Das kann zu Konflikten führen („Es ist gut genug“), aber es führt auch zu Software, die tatsächlich funktioniert. Die Frage ist, ob „gut genug“ wirklich gut genug ist — oder ob man jemanden braucht, der das letzte Prozent mitnimmt.

Zuverlässigkeit. Autisten halten sich an Regeln. Das ist keine Charaktereigenschaft — es ist eine kognitive Notwendigkeit. Wenn die Regel sagt, dass ein Deployment-Pipeline durchlaufen muss, bevor Code in Produktion geht, wird ein Autist keinen Shortcut nehmen. In einer Branche, in der Shortcuts zu Ausfällen führen, ist das wertvoll.

Was Autisten selbst tun können

Dieser Artikel wäre unvollständig, wenn er nur die Umgebung adressieren würde. Autisten sind nicht passive Empfänger von Anpassungen — sie können aktiv dazu beitragen, dass die Zusammenarbeit funktioniert.

Kommunizieren, was man braucht. „Ich arbeite am besten, wenn ich ungestört bin.“ „Ich brauche Aufgaben schriftlich.“ „Meetings erschöpfen mich — kann ich asynchron teilnehmen?“ Das ist keine Schwäche — es ist Professionalität. Wer seine Arbeitsbedingungen kennt und kommuniziert, ist besser als jemand, der schweigt und dann nicht liefert.

Grenzen setzen. Nicht jedes Meeting muss man besuchen. Nicht jede Slack-Nachricht muss man sofort beantworten. Nicht jede Einladung zum After-Work muss man annehmen. Grenzen zu setzen ist kein egoistisch — es ist notwendig, um langfristig leistungsfähig zu bleiben.

Stärken einsetzen. Wenn man gut im Debugging ist, dann debuggt man. Wenn man gut in der Dokumentation ist, dann dokumentiert man. Wenn man gut in der Architektur ist, dann archtektiert man. Die Gesellschaft — und insbesondere die IT — neigt dazu, Schwächen zu fixieren statt Stärken zu nutzen. Das ist ineffizient.

Burnout-Signale ernst nehmen. Wenn man merkt, dass man erschöpft ist, dass die Sensorik überlastet ist, dass das Masking nicht mehr funktioniert — dann ist es Zeit, etwas zu ändern. Nicht durchzuhalten. Durchhalten ist die Falle, in die Autisten besonders leicht tappen, weil sie gelernt haben, dass ihre Bedürfnisse „unnormal“ sind.

Die unbequeme Wahrheit

Die IT-Branche profitiert massiv von Autisten. Sie hat davon immer profitiert — lange bevor jemand den Begriff „Neurodiversität“ kannte. Die Pioniere der Informatik waren oft Menschen, die heute als autistisch diagnostiziert würden: Alan Turing, Grace Hopper, Dennis Ritchie — Menschen mit einer Intensität und einem Systemdenken, das nicht „normal“ war, aber das Feld erst möglich gemacht hat.

Die unbequeme Wahrheit ist: Die IT braucht Autisten mehr, als Autisten die IT brauchen. Ohne autistische Denkmuster gäbe es keine Betriebssysteme, keine Compiler, keine Netzwerkprotokolle, keine Kryptografie — keine der Infrastrukturen, auf denen die gesamte moderne Softwarewelt aufbaut.

Und trotzdem ist die Arbeitswelt so gebaut, dass sie die Menschen ausschließt, die sie am meisten braucht.

Das ist kein Trugschluss. Das ist eine Beobachtung. Und es ist eine Aufforderung: Wenn die IT Autisten beschäftigen will — und sie will es, auch wenn sie es nicht so nennt —, dann muss sie aufhören, neurotypische Normalität als Default zu setzen und alles andere als Anpassung zu behandeln.

Ein ruhiger Arbeitsplatz ist keine Sonderbehandlung. Schriftliche Kommunikation ist keine Zumutung. Explizite Erwartungen sind kein Mikromanagement. Es sind vernünftige Arbeitsbedingungen, die allen helfen — nicht nur Autisten.

Und der größte Gewinn ist nicht die Diversitätskennzahl. Der größte Gewinn ist, dass jemand, der Systeme wirklich versteht, in einem System arbeiten kann, das ihn nicht ständig bekämpft.

Infrastructure as Code: Warum Handarbeit auf Servern gefährlich ist

admin Schreib einen Kommentar

Jeder Systemadministrator kennt den Moment: Man meldet sich auf einem Server an, führt ein paar Befehle aus, ändert eine Konfigurationsdatei, installiert ein Paket. Alles funktioniert. Ein paar Wochen später steht man vor demselben Problem — nur auf einem anderen Server. Und man kann sich nicht mehr erinnern, welche Befehle man ausgeführt hat. Der Server ist ein Schneemann: Er sieht aus wie die anderen, aber unter der Oberfläche ist alles anders.

Infrastructure as Code (IaC) ist die Antwort auf dieses Problem. Und wer als Softwareentwickler und Administrator — wie ich — beide Welten kennt, weiß, dass IaC nicht nur ein Trend ist, sondern eine Notwendigkeit.

Das Problem mit manuellen Servern

Manuelle Administration skaliert nicht. Das ist keine Meinungsfrage, sondern Mathematik. Wenn jeder Server ein Unikat ist, dann ist jeder Server ein Risiko. Wenn ein Server ausfällt und niemand weiß, wie er konfiguriert war, dann ist der Wiederherstellungsprozess ein Glücksspiel.

Die typischen Symptome sind vertraut:

  • Konfigurationsdrift. Server, die identisch sein sollten, unterscheiden sich in subtilen — und manchmal kritischen — Details.
  • Wissensmonopole. Nur eine Person weiß, wie ein bestimmter Server konfiguriert ist. Wenn diese Person krank wird oder geht, ist das Wissen weg.
  • Nicht-reproduzierbare Zustände. Ein Server funktioniert, aber niemand kann erklären, warum. Oder schlimmer: Niemand kann ihn neu aufsetzen.
  • Angst vor Änderungen. Weil niemand weiß, was passieren wird, wenn man etwas ändert, ändert man nichts. Bis man es muss. Und dann ist es zu spät.

Was Infrastructure as Code bedeutet

IaC ist nicht einfach „Skripte schreiben“. Es ist ein Paradigmenwechsel in der Art und Weise, wie wir über Infrastruktur denken.

Deklarativ statt imperativ. Statt zu beschreiben wie ein Server konfiguriert werden soll („installiere nginx, kopiere die Konfiguration, starte den Dienst“), beschreibt man was der Zustand sein soll („nginx muss installiert sein, die Konfiguration muss diesen Inhalt haben, der Dienst muss laufen“). Der IaC-Workflow kümmert sich um das Wie.

Versioniert. Jede Änderung an der Infrastruktur ist in Git committet. Man kann sehen, wer was wann geändert hat. Man kann zu einem früheren Zustand zurückkehren. Man kann Änderungen über Code-Reviews prüfen lassen.

Reproduzierbar. Wenn ein Server ausfällt, kann er aus der IaC-Definition komplett neu aufgesetzt werden. Wenn ein neuer Server benötigt wird, kann er in Minuten statt Stunden erstellt werden.

Testbar. Bevor eine Änderung auf Produktion geht, kann sie in einer Testumgebung validiert werden. Syntaxfehler, fehlende Abhängigkeiten, inkompatible Konfigurationen — alles wird erkannt, bevor es Schaden anrichtet.

Die Werkzeuge

Die Wahl des Werkzeugs hängt vom Kontext ab. Hier eine Übersicht der etablierten Optionen:

Ansible

Das probably bekannteste IaC-Werkzeug. Ansible ist agentenlos (arbeitet über SSH), verwendet YAML für die Konfiguration und hat eine flache Lernkurve. Für FreeBSD-Administratoren ist es attraktiv, weil es native Module für ZFS, Jails, pkg und andere FreeBSD-Spezifika hat.

- name: ZFS-Dataset für Backup erstellen
  community.general.zfs:
    name: tank/backup
    state: present
    extra_zfs_properties:
      compression: zstd
      atime: off
      mountpoint: /backup

Der Nachteil: Ansible ist langsam bei großen Infrastrukturen und die YAML-Syntax wird bei komplexen Logiken unübersichtlich.

Terraform / OpenTofu

Für Cloud-Infrastrukturen ist Terraform (oder der Open-Source-Fork OpenTofu) der De-facto-Standard. Es verwaltet die Infrastruktur als Ressourcen — Instanzen, Netzwerke, Sicherheitsgruppen, Speicher — und hält den Zustand in einer State-Datei.

resource "aws_instance" "freebsd" {
  ami           = "ami-0xfreebsd15"
  instance_type = "t3.medium"

  tags = {
    Name = "freebsd-prod"
  }
}

Pulumi

Pulumi geht einen anderen Weg: Statt YAML oder HCL verwendet man echte Programmiersprachen — Python, TypeScript, Go. Das erlaubt echte Logik, Schleifen, Bedingungen und Typsicherheit.

import pulumi
import pulumi_command as command

server = command.remote.Command("freebsd-setup",
    connection=command.remote.ConnectionArgs(
        host="10.0.0.1",
        user="root",
    ),
    create="pkg install -y nginx",
)

Für FreeBSD: Besonderheiten

FreeBSD bringt eigene Werkzeuge mit, die in der IaC-Welt eine Sonderrolle einnehmen:

  • Jails sind leichtgewichtige Container, die sich hervorragend mit Ansible oder Shell-Skripten verwalten lassen.
  • ZFS bietet programmierbare Snapshots und Replikation, die sich in IaC-Workflows integrieren lassen.
  • pkgbase (seit FreeBSD 15.0) macht das Basissystem selbst paketierbar und damit IaC-kompatibel.

Der Pfad zur Einführung

IaC lässt sich nicht über Nacht einführen. Aber man kann schrittweise vorgehen:

  1. Bestandsaufnahme. Welche Server gibt es? Welche Konfigurationen? Was ist dokumentiert, was nicht?
  2. Ersten Server codifizieren. Den einfachsten Server nehmen und seine Konfiguration in Ansible (oder ein anderes Werkzeug) übertragen. Das dient als Lernprojekt und als Template.
  3. Neue Server nur noch via IaC. Jeder neue Server wird ausschließlich über Code konfiguriert. Keine manuellen Änderungen mehr.
  4. Bestehende Server migrieren. Nach und nach die manuelle Konfiguration durch IaC-Definitionen ersetzen. Das ist der langwierigste Teil.
  5. CI/CD für Infrastruktur. Änderungen an der IaC-Definition werden automatisch in Testumgebungen deployed, bevor sie auf Produktion gehen.

Die Kultur ändert sich mit

IaC ist nicht nur ein technischer Wechsel, sondern ein kultureller. Plötzlich sind Konfigurationsänderungen sichtbar. Jeder kann sie sehen, kommentieren, zurückrollen. Das ist ungewohnt — besonders für Administratoren.

Aber es ist der richtige Weg. In einer Welt, in der Sicherheitseinheiten täglich nachweisen müssen, welche Konfiguration auf welchem Server zu welchem Zeitpunkt aktiv war, ist manuelle Administration ein Risiko, das man sich nicht mehr leisten kann.

Und für den einzelnen Administrator ist IaC eine Erleichterung: Man muss sich nicht mehr erinnern, was man auf welchem Server gemacht hat. Es steht alles im Git-Repository. Wenn man nicht weiß, wie ein Server konfiguriert ist — man schaut nach. Immer. Zuverlässig. Ohne Ausnahme.

Automatisierung als Geschäftsmodell: Warum IT-Dienstleister ohne Automatisierung untergehen

Thorsten Geppert Schreib einen Kommentar

Wer IT-Dienstleistungen verkauft, hat ein Problem: Seine Zeit ist begrenzt. Jede Stunde, die er an einem Kundensystem verbringt, ist eine Stunde, die er nicht für einen anderen Kunden aufwenden kann. Das Geschäftsmodell des klassischen IT-Dienstleisters — Stunden abrechnen, Probleme manuell lösen, individuell betreuen — hat eine harte Decke.

Automatisierung ist der Weg durch diese Decke. Und wer als Softwareentwickler und Administrator die Werkzeuge beherrscht, hat einen entscheidenden Vorteil: Er kann Automatisierung nicht nur anwenden, sondern bauen.

Das Problem mit dem Stundensatz

Ein klassischer IT-Dienstleister verrechnet vielleicht 80 bis 120 Euro pro Stunde. Wenn er 40 Stunden in der Woche arbeitet (realistisch sind es weniger, weil Akquise, Verwaltung und Reisezeit abgehen), ergibt das eine Umsatzdecke von etwa 160.000 bis 240.000 Euro im Jahr. Davon gehen Steuern, Versicherungen, Fortbildung, Arbeitsplatzkosten ab.

Skalierung ist in diesem Modell nur möglich, indem man Mitarbeiter einstellt. Aber jeder Mitarbeiter bringt neuen Verwaltungsaufwand, Schulungsbedarf, Qualitätskontrolle. Der Gewinn pro Kopf sinkt, wenn man nicht gleichzeitig die Effizienz steigert.

Was Automatisierung ändert

Automatisierung verändert die Mathematik. Statt eine Aufgabe einmal pro Kunde manuell zu erledigen, baut man sie einmal — und deployt sie x-mal.

Beispiel: Ein Kunde braucht einen Webserver mit Nginx, PHP-FPM, SSL-Zertifikaten und einer Monitoring-Lösung. Manuell dauert das — wenn man ehrlich ist — einen halben Tag. Mit Automatisierung dauert es beim ersten Kunden auch einen halben Tag (zuzüglich der Zeit für das Skript/Playbook). Bei jedem weiteren Kunden dauert es fünf Minuten.

Der Effekt: Die Kosten pro Deployment sinken drastisch, während die Qualität steigt. Automatisierte Deployments sind reproduzierbar, testbar, dokumentiert. Manuelle Deployments sind — wie oben beschrieben — Schneemänner.

Konkrete Automatisierungsfelder

Systemadministration

Alles, was auf einem Server konfiguriert wird, kann automatisiert werden:

  • Server-Setup — Basiskonfiguration, Benutzer, SSH-Keys, Firewall-Regeln
  • Dienst-Konfiguration — Webserver, Datenbanken, Mailserver, Monitoring
  • Updates und Patching — Automatisierte Aktualisierungen mit Rollback-Möglichkeit
  • Backup und Recovery — ZFS-Snapshots, Replikation, automatisierte Restore-Tests

Kundenschnittstelle

  • Onboarding — Neukunden bekommen automatisch ihre Infrastruktur
  • Reporting — Wöchentliche Statusberichte automatisch generiert und versendet
  • Abrechnung — Nutzungsbasierte Abrechnung direkt aus Monitoring-Daten
  • Ticket-Routing — Automatische Zuordnung von Support-Anfragen

Compliance und Dokumentation

  • Audit-Logs — Jede Änderung an der Infrastruktur ist in Git dokumentiert
  • Compliance-Checks — Automatisierte Überprüfung von Sicherheitsstandards
  • Disaster-Recovery-Tests — Regelmäßige, automatisierte Tests der Wiederherstellungsprozesse

Der Preis der Automatisierung

Automatisierung ist nicht kostenlos. Sie erfordert:

Zeit. Die Erstellung eines robusten Ansible-Playbooks dauert länger als die manuelle Konfiguration eines einzelnen Servers. Die Investition amortisiert sich erst ab dem zweiten oder dritten Deployment.

Kompetenz. Wer automatisiert, muss programmieren können. Nicht auf dem Niveau eines Software-Entwicklers, aber ausreichend, um Skripte zu schreiben, Datenstrukturen zu verstehen und Fehler zu diagnostizieren.

Wartung. Automatisierte Prozesse müssen gepflegt werden. Wenn sich Upstream-Software ändert, müssen die Playbooks angepasst werden. Wenn neue Anforderungen dazukommen, müssen sie integriert werden.

Aber — und das ist der entscheidende Punkt — diese Kosten fallen einmal an. Die manuellen Kosten fallen jedes Mal an.

Vom Dienstleister zum Produkt

Die konsequente Automatisierung öffnet einen Weg, der über das Dienstleistungsgeschäft hinausgeht: den Übergang zum Produkt.

Wenn die Infrastruktur-Einrichtung automatisiert ist, kann man sie als Self-Service anbieten. Der Kunde wählt seine Konfiguration über ein Web-Interface, das System richtet alles automatisch ein, und der Dienstleister muss nur noch überwachen und bei Problemen eingreifen.

Das ist der Weg, den erfolgreiche IT-Unternehmen gegangen sind: Hetzner mit der Robot-Weboberfläche, GitLab mit seinem CI/CD-Produkt, HashiCorp mit Terraform Cloud. Alle haben begonnen, Dienstleistungen manuell zu erbringen, und sie dann in Produkte verwandelt.

Für kleine IT-Dienstleister bedeutet das nicht, dass man ein SaaS-Startup werden muss. Aber es bedeutet, dass man seine wiederkehrenden Aufgaben identifizieren, automatisieren und als Paket anbieten kann — zu einem Preis, der manuell nicht erreichbar ist.

Der erste Schritt

Wer mit Automatisierung anfangen will, sollte nicht versuchen, alles auf einmal umzustellen. Der beste erste Schritt ist:

  1. Den häufigsten wiederkehrenden Prozess identifizieren
  2. Ihn einmal vollständig automatisieren
  3. Die Zeitersparnis messen
  4. Den nächsten Prozess angehen

Bei mir war das die ZFS-Replikation mit Syncoid. Ein Prozess, der vorher jeden Abend manuell überprüft werden musste und regelmäßig Probleme verursacht hat. Nach der Automatisierung läuft er im Hintergrund — zuverlässig, reproduzierbar, fehlerfrei.

Die Zeit, die ich dadurch gewonnen habe, habe ich in die nächste Automatisierung investiert. Und die nächste. Irgendwann war der Punkt erreicht, an dem ich mehr Zeit für echte Problemlösung hatte als für wiederkehrende Aufgaben.

Das ist das Versprechen der Automatisierung. Und es hält, was es verspricht — wenn man den anfänglichen Aufwand investiert.

FreeBSD-Wochenrückblick: 6.–13. April 2026

Thorsten Geppert Schreib einen Kommentar

Die Kalenderwoche 15 bringt Bewegung in mehrere Baustellen: Der 15.1-Zeitplan ist offiziell, das Laptop-Projekt ruft zum Community-Test auf, OpenZFS bekommt endlich eine native relatime-Property, und auf freebsd-current wird hitzig über IPv6-only-RA-Flags und einen knote-Panic diskutiert.

FreeBSD 15.1: Zeitplan veröffentlicht, Code Slush am 17. April

Am 3. April verschickten die Release Engineers die offizielle Zeitplan-Erinnerung für FreeBSD 15.1. Die wichtigsten Termine:

MeilensteinGeplant
Code Slush beginnt17. April 2026
releng/15.1-Branch1. Mai
BETA11. Mai
RC122. Mai
RELEASE2. Juni

Der Code Slush startet also noch diese Woche: Ab dem 17. April sollten keine neuen Features mehr in den stable/15-Branch eingefügt werden. Commits sind weiterhin möglich, aber der Fokus verlagert sich auf Stabilität und Bugfixes.

Die Release Notes-Seite existiert bereits und listet die geplanten Neuerungen: KDE-Plasma-6-Installer-Option, verbesserte Realtek-WiFi-Unterstützung (RTW88/RTW89), aktualisierte Grafiktreiber und erweiterte Power-Management-Features.

Was das heißt: Wer noch Änderungen für 15.1 einbringen will, hat noch wenige Tage. Danach geht es in die Beta-Phase.

Laptop-Integration-Testing-Projekt: Aufruf an die Community

Die FreeBSD Foundation hat ein neues Community-Test-Programm ins Leben gerufen: das Laptop Integration Testing Project. LWN berichtete am 6. April darüber.

Die Idee: Die Foundation hat begrenzten Zugang zu Test-Hardware und will die Community einbinden. Freiwillige können FreeBSD auf ihrem Laptop testen und Ergebnisse über ein GitHub-Repository einreichen — ohne sich um Umgebungssetup, Formatierung oder Repo-Details kümmern zu müssen.

Besonders wertvoll: Nicht nur automatisierte Hardware-Erkennung, sondern auch manuelle Kommentare zur persönlichen Erfahrung mit FreeBSD auf dem jeweiligen Gerät. Die Ergebnisse werden in einer öffentlichen Kompatibilitäts-Matrix dargestellt.

Was das heißt: Endlich ein strukturierter Weg, Laptop-Kompatibilität zu dokumentieren. Wer FreeBSD auf einem Laptop nutzt, sollte das Repository besuchen und Ergebnisse einreichen — jeder Eintrag zählt.

Repository: github.com/FreeBSDFoundation/freebsd-laptop-testing

OpenZFS: Native relatime-Property für FreeBSD

Alexander Motin (amotin) hat am 1. April einen lang erwarteten Commit in OpenZFS gemerged: relatime als native ZFS-Property auf FreeBSD.

Bisher mussten FreeBSD-Nutzer, die relatime (relative Access-Time-Updates — atime wird nur geschrieben, wenn sie älter als mtime/ctime ist oder älter als 24 Stunden) nutzen wollten, auf den Mount-Option-Workaround zurückgreifen. Mit dem neuen Commit wird relatime zu einer echten ZFS-Dataset-Eigenschaft, die sich per zfs set relatime=on pool/dataset setzen lässt.

Die Implementierung folgt der Linux-Kernel-Logik: atime wird nur aktualisiert, wenn mindestens eine der Bedingungen erfüllt ist:

  • atime < mtime
  • atime < ctime
  • atime älter als 24 Stunden

Was das heißt: Weniger unnötige ZFS-Writes bei Lesezugriffen, besonders auf SSDs und Laptops. Wer atime=on braucht (z.B. für Maildir oder Backup-Tools), kann jetzt relatime=on setzen und bekommt das Beste aus beiden Welten.

Mailinglisten: IPv6-only-RA-Flag soll weichen

Pouria Mousavizadeh Tehrani hat am 2. April auf freebsd-current einen Vorschlag zur Diskussion gestellt: Die Entfernung der IPv6-only-RA-Draft-Implementierung zugunsten von RFC 8925 (DHCP-basierter Ansatz).

Hintergrund: Bjoern Zeeb hatte eine IPv6-only-Flag-Implementierung als IETF-Draft eingereicht, die auch im FreeBSD-Kernel und Userland vorhanden ist (standardmäßig nicht kompiliert, hinter DRAFT_IETF_6MAN_IPV6ONLY_FLAG). Das Draft wurde jedoch vom IETF aufgegeben, weil RA-Flags trivial fälschbar sind und für Malicious-Disabling von IPv4-Netzwerken missbraucht werden könnten. RFC 8925 verwendet stattdessen eine DHCP-Option, die in der Praxis durch DHCP Snooping besser geschützt ist.

Pouria bittet um Zustimmung, die Draft-spezifischen Codepfade zu entfernen und auf RFC 8925 zu migrieren. Bjoern ist cc’d, und die Diskussion läuft.

Was das heißt: Wer die experimentelle IPv6-only-RA-Flag nutzt, sollte auf RFC 8925 umsteigen. Die Code-Bereinigung ist ein guter Schritt — weniger tote Pfade im Kernel.

Mailinglisten: knote-Panic und etcupdate-Verlangsamung

Zwei aktuelle Probleme auf freebsd-current:

knote-Panic: Nach Commit d9d7b5948649 (main-n284826) tritt bei einigen Nutzern ein Panic auf: "knote ... was already on knlist...". Konstantin Belousov und Kyle Evans arbeiten an der Diagnose. Der Bug (Bugzilla #293382) betrifft closefp_impl und kann zu Deadlocks und Kernel-Crashes führen. Betroffen sind -CURRENT-Nutzer nach dem 2. April.

etcupdate doppelt so langsam: Bob Prohaska berichtet, dass etcupdate auf armv7 (Raspberry Pi 2) mittlerweile doppelt so lange dauert wie früher. Die Diskussion mit Dimitry Andric und Mark Millard legt nahe, dass die Ursache in der pkgbase-Umstellung und der veränderten Dateistruktur liegt — etcupdate muss mehr Dateien prozessieren.

Was das heißt: -CURRENT-Nutzer sollten den knote-Bug im Blick behalten. Auf armv7-Systemen lohnt es sich, etcupdate-Alternativen wie mergemaster zu evaluieren, bis das Problem behoben ist.

Ports: Chromium 146 und Security-Updates

Die Ports-Collection hat in dieser Woche mehrere Updates erhalten:

  • Chromium 146.0.7680.177 (1. April, René Nagy) — aktuelles Major-Release
  • Zuvor: Chromium 146.0.7680.164 mit VuXML-Eintrag für Sicherheitslücken in Versionen < 146.0.7680.164
  • Chromium 30. März: Revert eines Upstream-Commits, der das Datei-Dialog-Verhalten auf FreeBSD kaputtgemacht hatte

Die kontinuierlichen Chromium-Updates zeigen, dass die FreeBSD-Ports-Maintainer aktiv sind — aber auch, dass Upstream-Commits regelmäßig FreeBSD-spezifische Regressionen verursachen.

Neuer Committer: Kenneth Raplee

Am 4. April wurde Kenneth Raplee (kenrap@FreeBSD.org) als neuer Ports-Committer angekündigt. Willkommen im Projekt!

Ausblick auf die kommende Woche

  • 17. April: Code Slush für 15.1 beginnt — letzte Chance für Feature-Commits
  • Der knote-Bug in -CURRENT braucht einen Fix
  • Die IPv6-only-RA-Diskussion könnte zu einem Commit führen
  • Das Laptop-Testing-Projekt hofft auf erste Community-Ergebnisse

Syncoid: ZFS-Replikation ohne Umwege

Thorsten Geppert Schreib einen Kommentar

Wer ZFS nutzt, kennt das Gefühl: Man hat Snapshots, man hat zfs send und zfs recv, und theoretisch ist alles möglich. Praktisch steht man dann vor einer Pipe aus drei Befehlen, fragt sich, ob --verbose vor oder hinter -R gehört, und stellt fest, dass der inkrementelle Sendevorgang um Mitternacht abgebrochen hat, weil irgendein Snapshot auf der Zielseite fehlte.

Genau hier setzt Syncoid an.

Was ist Syncoid?

Syncoid ist Teil des Sanoid-Projekts von Jim Salter und beschreibt sich selbst schlicht als Replikationstool für ZFS. Das klingt bescheidener, als es ist. Tatsächlich löst Syncoid genau die Probleme, die jeden treffen, der ernsthaft ZFS-Daten zwischen Maschinen bewegen will:

  • Es findet selbst heraus, welcher Snapshot der letzte gemeinsame ist.
  • Es erzeugt bei Bedarf einen neuen Snapshot auf der Quelle.
  • Es überträgt inkrementell — nur die Differenz.
  • Es funktioniert lokal und remote, als Push und als Pull.
  • Es macht das alles mit einem einzigen Befehl.

Wer schon einmal versucht hat, eine ZFS-Replikation mit reinen Shell-Mitteln fehlerresistent aufzuziehen, weiß, dass das keine Kleinigkeit ist. Syncoid nimmt genau diesen Aufwand weg, ohne dabei die Kontrolle zu verlieren.

Die Grundlage: ZFS send und recv

Um zu verstehen, was Syncoid leistet, hilft ein Blick auf das, was es vereinfacht. ZFS bringt mit zfs send und zfs recv bereits ein mächtiges Werkzeug für die Replikation mit. Das Prinzip ist einfach: Ein Snapshot wird serialisiert und auf der anderen Seite wieder eingespielt. Inkrementell geht das auch — man sendet nur die Differenz zwischen zwei Snapshots.

In der Praxis sieht das dann so aus:

zfs send -R data/images/vm@syncoid_2026-04-07:12:00:00 | ssh remotehost "zfs recv backup/images/vm"

Das funktioniert. Bis es nicht mehr funktioniert. Weil ein Snapshot auf der Zielseite gelöscht wurde. Weil die SSH-Verbindung abbricht. Weil man vergessen hat, -I statt -i zu verwenden. Weil die Quellseite keine Snapshots hat, die die Zielseite erwartet.

Syncoid kümmert sich um all diese Fälle. Und das ist der eigentliche Mehrwert: nicht dass es zfs send aufruft — das kann jeder —, sondern dass es die Fehlerfälle abfängt, die im Alltag regelmäßig auftreten.

Loslegen: Einfacher geht es nicht

Die grundlegende Syntax ist so simpel, dass man sie sich kaum merken muss, weil sie offensichtlich ist:

syncoid data/images/vm backup/images/vm

Das repliziert den Dataset data/images/vm nach backup/images/vm — lokal, auf derselben Maschine. Beim ersten Lauf wird alles übertragen, bei jedem weiteren nur die Differenz.

Remote geht es genauso, nur mit dem üblichen SSH-Präfix:

syncoid data/images/vm root@remotehost:backup/images/vm

Das ist Push-Replikation: Die lokale Maschine sendet zum Remote. Pull geht auch:

syncoid root@remotehost:data/images/vm backup/images/vm

Hier zieht die lokale Maschine die Daten vom Remote. Der Unterschied mag marginal wirken, ist aber in der Praxis relevant: Pull bedeutet, dass die Backup-Maschine die Kontrolle hat und keinen SSH-Zugang zur Produktionsmaschine benötigt.

Rekursiv geht es mit -r:

syncoid -r rpool remotehost:tank/backup/rpool

Damit werden alle Child-Datasets unter rpool mit übertragen. Für ein vollständiges Backup ist das genau das, was man braucht.

Ohne Root: ZFS-Rechte delegieren

Einer der häufigsten Fehler bei ZFS-Backups ist, sie als root laufen zu lassen. Es funktioniert, aber es bedeutet, dass man root-SSH-Zugang zwischen Maschinen erlaubt. Das ist ein Sicherheitsrisiko, das sich vermeiden lässt.

Syncoid unterstützt den Betrieb ohne Root über --no-privilege-elevation. Dafür müssen auf beiden Seiten die entsprechenden ZFS-Berechtigungen delegiert werden:

Auf der Quellmaschine:

zfs allow -u syncuser send,hold,mount,snapshot,destroy rpool

Auf der Zielmaschine:

zfs allow -u syncuser compression,mountpoint,create,mount,receive,rollback,destroy tank/backup/rpool

Und dann:

syncoid --no-privilege-elevation -r rpool syncuser@remotehost:tank/backup/rpool

Das ist mehr Aufwand bei der Einrichtung, aber es ist der richtige Weg. Kein root-SSH, keine unnötigen Privilegien. Wenn man mit --use-hold arbeitet, kommt noch die release-Berechtigung dazu. Wer --create-bookmark nutzt, braucht bookmark auf der Quellseite.

Die Optionen, die man tatsächlich braucht

Syncoid hat eine überschaubare, aber nützliche Anzahl an Optionen. Die wichtigsten:

--compress: Kompression während der Übertragung. Unterstützt werden gzip, pigz-fast, pigz-slow, zstd-fast, zstd-slow, lz4, xz, lzo (Standard) und none. Wer über ein LAN synchronisiert, kann none wählen; über WAN ist zstd-fast eine gute Wahl.

--no-sync-snap: Standardmäßig erzeugt Syncoid bei jedem Lauf einen eigenen Snapshot. Wer das nicht möchte — etwa weil Sanoid die Snapshot-Verwaltung übernimmt oder weil man in ein Multi-Target-Setup repliziert —, der schaltet das mit --no-sync-snap ab. Verhindert die Anhäufung von Syncoid-Snapshots auf der Zielseite.

--create-bookmark: Setzt auf der Quelle ein Lesezeichen für den letzten erfolgreich replizierten Snapshot. Das ist besonders nützlich bei unregelmäßiger Replikation: Wenn der letzte gemeinsame Snapshot auf der Quelle bereits gelöscht wurde, kann das Bookmark den Zugriff auf den benötigten Punkt trotzdem ermöglichen. Funktioniert nur zusammen mit --no-sync-snap.

--use-hold: Setzt einen Hold auf den neuesten Snapshot auf Quell- und Zielseite und entfernt ihn erst nach dem nächsten erfolgreichen Lauf. Das verhindert, dass ein Snapshot gelöscht wird, bevor er repliziert wurde. Bei Multi-Target-Setups (A→B, A→C) kann man mit --identifier unterschiedliche Holds pro Ziel setzen.

--no-stream: Statt -I (alle Zwischensnapshots) wird -i (nur der neueste Snapshot) verwendet. Spart Bandbreite, wenn man die Zwischenschritte nicht braucht.

--exclude-datasets=REGEX: Schließt bestimmte Datasets von der Replikation aus. Kann mehrfach angegeben werden.

--source-bwlimit und --target-bwlimit: Bandbreitenlimitierung, falls mbuffer nicht verfügbar ist. Nützlich, wenn man die Übertragung nicht die ganze Leitung blockieren lassen möchte.

Snapshots und Pruning

Ein wichtiger Punkt: Syncoid ist agnostisch gegenüber der Snapshot-Verwaltung. Es löscht keine Snapshots auf der Zielseite, nur weil sie auf der Quelle gelöscht wurden. Das ist kein Fehler, sondern ein Feature — es schützt vor Datenverlust.

Für das Aufräumen alter Snapshots auf der Zielseite empfiehlt sich Sanoid mit einer Konfiguration wie dieser:

[backup/images/vm]
autoprune = yes
autosnap = no
frequently = 0
hourly = 36
daily = 30
monthly = 6
yearly = 0

autosnap = no, weil die Snapshots von Syncoid kommen und nicht von Sanoid erzeugt werden sollen. autoprune = yes, um alte Snapshots nach den definierten Regeln aufzuräumen. Das lässt sich mit Templates auch für viele Datasets gleichzeitig konfigurieren.

Oder, kürzer, mit einem Template:

[template_backup]
autoprune = yes
autosnap = no
hourly = 36
daily = 30
monthly = 6

[backup/images]
use_template = backup
recursive = yes

Die Kombination aus Syncoid für die Replikation und Sanoid für das Pruning ist das, was die meisten produktiven Setups verwenden. Und sie funktioniert genau deshalb gut, weil beide Werkzeuge ihre Zuständigkeit klar abgrenzen.

Praktisches Setup: Ein vollständiges Beispiel

Angenommen, man hat einen Server prod mit dem Pool zdata und einen Backup-Server backup mit dem Pool tank. Ziel: Tägliches inkrementelles Backup aller Datasets.

1. Sanoid auf prod einrichten (für die Snapshot-Erstellung):

/etc/sanoid/sanoid.conf

[zdata]
use_template = production

[template_production]
frequently = 0
hourly = 36
daily = 30
monthly = 3
yearly = 0
autosnap = yes
autoprune = yes

2. Cron-Job auf backup (Pull-Replikation):

0 2 * * * syncoid --no-sync-snap --compress=zstd-fast -r syncuser@prod:zdata tank/backup/zdata

3. Sanoid auf backup (für das Pruning):

[tank/backup/zdata]
use_template = backup

[template_backup]
autoprune = yes
autosnap = no
hourly = 36
daily = 30
monthly = 6
yearly = 0

Das ist im Grunde das komplette Setup. Drei Konfigurationsschritte, ein Cron-Job, und man hat eine robuste, inkrementelle ZFS-Replikation, die im Hintergrund läuft, ohne dass man sich darum kümmern muss.

Was man beachten sollte

Ein paar Dinge, die in der Dokumentation eher am Rande stehen, aber im Alltag relevant werden:

SSH-Konfiguration: Syncoid baut für jeden Lauf eine neue SSH-Verbindung auf. Bei häufiger Replikation lohnt sich ein Connection Multiplexing in der ~/.ssh/config:

Host backupserver
  HostName 192.168.1.50
  User syncuser
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 600

Das spart den Verbindungsaufbau bei jedem Lauf.

mbuffer: Wenn auf beiden Seiten mbuffer verfügbar ist, nutzt Syncoid es automatisch. Das kann die Übertragungsrate deutlich verbessern, weil es die Pipeline puffert und verhindert, dass zfs send auf zfs recv warten muss.

Erstlauf dauert: Der erste Syncoid-Lauf überträgt den kompletten Dataset. Bei mehreren Terabyte bedeutet das: Zeit einplanen. Alle folgenden Läufe sind inkrementell und entsprechend schneller.

Kein Konfigurationsfile: Im Gegensatz zu Sanoid hat Syncoid keine Konfigurationsdatei. Alles wird über Kommandozeilen-Flags gesteuert. Das ist konsistent, bedeutet aber auch, dass man bei komplexeren Setups die Aufrufe entsprechend dokumentieren sollte.

Warum Syncoid und nicht rsync?

Die Frage ist naheliegend. rsync ist etabliert, gut dokumentiert und funktioniert auf jedem System. Aber rsync kennt ZFS nicht. Es kann nicht inkrementell auf Snapshot-Ebene arbeiten, es kann keine Block-Differenzierung nutzen, und es kann nicht garantieren, dass der Zielzustand konsistent ist.

ZFS-Snapshots sind atomar. Ein Snapshot repräsentiert den exakten Zustand eines Datasets zu einem bestimmten Zeitpunkt. Wenn man den repliziert, erhält man auf der Zielseite exakt diesen Zustand — nicht einen Zustand, bei dem einige Dateien schon aus dem Snapshot stammen und andere gerade im Flux sind.

Das ist kein akademischer Unterschied. Wer schon einmal ein Datenbank-Backup mit rsync gemacht hat und feststellen musste, dass die Dateien während der Übertragung verändert wurden, weiß, wovon die Rede ist.

Fazit

Syncoid ist eines dieser Werkzeuge, die man sich früher wünscht. Es nimmt einen wiederkehrenden, fehleranfälligen Prozess — ZFS-Replikation per Hand — und macht ihn zu einem einzelnen Befehl, der funktioniert. Nicht weil er Magie einsetzt, sondern weil er die Randfälle abdeckt, die man selbst immer vergisst: fehlende Snapshots, abgebrochene Verbindungen, falsche Flags.

Wer ZFS einsetzt und nicht bereits ein etabliertes Replikations-Setup hat, sollte Syncoid ausprobieren. Die Einstiegshürde ist minimal, der Nutzen ist sofort spürbar, und falls man doch mehr Kontrolle braucht: Die Optionen sind da, man muss sie nur nutzen.

Und wer Sanoid für die Snapshot-Verwaltung ohnehin schon im Einsatz hat — der hat Syncoid bereits installiert. Es ist Teil desselben Pakets. Man muss es nur nutzen.

Quellen