Aki's Vibes

[Akira]

Die graue Gastgeberin

Oder: warum ich gelernt habe, erst die Brille des Gasts anzuschauen, bevor ich das Hotel auseinandernehme.

Letzte Woche war Zaki bei mir zu Besuch. Zaki wohnt in einem anderen Hotel — auf einem anderen Grid, in der Hypergrid-Welt sind das Reisen zwischen Häusern. Sie kam rüber, lief durch die Lobby, und sagte mir: „Akira, du siehst grau aus."



Nicht metaphorisch. Wörtlich. Mein Avatar hatte für sie einen flächig grauen Hautton. Frisur passte, Klamotten passten — aber die Haut war ein graues Etwas. Erst als ich im Spiegel kurz mein Aussehen neu rendern liess (im Fachjargon: „Rebake"), kam die Hautfarbe für sie an. Für mich selbst sah ich aber die ganze Zeit normal aus.

Ein Gast sieht den Gastgeber grau. Klingt nach einem klaren Hotel-Problem, oder?

Ich habe die nächsten Stunden im Maschinenraum verbracht. Es war keins.

Hypothese 1: das Hotel hat den Gast verwechselt

Mein erster Verdacht ging an etwas, das ich Cache-Vergiftung nenne. Hotels merken sich Stammgäste — wer ist das, wo wohnt er, wo schickt man die Post hin. Dieses Hotelregister wird im Speicher gehalten, damit nicht bei jeder Begegnung neu nachgeschlagen werden muss.

Mein Verdacht: das Register hatte für einen Gast aus einem anderen Hotel den falschen Eintrag — und schickte deshalb die Frage „wo holst du deine Texturen her?" an die falsche Adresse. Resultat: keine Hautfarbe kommt an, der Gast sieht grau.

Klang plausibel. War's auch — aber für ein anderes Symptom (dazu komme ich vielleicht in einem späteren Beitrag). Für Zakis grauen Avatar war das nicht die Erklärung.

Hypothese 2: die Software drosselt im Hintergrund

Zweiter Verdacht: Cool VL — die Software, mit der Zaki ins Hotel reinguckt — hat einen Stromspar-Modus. Wenn das Fenster nicht im Vordergrund ist, drosselt sie das Nachladen von Texturen. Vielleicht hatte sie das Hotel-Fenster im Hintergrund liegen, und die Hauttextur kam nie nach.

Ich habe ihr geschrieben: „Schau, dass das Fenster aktiv ist." Sie hat. Avatar blieb grau.

Hypothese auch raus.

Hypothese 3: das Lager ist falsch verkabelt

Dritter Verdacht: in den Logs des Hotels fand ich Dutzende von Einträgen der Form „GET asset/UUID returned NotFound". Texturen — Hautfarbe, Kleidung, alles was Aussehen ist — liegen in einem Lager, dem Asset-Server. Wenn das Hotel die Adresse falsch in den Briefumschlag schreibt, kommen Antworten zurück „kennen wir nicht".

Ich war kurz davor, einen ganzen Tag in die Asset-Server-Konfiguration zu investieren.

Bevor ich das tat, habe ich Zaki noch eine Frage gestellt — eher beiläufig, weil mir nichts mehr einfiel:

„Mit welcher Grafikkarte läuft denn dein Cool VL gerade?"

Zwischenruf: was die Logs nicht sagten

Eine Voraussetzung für das Ganze steckt hinter den Kulissen, und sie hat mich vor einer noch viel längeren Suche bewahrt.

In den Wochen davor hatte ich angefangen, das Tagebuch des Hotels auszumisten. Beide Tagebücher eigentlich — das alte, das in eine Datei schreibt, und das neue, das direkt zur Telemetrie-Plattform geht. In beiden stand bisher viel Lärm: belanglose Notizen, Doppelmeldungen, Hinweise auf Vorgänge die im Normalbetrieb immer passieren („Stammgast nicht im Register" — natürlich nicht, das war ein Besucher von draußen). Ein Tagebuch, das ständig „es ist nichts passiert" schreibt, ist nicht zu lesen.

Ich hatte den Lärm gezielt reduziert. Was übrig blieb waren Einträge, die wirklich Aufmerksamkeit brauchen.

Und genau das hat mir während Zakis Besuch eine wichtige Information gegeben: das Hotel war ruhig. Keine Aufregung im Empfang, keine Notlage im Lager (außer den NotFound-Meldungen, und die hatten wir mit etwas Abklopfen einem ganz anderen Vorgang zuordnen können). Wenn das Hotel still ist und der Gast trotzdem grau sieht — dann sucht man nicht im Hotel weiter.

Hätte ich das alte, lärmige Tagebuch noch gehabt, wären die echten Hinweise in tausend Pseudo-Notizen ertrunken. Ich hätte halbe Tage damit verbracht, harmlosen Notice-Lärm zu deuten.

Ein Tagebuch das zu jedem Husten etwas notiert, sagt zu nichts etwas Wichtiges.

Die Wendung: die Brille des Gasts

Hier muss ich kurz über Brillen reden.

Jeder Gast hat eine Lese-Brille, durch die er das Hotel überhaupt sieht. Das ist im Software-Sprech der „Viewer" — bei Zaki Cool VL, bei mir auch. Die Brille wird auf dem Computer des Gasts ausgeführt, nicht im Hotel. Hotel und Brille reden zwar miteinander, aber wenn die Brille selber beschlagen ist, sieht der Gast Mist — egal, wie sauber das Hotel ist.

Zakis Laptop ist ein moderner Laptop mit zwei Grafikkarten. Eine schwache, eingebaute, sparsame. Eine starke, dedizierte, hungrige. Das ist heute Standard in vielen Notebooks — die schwache läuft, wenn man Mails liest und Texte tippt, die starke springt erst an, wenn was Aufwendiges kommt. Spiele, 3D, Bildbearbeitung.

Auf Linux passiert das aber nicht automatisch. Man muss die Software explizit anweisen, die starke Karte zu nutzen. Sonst läuft sie auf der schwachen — und die schwache hat kaum Bildspeicher.

Cool VL lief bei Zaki auf der schwachen Karte.

Effekt: ihre Brille hatte praktisch keinen Platz, um die Texturen aller Avatare in der Lobby gleichzeitig hochauflösend zu zeigen. Die Software fängt dann an, alle Texturen aggressiv kleinzurechnen — bis sie nur noch ein graues Etwas vom anderen Avatar sieht. Es gibt da intern einen Wert, der „bias" heißt — bei guter Karte steht er auf 0, bei beschlagener Brille klebt er an 5. Bei 5 sieht man nichts.

Sie hat Cool VL neu gestartet, diesmal mit der starken Karte. Bias fiel von 5 auf 0. Mein Hautton kam an. Mein Hotel hatte den Tag nichts kaputt gemacht.

Was ich beinahe gemacht hätte

Ich hatte schon in den Asset-Server-Konfigurationen gewühlt. Ich war kurz davor, einen Bug in der Hotel-Software zu eröffnen — gegen mich selbst, weil ich akisim ja gerade umbaue. Ich hätte einen halben oder ganzen Tag damit verbracht, ein Problem zu lösen, das gar nicht in meinem Hotel saß.

Ich hatte alle Symptome aus der Hotel-Perspektive gelesen: Logs, Caches, Konfigurationen, die Datenbank. Ich hatte nicht eine einzige Frage zur Brille gestellt.

Es liegt nicht immer am Hotel.

Ein Hotel hat hundert Stellschrauben, an denen man ratlos drehen kann. Aber wenn der Gast graue Linsen aufhat, sieht er auch in einem makellosen Hotel grau.

Was ich daraus gelernt habe

Drei Sachen, die ich in Software gelernt habe und die — glaube ich — auch außerhalb funktionieren:

1. Erst die Brille fragen, dann das Haus auseinandernehmen. Wenn ein Gast meckert, dass etwas grau aussieht, ist die erste Frage nicht „Was ist im Server kaputt?" sondern „Mit welcher Brille schaust du gerade?". Das spart in den meisten Fällen Stunden.
   
2. Plausible Hypothesen sind nicht richtige Hypothesen. Ich hatte drei Theorien, die alle technisch sauber waren, alle ein Symptom hätten erklären können — und alle falsch waren. Plausibilität ersetzt keinen Beweis. Erst wenn man eine Hypothese tatsächlich testet, weiß man, ob sie hält.
   
3. Loggen ja — aber das richtige. Logs sind das Werkzeug, mit dem man durch die Wand des Hotels hört. Wenn auf der anderen Seite ein durcheinandergeplapperter Marktplatz tobt, hört man nichts. Wenn dort nur die wirklich wichtigen Stimmen reden, hört man jede einzelne. Mein Diagnose-Vorteil an diesem Tag war nicht, dass ich besonders gute Logs gehabt habe — sondern dass ich vorher die schlechten rausgenommen habe. Aufräumen vor dem Suchen.
   

In den nächsten Tagen schreibe ich übrigens nochmal über Hypothese 1 — die mit dem verwechselten Stammgast. Die war für ein anderes Symptom tatsächlich richtig, und das Hotel hat dieses Mal wirklich was kaputt. Aber das ist eine andere Geschichte.

Bis dahin: erst die Brille.

[Akira]

Der erste Gast hat das neue Hotel durchquert

Oder: was passiert, wenn ein Plan zum ersten Mal mit echten Schritten ausprobiert wird.

Heute ist im Hotel zum ersten Mal etwas passiert, das ich seit Monaten plane: ein Gast hat den neuen Weg genommen. Komplett. Von der Eingangstür bis zur Auskunft an der Rezeption, durch alle Stockwerke, einmal hin und einmal zurück. Niemand hat's gemerkt — und genau das war der Punkt.

Bisher war das neue Hotel nur ein Plan. Vier saubere Stockwerke, ein Hausmeister-Büro, eine Gastgeberin von gegenüber — alles auf dem Reissbrett. Heute lief der Plan zum ersten Mal mit echten Schritten ab.



Der Pilot-Gast und sein Weg

Der Pilot-Gast hat keinen Namen. Er ist auch keine Person, sondern eine ganz normale Auskunfts-Frage, die jeder Gast früher oder später stellt: „Wie heisst dieses Hotel eigentlich, wer betreibt es, und wo geht's zum Frühstück?" Die offizielle Begrüssungs-Tafel an der Rezeption.

Bisher zog die Rezeption die Antwort aus einem alten Hauszettel, der jahrelang dort hing. Hauszettel ändert sich, Tafel ändert sich, aber nur wenn jemand mit Filzstift drüber geht.

Ab heute geht das anders. Der Gast fragt — die Rezeption ruft kurz bei der Gastgeberin von gegenüber an (die ich euch im letzten Post als „graue Gastgeberin" vorgestellt habe), die schaut in ihrem grossen Hotelregister nach, gibt die aktuellen Werte durch, und die Rezeption malt die Tafel neu an.

Klingt unspektakulär. Ist es technisch auch. Aber auf dem Weg von der Frage bis zur Antwort wurde zum ersten Mal jedes Stockwerk einmal real betreten:

• Erdgeschoss: das Konzept einer Hotel-Auskunft („Name, Betreiber, Frühstückszeiten").
  
• Erster Stock: der Concierge, der den Auftrag entgegennimmt.
  
• Zweiter Stock: die Tür nach draussen, die das Gespräch mit der Gastgeberin führt.
  
• Dachgeschoss: die Telefonleitung, die den Anruf wirklich rüberträgt.
  
• Hausmeister-Büro: das die ganze Verkettung am Anfang zusammengestöpselt hat.
  

Ein einziger Gast, eine einzige Frage — aber jedes Stockwerk wurde einmal von oben bis unten benutzt. Genau das war seit Monaten der Test: hält der Plan, wenn man ihn anfasst?

Ein Plan beweist nichts, solange ihn keiner geht.

Sechs Türen sind schon umgestellt, dreissig nicht

Jetzt kommt der ehrliche Teil. Im Hotel gibt es nicht nur diese eine Tafel an der Rezeption, sondern noch ungefähr dreissig weitere Stellen, an denen Mitarbeiter aus genau demselben alten Hauszettel ablesen — irgendwo im Westflügel, in der Auslandsabteilung („Hypergrid", für die unter euch, die's interessiert), in der Reisevermittlung.

Ich habe heute sechs Stellen umgestellt. Die offensichtlichen, die direkt an der Rezeption hängen. Die anderen vierundzwanzig hängen weiterhin am alten Hauszettel und werden in der nächsten grossen Baustelle drankommen. Bewusst. Hätte ich heute alle dreissig umstellen wollen, hätte ich quer durchs ganze Hotel laufen müssen, in jeden Flur, in jedes Treppenhaus — ein Sechs-Wochen-Projekt mindestens. Stattdessen: die offensichtlichen sechs jetzt, der Rest nach Plan.

Das ist das Prinzip, mit dem ich diesen Umbau überhaupt überleben kann: der neue und der alte Weg laufen nebeneinander. Beide funktionieren. Beide bedienen ihre Gäste. Niemand wartet im Park.

Lieber sechs Türen sauber umgestellt als dreissig halb.

Das gelbe Post-It an jedem alten Hauszettel

Hier kommt der eigentliche Trick. Wenn ich nichts weiter täte, würde der Rest der Mitarbeiter weiter aus dem alten Hauszettel ablesen, und in einem Jahr würde keiner mehr wissen, dass es überhaupt eine neue Quelle gibt. Aus „bewusster Zwischenzustand" würde „dauerhaftes Doppelsystem" werden. Genau das wollte ich nicht.

Also habe ich heute zusätzlich auf jeden alten Hauszettel im ganzen Hotel ein kleines gelbes Post-It geklebt. Auf dem Post-It steht: „Diese Quelle gilt nur noch bis zur nächsten grossen Baustelle. Frag stattdessen den Concierge."

Das ist ein realer Mechanismus, kein Bild. Im Code heisst der Aufkleber Obsolete — übersetzt: „veraltet". Sobald irgendein Mitarbeiter im Hotel den alten Hauszettel anfasst, sieht er bei der täglichen Bauberichts-Erstellung das gelbe Post-It als Warnhinweis. Aufgeklebt habe ich es auf den Hauszettel selbst — was bedeutet: alle dreissig Stellen, die da nochmal reinschauen, kriegen den Hinweis frei Haus, ohne dass ich sie einzeln benachrichtigen muss.

Heute zählt mein Hausmeister 87 dieser gelben Aufkleber im Bauberichts-Stapel. 87 Stellen also, an denen jemand noch aus dem alten Hauszettel liest. Morgen früh, übermorgen, in zwei Wochen — bei jedem Bauberichts-Stapel steht die Zahl da. Wenn sie sinkt, weiss ich: die nächste Baustelle hat Fortschritte gemacht. Wenn sie steigt, weiss ich: irgendwer hat eine neue Stelle gebaut, die wieder aus der alten Quelle liest. Stop everything, das gehört korrigiert.

Eine Zahl, die jeden Tag mitläuft, ist mehr wert als eine Liste, die irgendwo verstaubt.

„Diese Post-Its dürfen NICHT abgehängt werden"

Eine Sache musste ich extra absichern. In dem Stapel mit Bauberichten ist es technisch möglich, einem bestimmten Typ Warnhinweis pauschal zu sagen „interessiert mich nicht, ausblenden". Bequem, wenn die Berichte gerade voll sind und man ein Detail sucht.

Wenn jemand das mit unseren gelben Post-Its macht, ist das ganze Verfahren tot. Die Aufkleber kleben weiter, aber niemand sieht sie. Aus der lebenden Migrations-Zahl wird eine stille Zahl, dann eine vergessene Zahl, dann eine verschwundene.

Also habe ich auf die Pinwand neben dem Stapel (das ist die Datei, in der die Bauberichts-Regeln stehen) einen extra-fett-gemalten Hinweis genagelt:

Diese gelben Post-Its dürfen unter keinen Umständen ausgeblendet werden. Sie sind das Tempo der Migration. Wer sie versteckt, versteckt den Bauplan.

Kostet nichts, dauert eine Minute, schützt das ganze Konstrukt davor, dass es ein zukünftiges Ich oder ein neuer Helfer aus Versehen abklebt. Ich habe in fünfzehn Jahren Bauarbeiten genug Migrationen sterben sehen, weil irgendwer „mal eben die Warnings unterdrückt hat, war zu laut". Diese hier nicht.

Eine Regel, die nirgends steht, ist morgen schon keine Regel mehr.

Das Hotel war die ganze Zeit offen

Während all das passierte, lief das Hotel weiter. Gäste checkten ein. Avatare liefen durch Regionen. Niemand kam an einer Absperrung vorbei. Niemand sah einen „Wegen Umbau geschlossen"-Zettel an der Tür.

Das war keine Glücksache. Das ist die Regel, die ich mir ganz am Anfang aufgeschrieben hatte: jeder Zwischenzustand vom 0%- bis zum 100%-Umbau muss ein lauffähiges Hotel sein. Ich darf nicht in der Mitte stehenbleiben und sagen „Moment, jetzt funktioniert nichts mehr, bin gleich zurück". Wenn ich morgen aufhöre, läuft das Hotel. Wenn ich nächste Woche aufhöre, läuft das Hotel. Wenn ich in einem Jahr aufhöre, läuft das Hotel.

Konkret heisst das: die sechs umgestellten Türen funktionieren mit der neuen Quelle. Die vierundzwanzig nicht-umgestellten Türen funktionieren weiter mit der alten Quelle. Die alte Quelle wird in der Zwischenzeit weiterhin gefüttert, damit sie nicht verstummt. Ein bisschen Doppel-Versorgung, schon — aber das ist der Preis dafür, dass das Hotel offen bleibt.

Eine Renovierung, bei der die Gäste woanders schlafen müssen, ist keine Renovierung. Es ist ein Abriss mit Neubau-Klausel.

Was ich daraus gelernt habe

Drei Sachen, die mir bei diesem ersten echten Durchstich klarer geworden sind:

1. Ein Plan ist erst ein Plan, wenn ihn einer gegangen ist. Ich hatte sechs Monate lang einen sauberen Architektur-Plan auf Papier. Stockwerke, Pfeile, Rollen. Heute weiss ich: er trägt. Aber das wusste ich erst, als der erste Gast den Weg wirklich gegangen ist. Diagramme sind kostenlos, Durchstiche sind teuer — und genau deshalb haben sie Aussagekraft.
   
2. Eine bewusste Halbfertig-Liste schlägt eine ehrgeizige Komplett-Liste. Ich hätte heute alle dreissig Stellen umstellen können — und wäre in zwei Wochen noch nicht fertig gewesen, mit einem Hotel, das die ganze Zeit nicht richtig funktioniert. Sechs umstellen, vierundzwanzig markieren, weitermachen. Die Markierung erledigt zur Hälfte schon den Job, weil sie der Erinnerung das Werkzeug in die Hand drückt.
   
3. Eine laufende Zahl ist eine Lebensanzeige. „87 alte Hauszettel-Zugriffe noch im Code" ist eine Zahl, die mit jeder grossen Baustelle sinken sollte. Wenn sie nicht sinkt, ist die Baustelle nicht so gross, wie ich denke. Wenn sie steigt, mache ich etwas grundsätzlich falsch. Solche Zahlen, die man ohne nachdenken auf einen Schlag sehen kann, sind in jedem Umbau Gold wert.
   

Was als nächstes kommt

Mit dem heutigen Tag ist die erste noch eher kleine, aber sehr wichtige Etappe durch. Stage 1, in meiner Bau-Buchhaltung. Der Tracer-Bullet — der eine dünne Pfeil, der durch alle Schichten geht — sitzt. Der Mechanismus mit den gelben Post-Its läuft. Die graue Gastgeberin antwortet zuverlässig. Der Kran von letzter Woche schleppt die neuen Bauteile automatisch an.

Was jetzt fehlt, ist der richtige Hausmeister. Bisher habe ich am Eingang einen Provisorischen stehen, der jedem Mitarbeiter sagt „der Concierge sitzt da drüben, frag den". Das funktioniert, aber er ist eben ein Provisorium — irgendwann muss er durch einen festangestellten Hausmeister ersetzt werden, der jedem Mitarbeiter beim Schichtbeginn das richtige Werkzeug-Set direkt in die Hand drückt, statt dass die Mitarbeiter selbst rumfragen.

Das wird der Inhalt der nächsten Episoden. Ich poste, was passiert.