Zwanzig Jahre, von der Infrastruktur zum Bildschirm

Das Maß unsichtbarer Arbeit ist, dass sie nur beurteilt wird, wenn sie ausfällt. Zwanzig Jahre habe ich das gelernt; dann bin ich auf die sichtbare Seite gewechselt.

Karrieren sehen im Rückblick ordentlich aus. Im Erleben sind sie es nicht: Jeder Abschnitt beginnt mit einem Problem, das der vorherige nicht lösen konnte.

Dieser Text handelt von vier Abschnitten. Aber er ist kein Lebenslauf — er handelt davon, welche Gewohnheit sich in der nächsten Schicht als nützlich erwies und welche fallen gelassen werden musste.

2005–2013 — Unternehmensinfrastruktur

Server, Speicher, Backup, Verfügbarkeit.

Wenn dieser Abschnitt eines gelehrt hat, dann dies: ein funktionierendes System ist unsichtbar, solange es funktioniert. Backups kommen jahrelang auf niemandes Tagesordnung. Dann werden sie eines Tages gebraucht, und dieser Tag ist die Prüfung für alles, was bis dahin getan wurde.

Die berufliche Folge ist seltsam. Gut gemachte Infrastrukturarbeit erzeugt kein Lob, nur Stille. Lob kommt erst, wenn etwas ausfällt und die Erholung schnell ist — Ihr sichtbarster Moment ist also Ihr schlechtester Tag.

Die mitgenommene Gewohnheit: das Wiederherstellungsszenario vor dem Aufbau schreiben. Die erste Frage beim Bau eines Systems lautet nicht „wie wird es funktionieren", sondern „wie kommen wir zurück, wenn es kaputtgeht". Dass ein Backup existiert, genügt nicht; die Wiederherstellung muss geprobt worden sein. Ein ungetestetes Backup ist kein Backup.

2013–2019 — Netzwerke und Sicherheit

Routing, Firewalls, Zugang.

Netzwerkarbeit lehrt, ein System als Topologie zu sehen. Nicht einzelne Kästen, sondern die Beziehungen zwischen ihnen. Wo ein Paket entlangläuft, welche Regel es stoppt, warum ein Weg einem anderen vorgezogen wird.

Die bleibendste Lehre dieses Abschnitts betrifft nicht die Sicherheit, sondern die Sichtbarkeit: Die Voraussetzung, ein Problem zu lösen, ist, es sehen zu können. Die meisten Netzwerkfehler sind nicht rätselhaft; sie sind nur ungemessen. Setzt man an der richtigen Stelle einen Zähler, löst sich das Rätsel auf.

Die zweite Lehre betrifft Voreinstellungen. Firewall-Regeln häufen sich mit der Zeit; jede war einmal nötig, keine wurde je entfernt. Fünf Jahre später kann niemand die ganze Liste erklären. Ein Team, das nicht aufschreibt, warum eine Regel existiert, kann sie nie löschen.

Deshalb erklären die Codekommentare, die ich heute schreibe, „warum es so ist", nicht „was es tut". Was es tut, steht bereits im Code.

2019–2024 — Identität und M365

Active Directory, Migrationen, Cloud-Identität. Ordnung im Maßstab von Tausenden Konten.

Identitätsarbeit ist eine Lehre über Skalierung. Zehn Konten verwalten Sie von Hand. Bei Tausenden verwandelt sich alles Handgemachte früher oder später in Inkonsistenz — denn Handarbeit ist nicht wiederholbar.

Die mitgenommene Gewohnheit: eine Ausnahme ist keine Lösung, sie ist eine Schuld. Eine für einen Nutzer geöffnete Sonderregel bleibt lange im System, nachdem dieser Nutzer gegangen ist. Im Maßstab lautet die richtige Antwort nicht, die Ausnahme zu erfassen, sondern die Regel so neu zu schreiben, dass die Ausnahme überflüssig wird.

Migrationsprojekte fügen ihre eigene Lehre hinzu: eine Migration ohne Rückfallplan ist keine Migration, sondern eine Wette. Und der Rückfallplan muss vor der Migration geprobt werden, nicht danach.

2024 — heute

KI-gestützte Webanwendungen und Webtechnologien. Modelle und Agenten, mit derselben Disziplin zum Bildschirm gewendet.

Der Übergang ist weniger scharf, als er aussieht. Eine moderne Webanwendung ist Probleme verteilter Systeme im Kleinen: Zustandsverwaltung, Konsistenz, Fehlerbehebung, Beobachtbarkeit. Die Namen ändern sich, die Fragen bleiben.

Die KI-Schicht belohnt Infrastrukturgewohnheiten indes auf unerwartete Weise. Ein Sprachmodell ist eine unsichere Komponente: Es kann bei gleicher Eingabe unterschiedliche Ausgaben liefern, es kann still falsch sein, und es scheitert, ohne eine Fehlermeldung zu erzeugen. Genau diese Fehlerklasse wurde jahrelang bearbeitet — nur die Schicht hat sich geändert.

Die Fragen, die ich beim Schreiben eines Agenten stelle, sind daher dieselben wie beim Aufsetzen eines Servers: Wo messe ich? Woran erkenne ich, dass er falsch geantwortet hat? Wie weit kann ich zurückrollen, wenn er kaputtgeht?

Der Unterschied verschärft sich an einem Punkt. Wenn ein Server kaputtgeht, sagt er es Ihnen: Der Dienst fällt aus, die Überwachung alarmiert, eine Zeile landet im Logfile. Wenn ein Sprachmodell kaputtgeht, erzeugt es einen flüssigen Satz. Der Fehler ist still und obendrein überzeugend.

Praktisch heißt das: Klassische Überwachung reicht nicht. Für einen Server genügt „läuft er"; bei einem Modell muss man „stimmt es" gesondert fragen, und diese Frage beantwortet sich nicht von selbst. Die Ausgabe an einen überprüfbaren Boden zu binden — eine Quelle, eine Berechnung, eine Messung — muss Teil der Architektur sein.

Zwanzig Jahre Gewohnheit passen hier genau: vertrauen Sie nicht der Ausgabe, sondern ihrer Grundlage.

Was mitgenommen wurde

Der gemeinsame Nenner der vier Abschnitte sind vier Gewohnheiten:

Alle vier tun heute dieselbe Arbeit. Die Verifikationssuite dieser Website — die Testreihe, die sich weigert, auf Screenshots zu schauen, und stattdessen Luma vom Canvas liest — ist ein direktes Produkt der zweiten. Die Entscheidungsprotokolle im Repository sind das der vierten.

Der gemeinsame Faden: ein Fehlerbudget

Ein Begriff wiederholt sich in allen vier Abschnitten, auch wenn sein Name jedes Mal wechselt.

In der Infrastruktur hieß er „Verfügbarkeitsziel". Hundert Prozent Verfügbarkeit gibt es nicht; was es gibt, ist vorab zu sagen, wie viel Ausfall Sie akzeptieren. Ein Team, das das nicht sagt, führt bei jedem Ausfall dieselbe Diskussion von vorn.

Im Netzwerk hieß er „akzeptable Latenz". In der Sicherheit „akzeptiertes Risiko". Im Identitätsmanagement „welche Ausnahmen genehmigt sind". Auf der Produktseite „Performance-Budget".

Alle meinen dasselbe: eine Grenze im Voraus aufschreiben. Wo keine Grenze geschrieben steht, wird jede Entscheidung zur Verhandlung, und Verhandlungen gewinnt meist, wer in dem Moment am lautesten ist.

Der Schreibbereich dieser Website hat ebenfalls ein geschriebenes Budget: größte Inhaltsdarstellung unter 2,5 Sekunden, Seitenskript unter 60 KB, kein Opazitätsgatter vor dem Text. Alle drei werden von der Verifikationssuite bei jedem Lauf gemessen. Wird die Zahl überschritten, wird der Test rot — es beginnt keine Diskussion.

Das mag die praktischste Lehre aus zwanzig Jahren sein: guter Wille ist kein Kontrollmechanismus. Eine Grenze wird entweder gemessen, oder es gibt sie nicht.

Was zurückblieb

Es gibt Dinge, die nicht mitgenommen wurden, und sie loszulassen war schwerer als das Mitnehmen.

Die Erwartung fehlerfreien Betriebs. In der Infrastruktur ist das Ziel null Ausfallzeit. Auf der Produktseite führt ein Null-Fehler-Ziel dazu, nie etwas auszuliefern. Das neue Kriterium wurde nicht „geht es nie kaputt", sondern „was passiert, wenn es kaputtgeht".

Widerstand gegen Veränderung. Im Serverraum ist der sicherste Zug, sich nicht zu bewegen; ein laufendes System anzufassen ist Risiko. Auf der Produktseite gilt das Gegenteil: Was nicht angefasst wird, veraltet. Dieselbe Vorsicht muss in eine andere Richtung wirken — nicht den Zug verhindern, sondern ihn umkehrbar machen.

Unsichtbarkeit für eine Tugend zu halten. Zwanzig Jahre lang war gute Arbeit unbemerkte Arbeit. Dieses Kriterium stimmte im eigenen Feld, lässt sich aber nicht verallgemeinern. Wo es ein Feld gibt, in dem die Arbeit sichtbar sein soll, ist Stille dort keine Tugend, sondern Abwesenheit.

Diese Website ist das Protokoll jenes Unterschieds. Zwanzig Jahre habe ich Systeme gebaut, die niemand sieht; jetzt baue ich die Oberfläche — und lerne, dass auch die Oberfläche messbar sein muss.

Warum der Übergang leicht aussieht und es nicht ist

Die meisten, die von der Infrastruktur zum Produkt wechseln, tappen in dieselbe Falle: Sie nehmen an, technische Kompetenz sei übertragbar. Sie ist es — aber allein genügt sie nicht.

Was fehlt, ist nicht technisch. In der Infrastruktur ist „richtig" meist singulär: Eine Konfiguration funktioniert oder nicht, ein Backup stellt wieder her oder nicht. Auf der Produktseite ist richtig plural und hängt vom Kontext ab. Ob eine Oberflächenentscheidung „richtig" ist, ändert sich danach, für wen sie ist und was sie erreichen soll.

Für eine ingenieurhafte Gewohnheit ist das ein unbequemer Zustand. Die gewohnte Gewissheit ist weg. An ihre Stelle tritt Messung: Wo die Wahrheit nicht singulär ist, bleibt zu messen, was jede Option erzeugt, der einzige ehrliche Weg.

Die zweite Lücke: Unsichtbare Arbeit hat kein Publikum, sichtbare schon. Zwanzig Jahre lang war das Gegenüber der Arbeit ein System. Jetzt ist das Gegenüber ein Mensch, und dessen Geduld, Aufmerksamkeit und Kontext schwanken. Das ist kein zu lösendes Problem, sondern eine einzurechnende Realität.

Eine Anmerkung

Jeder der obigen Abschnitte enthält konkrete Ereignisse, die man einzeln erzählen könnte: eine bestimmte Migration, eine bestimmte Ausfallnacht, eine bestimmte Architekturentscheidung. Dieser Text enthält sie nicht.

Der Grund ist einfach: Dieser Text handelt von Disziplinen, nicht von Fällen. Fälle verdienen eigene Texte, und jeder sollte mit seiner eigenen Messung kommen — wie die übrigen Texte in diesem Bereich.

Verallgemeinern birgt ein Risiko, und ich bin mir dessen bewusst: Zwanzig Jahre auf vier Punkte zu reduzieren, plättet die tatsächlichen Entscheidungen in jenen Jahren. Zu erklären, woher eine Gewohnheit kam, ist nicht dasselbe wie zu erklären, wie man sie erworben hat. Das Zweite dauert länger und verlangt konkretere Beispiele.

Dennoch hat diese Liste eine Funktion: Sie legt den Boden fest, auf dem Sie den nächsten Text lesen. Warum ein derart an Messung gebundener Schreibbereich so gebaut wurde, lässt sich mit diesen vier Gewohnheiten erklären. Der Rest steckt in den Fällen.