Warum robuste Infrastruktur wichtiger ist als moderne Tools

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.