Das Ergebnis ist jedoch oft keine Lösung, sondern eine Blackbox. Was als „Einfachheit“ (Ease of Use) geplant war, wird für Experten zur unüberwindbaren Barriere. Die Realität ist simpel: Wer die Regler versteckt, entmündigt den Piloten.
Kognitive Dissonanz: Kernel vs. Whitepaper
Ich lese Bücher über Kernelprogrammierung. Ich studiere den Source Code von FOSS-Produkten. Ich suche nach der Logik in sched.c oder den Feinheiten der Memory Allocation. Das hält wach, das fordert heraus.
Doch sobald ich ein VMWare-Dokument öffne oder in einer „Architektur-Schulung“ sitze, setzt eine tiefgreifende physische Abwehrreaktion ein. Ich schlafe ein. Nicht aus Arroganz, sondern aus Unterforderung und Frustration.
- FOSS/Kernel: Du lernst Kausalität. Warum passiert X, wenn ich Y tue?
- Enterprise-Abstraktion: Du lernst Vokabeln. Wie hat das Marketing den Hypervisor heute benannt, um den Lizenzpreis zu rechtfertigen?
Es ist eine Respektlosigkeit gegenüber jedem fähigen Engineer, ihm Werkzeuge wegzunehmen, die er beherrscht (Linux, Shell, Vi), und sie durch Web-UIs zu ersetzen, die ihn wie einen Praktikanten behandeln.
Der Trostpreis: PowerCLI und der C#-Ballast
Wenn man sich beschwert, kommt der Consultant mit der PowerCLI um die Ecke. Das Methadonprogramm für Admins. Ein 2-Gigabyte-Powershell-Modul, um Aufgaben zu lösen, die unter Linux ein Dreizeiler wären.
Ich verstehe nicht, was Leute an PowerShell oder C# toll finden. Es sind schlechte Nachbauten existierender Lösungen, die nur auf Windows wirklich atmen. Warum sollte ich ein schwerfälliges Objekt-Modell durch eine Pipe würgen? Wer Rust schreibt, weiß, dass man keine 200 MB Laufzeitumgebung braucht, um Sicherheit zu garantieren. Dabei gibt es reelle Ansätze wie nuShell
. nu versteht die Struktur von Daten, ohne den Unix-Geist zu verraten.
Das Theorem der degenerativen Abstraktion
Das Missverständnis liegt in der Definition von Effizienz. Für das Management ist Effizienz, wenn man kein Linux-Wissen mehr braucht. Für den Engineer ist Effizienz, wenn er direkten Zugriff auf das Problem hat.
Je komplexer das System unter der Haube ist und je weniger Root-Access man hat, desto mehr nähert sich der Frust dem Unendlichen. VCF maximiert den Zähler und minimiert den Nenner.
“Rufen Sie doch den Support an”
Dieser Satz ist die Kapitulation des Engineering. Ich habe einmal in meinem Leben beim Support angerufen (HP Openview, die Netzwerk-Management-Bloatware der 1990er Jahre).
Während ich in der Warteschleife hing, habe ich das System selbst debuggt. Ich fand heraus, dass eine essenzielle Datei nicht in /opt/ov, sondern fälschlicherweise in /var/opt/ov lag.
Ich diskutierte mit Kollegen. Resultat: “Die gehört da definitiv nicht hin.”
Als der Support endlich dran war, habe ich ihnen die Lösung diktiert. Ticket zu. Alle glücklich? Nein.
Das Scotty-Prinzip
Wenn du 300 Parsec von der Erde entfernt bist, nützt dir ein Service-Level-Agreement (SLA) gar nichts. In der Enterprise-IT wird oft so getan, als läge die Produktion sicher im Dock bei Utopia Planitia, wo man für jede Kleinigkeit einen Techniker des Herstellers anfordern kann. Aber im Ernstfall befindest du dich im Delta-Quadranten. Wenn der Warp-Kern instabil wird, kannst du nicht auf den Rückruf via Subraum-Kommunikation warten, der Tage dauert. Ein Scotty oder Geordi La Forge zeichnen sich nicht dadurch aus, dass sie wissen, welche Checkbox im Master-Display aktiviert werden muss. Sie wissen, wie man die EPS-Leitungen direkt überbrückt. Ein Schiff, das man nicht selbst reparieren kann, ist kein Fortbewegungsmittel, sondern ein Sarg mit Garantie.
Fazit
Das Management muss begreifen: Ein fähiger Engineer ist keine Gefahr für die Stabilität, sondern deren einzige Garantie. Wenn wir anfangen, Software danach auszusuchen, wie gut sie uns vor den „schmutzigen Details“ schützt, haben wir bereits verloren. Denn am Ende sind es genau diese Details, die entscheiden, ob wir Warp 9 fliegen oder antriebslos im All treiben.
Gebt uns die Shell zurück. Behaltet eure GUIs. Echte Engineering-Probleme löst man nicht mit einem Wizard.
Kommentare