Kategorie: Arbyte

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.

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.

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.

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.

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)

Softwareentwicklung Teil 2: Weitere Erfahrungen

Thorsten Geppert Schreib einen Kommentar

Mir fallen noch einige weitere Dinge ein, die ich hier zu teilen versuche. Meist geht es um technische Schulden und, für mich, komische Ansätze in der Verwaltung von Firmen.

Ich war vierzehn Jahre lang in einem Unternehmen beschäftigt und das hat, zumindest in Bezug auf die IT, auf die IT-Abteilung gehört. Haben wir immer die richtigen Entscheidungen getroffen? Nein. Aber zumeist und aus den fehlgeschlagenen Entscheidungen haben wir immer gelernt. Ich möchte das hier einmal als Positivbeispiel anbringen. Ich schätze, es muss 2012 gewesen sein, als wir neue Server anschafften. Zwei baugleiche Geräte für Redundanz. Wir kamen auf die Idee, dort Festplatten mit 4TB Speicherkapazität einzubauen und entschieden uns für Western Digital SAS. Leider wusste keiner von uns, und da hätten wir uns vorher definitiv noch einmal genauer informieren müssen, dass es SAS-Festplatten und Nearline-SAS-Festplatten gab. Wir waren zwar verwundert über die Preise, denn eine solche Platte mit 4TB in etwa so viel wie welche mit 960GB, aber wir forschten nicht weiter nach, sondern freuten uns.

Wir klatschten die Server also mit einer Menge dieser Platten voll, richteten darauf zraid-2 ein (RAID 6) und banden die Geräte ins Netzwerk ein. Wie zuvor auch, exportieren wir die Home-Laufwerke gut 50 Clients per NFS. In Tests funktionierte alles tadellos und wir schlossen glücklich und schnell die Umstellung ab. Dann kamen die Leute und wollten arbeiten. Es kam zu großen Wartezeiten und ein gewisser Unmut machte sich breit, denn das System performte nicht. In einzelnen Tests lief es hervorragend, sequentielles Schreiben und Lesen funktionierte tadellos. Aber in der Masse und bei der Menge an Dateien war es grottenlangsam und unbenutzbar. Wir suchten zu zweit sicher einen Monat nach dem Problem, bis ich auf die Idee kam, dass die Platten in Form der Hardware schuldig waren. Wir stellten dann ein solches Szenario nach und stellten dem gegenüber ein System mit echten (super teuren) SAS-Festplatten und siehe da: Genau da war das Problem. Die Lösung war schnell da: Neue Festplatten mussten her. Wir besprachen das mit der Geschäftsleitung, räumten ein, dass es letztlich unsere Schuld war, wir das aber vorher nicht wussten und es kein böser Wille war. Das Ende vom Lied war, dass wir neue Festplatten, die teuer waren und eine niedrige Kapazität hatten, kauften und einbauten. Das kostete die Firma natürlich eine Unmenge an Geld (ich habe noch gut 12.000 Euro im Kopf). Uns wurde aber nicht der Kopf abgerissen. Erstens wäre der weitere Betrieb in alter Form ohnehin teurer geworden, da niemand arbeiten konnte, und zweitens wusste man, dass Fehler passieren. Wir haben das zusammengefasst, noch einmal berichtet, was wir gelernt hatten, und solche Probleme traten dann nie wieder auf.

In einer anderen Firma sprach ich einmal an, dass wir einen gewissen Style-Guide einführen sollten, und dieser bezog sich nur auf die Benennung von Variablen, Konstanten und Funktionen. Die Benennung solcher Dinge kann man weiter unten in meinem vorherigen Artikel nachlesen, da habe ich ein Beispiel. Ich sprach mich für „sprechende“ Namen aus. Dies wurde abgelehnt, denn dann hätte man ewig lange Namen, mehr aussagen würden diese auch nicht, und man würde sich tottippen (VI(M) war der Editor der Wahl und mit [CTRL]+[p] bzw. [CTRL]+[n] ergänzt er begonnene Namen vollautomatisch). Aufgrund der Ablehnung und auch aufgrund anderer, vorheriger und späterer Aussagen, war mir klar, dass da keine zielbringende Diskussion möglich war. Also ließ ich es.

In der selben Firma kam man auf die Idee, die (teuer zu bezahlenden) Mitarbeiter ein bis mehrmals pro Woche (später dann die Entwickler, die an einem gewissen Projekt arbeiteten, alle zwei Wochen) halbtägig in den technischen Service zu stecken. Der Tenor, so ich mich noch richtig erinnere, war, dass diese dann mehr vom Drumherum mitbekommen und Prozesse besser verstehen. Man war dann in der Tickethölle und musste bestimmte, ausgewählte, redundante Aufgaben abarbeiten. Das Problem: Für viele Serviceaufgaben gab es entweder keine Tools oder diese waren so dermaßen komplex, fehleranfällig und schwergängig, dass sie ein „normaler“ Servicemitarbeiter nicht hätte benutzen können. Bereits einfache Aufgaben konnten ganze Prozesse zerschießen. Anstatt die Softwareentwickler laut ihrer Kompetenzen dazu zu bringen, Tools zu entwickeln, die der Service nutzen hätte können, nutzten wir die halbgaren Tools in der Hoffnung, nichts Schlimmeres zu machen. Doch trotz großer Vorsicht passierte dies ab und an, auch mir zwei Mal. Einmal, ich weiß es noch, haben ein Kollege und ich mehr als einen halben Tag daran gesessen, das Problem zu fixen. Dabei wäre es wirklich sinnvoller gewesen, diese Tools robust zu machen.

Mir fällt noch ein Beispiel in dieser Firma ein. Wir hatten einen Workshop und mussten danach irgendwelche Funktionen noch fertig machen. Beim Testen wurde bei einem der komplexen Parameter aus Versehen die falsche Datenbank angegeben. Keinem von uns, wir waren drei oder vier Leute, fiel dies auf. Leider wurden dann wichtige Datensätze von Kunden in der Produktivumgebung überschrieben bzw. gelöscht. Die Produktivumgebung für mehrere tausend Kunden war nicht vollständig von der Entwicklungsumgebung abgeschirmt. Mein Chef hat es zwar hinbekommen und war auch nicht böse, aber es hätte auch anders ausgehen können. Beim Vorschlag, dass sowas irgendwie anders gelöst wird, kam nur ein lapidares „Nutzen Sie doch einfach die richtige Datenbank.“. Schlussendlich wurde doch zumindest ein Parameter im Programm umbenannt.

Es gibt an dieser Stelle zwei wichtige Dinge:

  1. Die Fehlerkultur in einem Unternehmen bestimmt auch die Qualität der Software, die Weiterentwicklung dieser, die der Entwickler und zu guter Letzt die des Unternehmens.
  2. Das Unternehmen sollte unbedingt die Vita der Leute, die es beschäftigt, ansehen. Wer kann wo am besten eingesetzt werden? Wert hat wo die besten Erfahrungen? Usw. usf. Das wurde in einigen Unternehmen, in denen ich war, nicht getan.

Die schrecklichste Zeit, die ich je hatte, waren meine zwei Monate bei einem Softwareunternehmen in Koblenz. Das Unternehmen hatte unglaublich viele Probleme. Neben der bescheidenen Bezahlung für die Programmierer war allen voran die Qualität des Codes völlig unzulänglich. Niemand sah sich meine Vita an, doch einer meiner Programmierkollegen meinte irgendwann: „Er soll sich doch mal die Memory-Leaks in unserer Software ansehen, er kennt sich da aus.“

Ich wühlte mich also durch etliche Zeilen kaum lesebaren Codes, da es auch hier keinen einheitlichen Style gab. Viel schlimmer war aber, dass ich nur Zugriff auf einen auf ein Core-System aufsetzenden Code hatte, aber nicht auf das Core-System selbst. Im Core-System gab es aber etliche Probleme. Zugriff bekam ich trotzdem nicht, so dass ich meiner Aufgabe überhaupt nicht sinnvoll nachgehen konnte. Dass nur ich das alles kaum verstand, sah man am Versionsverwaltungssystem (Subversion): Von den meisten Kollegen gab es maximal einen Commit pro Woche und der Commit hatte meistens nur ein bis drei Codezeilen inne. Niemand stieg durch das System.

Auch die Aufteilung innerhalb dieser Firma war äußerst komisch. Es kam SAFE zum Einsatz, das aber nur nebenher. Aufgeteilt wurde die Entwicklung zwischen zwei Menschen: dem Requirements-Engineer (kurz RE) auf der einen, dem Programmierer auf der anderen Seite. Gehen wir von einer Rolle als Senior-Softwareentwickler (was auch immer das sein soll) aus. Der RE bekam den Auftrag für ein neues Modul oder einen Teil eines Moduls. Dieser beschrieb dann, was gemacht werden sollte (aus meiner Sicht noch ok) und dann unterteilte er es in etliche Untertasks. D.h. der RE musste dem Softwareentwickler seine eigenen Kompetenzen wegnehmen und für ihn planen, wie der Softwareentwickler dies umzusetzen hatte. Und der Softwareentwickler musste auf diese Tickets seine Zeiten buchen (das war übrigens die Hauptaufgabe: Verwalten seiner Zeiten, jede Sekunde musste protokolliert werden) und sich dafür rechtfertigen, wenn er länger brauchte oder Dinge nicht funktionierten. Das habe ich in den zwei Monaten, in denen ich da war, öfter erlebt. Man musste sich vor seinem Vorgesetzten und mitunter vor dessen Vorgesetzten verantworten. Es war die pure Hölle, was ich mittlerweile aber auch verstehen kann, weiß ich doch mittlerweile, in welcher Szene sich der Gründer des Unternehmens widerwärtig aufhält.

Kommen wir noch einmal auf die erste Firma zurück. Dort war eines der Probleme, wie ich in einem anderen Artikel bereits schrieb, dass unglaublich viel Code generiert wurde. Dabei ging es um eine Art OR-Mapper für DBMS und XML. Objektorientierte Entwicklung und generische Programmierung wurden hier immer wieder abgelehnt, obwohl diese unglaublich viele Probleme gelöst hätten. Man entschied sich für die Erneuerung des Codes für eine Multiparadigmensprache. Diese kann zwar Objektorientierung, aber nicht wirklich Vererbung. Warum die Wahl auf diese Programmiersprache fiel, war mir nie klar. Letztlich wurde das damit bekräftigt, dass die neue Generation von Programmierern kein C mehr kann. Auf C basierte die meiste alte Software (wenig auf C++, Ruby, Python, Shell-Scripts, usw.). Die Wahl hielt ich für suboptimal. Ein sinnvoller Weg wäre vielleicht gewesen, auf C++ umzusteigen. Da ein Projekt bereits in C++ umgesetzt war, waren auch schon bestimmte Kompetenzen vorhanden. Auch hätte man einen Teil des alten Codes leichter weiterverwenden können, als es mit der ausgewählten Programmiersprache möglich war (wenn diese auch C unterstützte). Die Ablösung wäre vielleicht einfacher gewesen, aber natürlich auch, dass Programmcode 1:1 übernommen worden wäre, was vielleicht nicht das eigentliche Ziel war. Es wurde allerdings Code übernommen und nahezu 1:1 in die neue Programmiersprache gesetzt. Variablen hießen gleich, Funktionen hießen gleich, der Programmablauf war der gleiche.

Zum Einsatz kamen zwei DBMS. Ein teures von einem teuren Hersteller und, für das neue Projekt, ein super gutes, welches ich auch oft empfehle. Beide DBMS wurden aber nicht wirklich als DBMS genutzt, sondern nur als Puffer für irgendwelche Daten. Auch auf vernünftige referentielle Integrität wurde, so wie ich die Datenstrukturen wahrnahm, verzichtet. Je nachdem, ob man in der Entwicklung war und Daten löschen wollte, musste man die händisch aus etlichen Tabellen entfernen. Von Normalisierung und Stored Procedures usw. müssen wir gar nicht sprechen.

Softwareentwicklung: Verwaltung zuerst – aber wie steht es um Softwarequalität?

Thorsten Geppert Schreib einen Kommentar

In den letzten Jahren habe ich in verschiedenen Unternehmen gearbeitet, die zwar unterschiedlich waren, aber mit ähnlichen Problemen konfrontiert waren. Mit diesem Text möchte ich meine Perspektive auf diese Herausforderungen teilen.

Als Softwareentwickler und Administrator habe ich an zahlreichen Projekten im Softwarebereich, in der Administration sowie im Aufbau von Netzwerken und Client-Server-Strukturen gearbeitet. Einige dieser Projekte habe ich selbst geleitet, andere in Zusammenarbeit mit verschiedenen Personen betreut.

In meinen letzten Positionen war ich jedoch hauptsächlich auf die Programmierung beschränkt. Ich hatte keine Entscheidungsbefugnis und konnte mein Wissen und meine Expertise nicht sinnvoll einbringen. Stattdessen führte ich eine monotone und ermüdende Fließbandarbeit aus. Diese Erfahrung ermöglichte es mir jedoch, die Probleme aktueller Softwareunternehmen zu beobachten, die in einem ewigen Kreislauf der Selbstoptimierung gefangen sind, aber im IT-technischen Kernbereich keine bedeutenden Fortschritte erzielen.

Zwei Hauptthemenbereiche traten in diesen Unternehmen hervor (nicht in jedem, aber mindestens in einem):

  1. Die Notwendigkeit, agil zu werden und zu bleiben.
  2. Die Implementierung von CI/CD um jeden Preis.

Für die meisten klingen diese beiden Punkte sinnvoll, und in gewisser Weise sind sie es auch, insbesondere der zweite Punkt. Die Umsetzung dieser Ansätze erfolgte jedoch nicht als strukturierter Prozess, sondern eher als eine übergeordnete Aufgabe, die den Fokus von den wirklich wichtigen Aufgaben ablenkte.

Beginnen wir mit dem Thema Agilität. Was neue Softwarefirmen (Startups) von Anfang an praktizieren, wird in etablierten Unternehmen oft nur mühsam eingeführt. Ich erinnere mich noch gut daran, wie wir uns in einem Unternehmen, das von technischen Schulden geplagt war, ausschließlich auf die Einhaltung agiler Prinzipien konzentrierten, anstatt die eigentlichen Probleme anzugehen. Das bedeutete, dass wir mit Hochdruck Tools einführten und Schulungen durchführten, die die Mitarbeiter hauptsächlich beschäftigten. Da es Architekten, Product Owner und Scrum Master und so weiter gab, wollte kaum noch jemand Techniker sein, sondern einen solchen Titel tragen und Tickets und Epics durch die Gegend schieben. Das Softwareprodukt selbst blieb dabei auf der Strecke.

Wir hatten mehrere Schulungen mit einem Unternehmen, das sich meiner Meinung nach auf die Vermittlung esoterischer Agilität spezialisiert hatte. Alle zwei Wochen fand die Retrospektive statt, in der jeder seine Gefühle offenbaren musste und wir uns an wilden (Kinder-)Spielen wie „Wer ist schneller mit dem Mauszeiger?“ beteiligten. Wichtige Themen wie Bugs, Features, Refactoring, Neuausrichtung, Ideen und die Erweiterung unseres technischen Wissens wurden dabei völlig vernachlässigt. Stattdessen mussten wir uns gegenseitig loben und betonen, wie großartig unser Team sei. Das Produkt blieb oft ein einziges Chaos, und mir war die ganze Nummer mehr als peinlich.

Fahren wir mit CI/CD fort. Obwohl ich es für wichtig halte, ist es nicht so entscheidend wie das Produkt selbst. In einer Firma musste ich ein Frontend entwickeln, das zwei Kommandozeilenprozesse startete und überwachte. Es war eine relativ einfache Software, die schnell geschrieben werden konnte. Tatsächlich musste ich sie zweimal schreiben. Zuerst verwendete ich Qt und C++, was zu einem funktionsfähigen, modernen und effizienten Produkt führte. Es wurde jedoch entschieden, dass es einfacher sein und lieber mit wxWidgets geschrieben werden sollte, da die Firma bereits Erfahrung mit dieser Technologie hatte. Daher begann ich mit dem Schreiben einer neuen Version. Obwohl der Funktionsumfang geringer war, dauerte die Entwicklung aufgrund der geringeren Abstraktion von wxWidgets länger. Schließlich war das Produkt fertig, funktionsfähig und bereit für die Auslieferung. Es handelte sich um eine relativ kleine Codebasis von etwa 4.000 Zeilen C++. Nachdem ich das Produkt fertiggestellt hatte, hatte ich aufgrund von schlechtem Management (man war ja mit Agilität beschäftigt) nichts mehr zu tun. Man schlug vor, dass ich mich mit dem Testing befassen sollte, da das Produkt in CI/CD integriert werden musste. Dies umfasste drei Hauptaspekte:

  1. Unit- und Integrations-Tests mit Google-Test
  2. Statische Codeanalyse mit SonarQube
  3. Automatische GUI-Tests

Ich habe mich dann über ein halbes Jahr ausschließlich mit diesem Projekt beschäftigt. Während die Unit- und Integrations-Tests noch relativ einfach zu handhaben waren, erwies es sich als deutlich schwieriger, Anwendungsfälle für eine Software mit über 4.000 Zeilen Quellcode zu entwickeln, von denen der Großteil GUI-bezogen war. Das agile Testmanagement verlangte eine Code-Coverage von mindestens 70 %. Anstatt mich also auf die eigentliche Kernsoftware zu konzentrieren, die dieses von mir entwickelte Frontend lediglich startete und überwachte, widmete ich mich der ABM und der Erstellung von Tests, die letztendlich keinen wirklichen Zweck erfüllten. Der Grund dafür ist einfach: Die Software war funktionsfähig, sollte nicht weiterentwickelt werden und war nicht anfällig für Fehler. Sie war ausgebaut und lediglich im Bestand. Darüber hinaus sollte sie in naher Zukunft durch eine andere Software ersetzt werden.

Trotz dieser Umstände durfte ich mich weiterhin mit der Umsetzung der teils eigenwilligen Standard-Regeln von SonarQube befassen. In den gesamten 4.000 Zeilen Code entdeckte SonarQube lediglich einen einzigen Bug (einen gelöschten Pointer, der in einem anderen Codesegment erneut aufgerufen wurde). Die restlichen Hinweise bezogen sich auf unbedeutende Aspekte wie die Anzahl der Member-Variablen und die Begrenzung der Methodenanzahl pro Klasse auf 30.

Da die Software auch zwei klickbare Buttons enthielt, musste ich vollautomatische GUI-Tests implementieren. Dies stellte sich bei einer wxWidgets-Anwendung mit C++ als Herausforderung dar, konnte aber erfolgreich gemeistert werden. Dadurch wurde das gesamte GUI vollautomatisch testbar.

Obwohl dies die Software, die im Mittelpunkt stand, nicht direkt voranbrachte, fügte es doch ein weiteres Puzzleteil zur Pipeline hinzu. Ich konnte wertvolle Erkenntnisse gewinnen, die ich bei zukünftigen Softwareprojekten, wo es sinnvoll ist, anwenden kann.

In einer anderen Firma war ich an zwei oder drei Softwareteilen beteiligt. Auch hier wurde, im Zuge des Wachstums des Produkts, zunehmend Wert auf die Pipeline gelegt. Folglich mussten zahlreiche Tests nachimplementiert werden. Dies war nur bedingt sinnvoll, da drei wesentliche Probleme vorlagen:

  1. Die Qualität des Codes und insbesondere der gesamten Architektur war mangelhaft, wenn nicht gar nicht vorhanden.
  2. Es gab Fachverfahren, die eine umfassende Einarbeitung erforderten oder eine gezielte Einweisung notwendig gemacht hätten.
  3. Die Software sollte vollständig durch eine neue Version in einer anderen Programmiersprache ersetzt werden. Diese neue Architektur war jedoch ebenfalls fehlerhaft und entsprach nicht den Qualitätsstandards, die ich vertrete.

Einige der Tests hätten durchaus auch für die zweite Generation der Software verwendet werden können, was sinnvoll war, um das Verhalten der alten und neuen Software zu vergleichen. Doch meiner Meinung nach war das Projekt dazu verdammt, gegen die Wand zu fahren.

Unit-Tests, Integrationstests, Code-Reviews, CI/CD, statische Codeanalyse, GUI-Tests, Dokumentation, nachverfolgbare Ticketbearbeitung, Kompetenztransfer und vieles mehr sind entscheidend für eine nachhaltige Softwareentwicklung. Diese Elemente sollten jedoch von Anfang an integriert sein. Sie später, insbesondere bei großen Projekten, einzuführen, ist ineffektiv, vor allem bei komplexen Projekten mit Hunderttausenden von Codezeilen. Darüber hinaus können andere technische Schulden so hoch sein, dass sie dringendere Aufmerksamkeit erfordern.

Ich habe es immer wieder erlebt, dass Unternehmen weiterhin auf veraltete Frameworks setzen. Ich bin auf Systeme gestoßen, die 20 Jahre alt oder noch älter waren und längst nicht mehr unterstützt wurden. Oder auf Plattformen, die über 20 Jahre alt waren und auf denen immer noch die Software für aktuelle Systeme kompiliert wird, weil die Migration auf aktuelle Plattformen vernachlässigt wurde.

Doch das ist nicht alles. Die Qualität von Software-Code ist ein entscheidender Faktor in der Softwareentwicklung. Ich habe Ein-Personen-Projekte erlebt, die aufgrund ihrer zunehmenden Komplexität oder der Sorge um die langfristige Verfügbarkeit des ursprünglichen Entwicklers zusätzliche Teammitglieder erforderten. Diese neuen Teammitglieder haben jedoch oft Schwierigkeiten, den Code, die Fachverfahren und das gesamte System zu verstehen.

Aber warum ist das so? Ein Ein-Personen-Projekt hat von Natur aus seine Grenzen. Der ursprüngliche Entwickler versteht den Code vielleicht noch, aber das gilt nicht unbedingt für andere. In den letzten Jahren bin ich immer wieder auf schlecht geschriebenen Code gestoßen. Schon die Verwendung von Funktionen, Methoden oder Variablennamen wie „reg_rq_fachver2_23“ ist wenig hilfreich. Darüber hinaus habe ich unglaublich redundanten Code gesehen, wie zum Beispiel:

int za_wwggw_w2(int p, int p_k, int p_key, int k, int key, char *pk) {
int _key;
struct pkey *pkey_p;
return za_wwggw_w3(p, p_k, p_key, k, key, pk, &_key, pkey_p);
}

Selbst nach mehrmaligem Lesen verstehe ich diesen Code nicht. Wenn ich mich durch etwa 50 Dateien mit mehreren zehntausend Zeilen Code kämpfen müsste, der genauso oder noch schlimmer aussieht, würde ich irgendwann aufgeben.

Es gab Software, bei der GUI-Komponenten mit Namen wie Edit1, Edit2, Edit3 bis Edit123 versehen waren. Diese Praxis führte zu immensen technischen Schulden, die ich nicht erklären kann. Schließlich ist allgemein bekannt, dass sauberer und lesbarer Quellcode die Notwendigkeit von Dokumentation minimiert (die oft ohnehin nicht vorhanden ist), das Bugfixing und die Wartbarkeit erhöht sowie die Einarbeitung anderer Menschen vereinfacht.

Betrachten wir das Projekt mit der Methode za_wwggw_w2. Es war offensichtlich, dass das Projekt unkontrolliert gewachsen war und eine Reimplementierung erforderlich war. Meiner Meinung nach war dies der einzige praktikable Ansatz, um das Projekt weiter auszubauen. Allerdings sah ich sofort mehrere Probleme:

  1. Die Reimplementierung wurde nicht als eine vollständige Neubegründung des Projekts verstanden, was angesichts seiner Komplexität eine gewaltige Aufgabe gewesen wäre. Stattdessen wurde sie als eine Portierung des alten Codes auf eine neue Programmiersprache wahrgenommen, mit minimalen Anpassungen, um die Besonderheiten der neuen Sprache zu berücksichtigen. Als ich den Code der anderen Programmierer untersuchte, stellte ich fest, dass er fast identisch mit dem alten Code war, mit nur wenigen geringfügigen Änderungen. Die zugrundeliegenden Probleme blieben bestehen, und ohne jemanden direkt verantwortlich machen zu wollen, würde ich behaupten, dass die meisten, die an dieser Umsetzung beteiligt waren, sie nicht vollständig verstanden.
  2. Darüber hinaus wurde im Prozess keine Architektur implementiert. Da die neue Programmiersprache eine einfache Integration von Code aus dem alten System ermöglichte, wurde diese Funktion häufig genutzt.
  3. Es wurde eine Masse an „gleichem“ Code automatisch generiert, anstatt auf Abstraktion, Ableitung und Konventionen zu setzen. Viele tausende Zeilen gleicher Code mit leicht unterschiedlicher Logik wurde generiert.

Leider wurden die gleichen Fehler gemacht wie bei dem Ein-Personen-Projekt, obwohl das Team aus erfahrenen Programmierern bestand, die jahrelange und jahrzehntelange Erfahrung mitbrachten. (Ich kam relativ spät dazu und wurde hauptsächlich als „Programmieräffchen“ eingestellt.)

Diese Erfahrung habe ich in zahlreichen Projekten gemacht. In einem Projekt, das stark auf eine Datenbank angewiesen war, deaktivierte mein Vorgänger die referentielle Integrität mit der Begründung, es würde die Leistung verbessern. Dies führte jedoch dazu, dass die Datenbank in einen fehlerhaften Zustand geraten konnte (was auch mehr als nur einmal passierte). Solche Probleme hätten leicht behoben werden können, indem beispielsweise ein zuverlässiges Datenbankmanagementsystem (DBMS) verwendet oder qualitativ hochwertiger Code geschrieben worden wäre. Trotzdem wurden diese Maßnahmen nicht ergriffen.

Meine Botschaft ist klar: Anstatt sich ausschließlich auf das Umfeld zu konzentrieren, würde es vielen Produkten zugutekommen, wenn ein stärkerer Fokus auf die Produkte selbst gelegt würde. Auch vorher Gedanken zu machen und Erfahrungen von Menschen einzubringen, die das seit Jahren/Jahrzehnten bereits machen, ist absolut sinnvoll.

Als Angestellter in einer insolventen Firma

Thorsten Geppert Schreib einen Kommentar

Im Jahr 2021 erfuhr ich, dass die Firma, für die ich seit mehr als dreineinhalb Jahren tätig bin, Insolvenz anmelden muss. Ein kurzer Erfahrungsbericht.

2018 suchte ich mir eine neue Arbeit, die ich im März des selben Jahres auch direkt begann, und zwar, wie so gerne, als Softwareentwickler und Administrator. Nach kurzen Startschwierigkeiten und Neuorientierung lief es dann doch ganz gut und ich hatte (zumeist) Freude an meiner Arbeit.

Im Oktober, nach einem Arbeitstag, dann das kurze Gespräch zwischen meinem Chef und mir. Er müsse wohl Insolvenz anmelden (warum und wieso, ist hier nicht Thema). Ich war schon gut geschockt, im Nachhinein hätte ich aber auch selbst drauf kommen können. Wie das so immer ist: Später ist man immer schlauer.

Im November 2021 wurde es dann offiziell. Ich bekam die schlechte Nachricht per E-Mail, dass ein Insolvenzantrag eingereicht wurde und es einen Insolvenzverwalter gibt. Dann wurde aus der „grauen“ Nachricht im Oktober plötzlich harte Gewissheit.

Abgesehen vom Verlust des Arbeitsplatzes gab es ein weiteres Problem: Es gibt kein Geld. Ab Oktober. Nochmal: kein Geld. Nicht weniger Geld oder jemand anderes übernimmt das, nein, es gibt kein Geld. Die Banken und die Supermärkte, die Strom- und Gaslieferanten, die Kindergärten, und viele mehr, wollen aber weiterhin Geld haben. Also stehst du mit einer Frau, die glücklicherweise beschäftigt ist, und drei Kindern da und weißt nicht weiter. Hast du dann keine Ersparnisse, sieht es schlecht für dich aus.

Vom Insolvenzverwalter wird dir dann gesagt: Stell doch einen Antrag auf Insolvenzgeld. Das bedeutet, dass du für drei Monate dein volles Gehalt bekommst, und zwar von der Arbeitsagentur und das ohne Anrechnung auf das Arbeitslosengeld, du arbeitest ja schließlich. Wissen muss man aber, dass einem das Insolvenzgeld erst zusteht, wenn auch eine Insolvenz besteht. Man hat allerdings auf dem Antragsformular die Möglichkeit, ein Kreuzchen zu setzen, um einen angemessenen Vorschuss zu bekommen, was ich machte.

Den Antrag habe ich noch im November eingereicht, um zum Einen Geld zu bekommen und zum Anderen die Fristen nicht zu verpassen (innerhalb von zwei Monaten nach Bekanntgabe der Einleitung der Insolvenz). Ich bekam aber kein Geld. Auf zweimaliges Nachfragen bei der Arbeitsagentur bekam ich die E-Mail, dass die den Antrag erst prüfen können, wenn mein Arbeitsverhältnis endet. Da war die Problematik, dass mein Chef versäumt hatte, mir fristgerecht zu kündigen und ich noch bis Ende Januar angestellt war. Wer bis hierhin aufmerksam mitgelesen hat weiß, dass es das Insolvenzgeld nur für drei Monate gibt, wenn es das denn überhaupt gibt, in meinem Fall also für Oktober, November und Dezember. Januar? Pustekuchen.

Laut meines Anwalts stand mir das Januargehalt aber von meinem Arbeitgeber zu. Damit ich nicht voraussichtlich kostenlos einen vierten Monat arbeite (denn ob man Insolvenzgeld bekommt, steht auch noch in den Sternen und ist von verschiedenen Faktoren abhängig), riet mein Anwalt und ein Rechtsforum mir, von meinem Zurückbehaltungsrecht gebrauch zu machen, was ich dann auch tat. Der Brief an meinen Chef stieß natürlich nicht auf Freude, hat er mich ja eingeplant, noch für Projekte für seiner anderen Firma weiter zu arbeiten.

Die Zeit, die man das Zurückbehaltungsrecht ausübt, kann man natürlich sinnvoll dazu nutzen, sich zu bewerben und an seinen Bewerbungsunterlagen zu arbeiten (wenn man nicht eh schon auf der Straße sitzt, weil man keine Rücklagen hatte), was ich auch fleißig tat.

Ich hatte natürlich durchaus Verständnis für meinen Chef. Neben ganz kuriosen Bitten, die ich hier nicht weiter ausführen möchte, wurde mir (wohl) vom Insolvenzverwalter meines Chefs geraten, selbst direkt zu kündigen, damit ich schleunigst Insolvenzgeld bekomme. Ganz großer Fehler. Laut zwei Anwälten, einem Rechtsforum und einem Gespräch mit der Arbeitsagentur selbst, erhält man dann eine dreimonatige Arbeitslosengeldsperre. Auf keinen Fall selbst kündigen, egal, welcher Druck ausgeübt wird.

Schlussendlich bekam ich Insolvenzgeld für drei Monate. Einen Monat, den ich gearbeitet hatte, bekam ich kein Geld. Auch, als alles durch war, ging ich leer aus.

Testaufgaben nach einem Bewerbungsgespräch

Thorsten Geppert Schreib einen Kommentar

Ich habe jetzt länger überlegt, ob ich darüber überhaupt bloggen möchte. Ich mache es doch einmal, denn es gab für mich etwas sehr interessantes und es ist schon eine ganze Weile her.

Ich war auf Jobsuche, schrieb hier und da eine Bewerbung. Dann hatte ich ein Vorstellungsgespräch und der Herr am anderen Ende der Telefonleitung meinte, es könnte passen. Nachdem er über meine Konditionen nachdachte und das mit der Geschäftsleitung durchsprach, bekam ich einen Anruf, dass diese passen würden, die Firma aber eine Testaufgabe für mich hätte. Darum soll es hier gehen, nämlich um diese eine Testaufgabe und um Testaufgaben im Allgemeinen.

Nachdem wir den Techstack abgeklärt hatten und es darum um PHP und Symfony ging und ich auch sagte, dass ich von beidem keine Ahnung habe (PHP habe ich das letzte Mal vor 20 Jahren gemacht), wurde mir versichert, dass vor dem persönlichen Kennenlernen nur noch eine einfache Testaufgabe zu meistern wäre, nämlich die Umsetzung eines Kontonummer-Bankleitzahlen-IBAN-Konverters. Ich sagte: kein Problem, das musste ich auch schon in einem echten Projekt vor einigen Jahren machen, er soll mir die Aufgabe zukommen lassen. Kurze Zeit später war dann das Dokument mit der Testaufgabe da. Fünf vollgeschriebene DinA4-Seiten. Dabei ging es nicht um die Entwicklung eines Konverters, sondern um ein gesamtes Projekt mit etlichen Zwischenstationen.

Ich sollte mich erst einmal in PHP 8.1 einarbeiten. Danach in Symfony 6.1. Um beides richtig zu machen, würde ich schon keine Stunden mehr veranschlagen, sondern eher einige Tage bishin zu wenigen Wochen. Eine Programmiersprache lerne ich zwar schnell, vor allem PHP, bei der ich nicht einmal von ganz vorne einsteigen müsste, dann aber noch ein komplexes Framework, das ist Aufwand.

Zusätzlich dazu sollte ein Login-Verfahren entwickelt werden und eine dazugehörige Website mit Datenbankanbindung (MySQL oder MariaDB). In der Datenbank sollten die bereits zuvor konvertierten Daten tabellarisch dargestellt werden. Jeder Aufruf sollte einen Zähler inkrementieren.

Weiterhin sollten die Daten dann als JSON exportiert werden können.

Dazu gehörte dann die Installation und Konfiguration von Debian 11, die Installation der benötigten Software (spezielle PHP-Version, nicht in APT drin, MySQL oder MariaDB, Symfony und Apache oder NGINX).

Das war der technische Part. Dazu kam dann ein Benutzerhandbuch für den Konverter über Funktionalität und Bedienung. Dann noch eine Dokumentation für das gesamte Deployment durch einen Laien (Installation und Konfiguration Betriebssystem, Installation und Konfiguration Webserver, Installation und Konfiguration Datenbankserver, Installation und Konfiguration PHP, Installation und Konfiguration von Symfony – durch einen Laien!).

Weiterhin sollte das Projekt vorher komplett durchgeplant werden, vermute mit Pflichenheft, war nicht genauer beschrieben und es sollten auch Tests (Unit-Tests, händische Tests) durchgeführt und dokumentiert werden.

Versteht mich bitte nicht falsch: Das alles kann ich, aber rein realistisch, wenn man es vernünftig macht, ist das ein Projekt, das man nicht in einigen Stunden hinbringt, selbst, wenn man PHP und Symfony auf hohem Level beherrscht. Schon alleine am Pflichtenheft schreibt man eine Weile, das Benutzerhandbuch rotzt man auch nicht einfach runter…

Ich lehnte den Job dann mit Begründung ab. Eine Antwort darauf erhielt ich nie.

FreeBSD-Upgrade: vom Desaster doch noch zum Erfolg? Es war schrecklich

Thorsten Geppert Schreib einen Kommentar

Ich gebe es zu: Ich habe meinen Server, der online steht und, unter anderem, dieses Blog betreibt, ziemlich und auch lange vernachlässigt. Installiert war ein FreeBSD 13.3 amd64. Die aktuelle Version aus der 13er-Reihe war 13.4. So weit zurück war ich nicht, was aber das größere Problem war, waren die installierten Packages, allen voran PostgreSQL, MySQL und PHP.

Rauchender Server

Ich dachte mir, ich ziehe mein FreeBSD 13.3 direkt auf 14.2, damit zumindest das Grundsystem mal aktuell ist und Dienste wie SSH und ähnliche mit Sicherheitsupdates versorgt werden. Die Packages wollte ich dann irgendwann später nachziehen.

Also begann ich, das Upgrade durchzuführen. Das lief auch gut, bis zum ersten Reboot. Der Server kam nicht mehr hoch. Zumindest dachte ich das. Von Hetzner ließ ich mir eine KVM anschließen und war doch erstaunt: Der Server ist hochgefahren und der erste Schritt des Upgrades war erfolgreich. Jedoch hatte der Server kein Netzwerk mehr. Warum, weiß ich nicht, ich konnte es aber schnell lösen, indem ich von meiner statischen Netzwerkonfiguration auf DHCP umgestellt habe. Also weiter mit dem Upgrade.

Der zweite Reboot ging dann leider in die Hose. Ich habe mir wieder eine KVM von Hetzner anschließen lassen (die erste hatte ich nur für eine Stunde geliehen) und sah, dass ich beim Mergen der Konfigurationen irgendwo zwei Zeilen „wegoptmiert“ hatte und so ein Script, welches zum Booten benötigt wird, fehlschlug. Reboot. Die Maschine kam hoch, schmiss aber ein paar Fehlermeldungen. Problematisch war, dass ich mich mit keinem meiner Accounts anmelden konnte. Irgendwelche anderen Scripte waren auch kaputt.

Anscheinend habe ich es entweder geschafft, ein paar Dinge kaputt zu machen (was mir zuvor noch nie passiert war), oder es gab irgendwelche anderen Probleme. Durch den Boot in den Single-User-Mode konnte ich mich umsehen und habe versucht, die Probleme zu fixen. Vergeblich. Dann hatte ich aber auch keine Lust mehr und die KVM war ja auch nur für drei Stunden geliehen, es musste eine Lösung her. Fakt war, dass im etc-Verzeichnis einiges kaputt war.

Also kopierte ich das etc-Verzeichnis von einer funktionsfähigen Installation von FreeBSD 14.2, schob meine Konfigurationen hinein und kopierte alles per „scp“ auf meinen Server. Zumindest das Grundsystem funktionierte dann wieder und ich brauchte die KVM nicht mehr.

Doch kaum ein Dienst funktionierte. Wir (meine Familie und ich) sind allerdings auf ein paar Dienste angewiesen: Mail, Card– und CalDav, mein Blog, NextCloud, meine Projekte, Git, usw.

Es blieb mir nichts übrig, als alles hochzuziehen. Wieder einmal dachte ich mir, wie sinnvoll es wäre, verschiedene Dienste in verschiedenen Jails zu organisieren und regelmäßiger Updates und Upgrades durchzuführen. Es war gut ein Tag Arbeit, alles wieder ans Rennen zu bekommen, zumal auch Packages wegfielen (wxWidgets 2.8, welches ich für compow.de benötige).