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.

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.