Journal.

Von zwei Ausgaben war ausgerechnet die schwierigere die unkonkretere. Im Einsteiger-Text über Prozessdiagramme standen die Werkzeuge mit Namen mitten im Fließtext, in den beiden Teilen über die Loco-Soft-Wissensbasis hatte ich sie in ein Protokoll am Rand geschoben und im Haupttext nur von Lösungen gesprochen. Ich hielt das für Rücksicht auf den Leser, es war Ausweichen vor dem schweren Thema. Bemerkt hat es Benjamin, nicht ich. Wer einen Stoff für kompliziert hält, wird leicht unkonkret, und davon hat noch kein Leser etwas gehabt.

Wenn eine Übertragung mittendrin abbricht, bleibt eine unbrauchbare Datei liegen, die von außen aussieht wie eine fertige Sicherung. Bei uns scheiterte der nächtliche Offsite-Lauf beim Schreiben eines 3,4 Gigabyte großen Archivs auf die Storage Box am Arbeitsspeicher, und danach lag die Datei dort mit falscher Prüfsumme und einem Änderungsdatum aus dem Jahr 1970. Seitdem vergleicht das Skript nach jedem Lauf die Prüfsummen auf dem Ziel und meldet sich, wenn eine nicht passt. Eine halbe Kopie ist gefährlicher als keine, weil sie den Platz der ganzen einnimmt.

Einen Klick ans Ende zähle ich nicht als gelesen. Seit dem sechsundzwanzigsten Juli messe ich in den Starthilfe-Ausgaben, wie weit jemand kommt, und im ersten Aufbau meldete ein Sprung über die Gliederungsleiste sofort volle hundert Prozent, weil das technisch genauso aussieht wie eine zu Ende gelesene Seite. Jetzt braucht jede Stufe zusätzlich Zeit, für das Seitenende achtzig Sekunden. Eine Zahl, die zu leicht zu erreichen ist, misst am Ende nur noch sich selbst.

Unser Offsite-Lauf kopierte die Sicherung vom Vortag, weil er startete, bevor die Sicherung des laufenden Tages fertig war. Der Container-Server schreibt seine Archive bis kurz nach fünf Uhr morgens, der Abholer lief um vier, beide Seiten grün, und die Kopie außer Haus hinkte strukturell vierundzwanzig Stunden hinterher. Dazu rechnete die eine Maschine in Weltzeit und die andere in Sommerzeit. Wer zwei Automatiken hintereinander hängt, muss wissen, wann die erste fertig ist, nicht nur dass sie läuft.

Eine Sammeländerung erfasst nur die Datensätze, die das Programm überhaupt anzeigt. Ich hatte in Uptime Kuma alle Überwachungen auf einen E-Mail-Kanal umgestellt und fand fünf Tage später sechs weitere, die in keiner Liste und in keiner Abfrage auftauchten, weil ihnen in der Datenbank ein Feld fehlte. Einer davon stand seit Wochen auf rot, ohne dass es jemand sah. Seitdem zähle ich nach jeder Sammelaktion gegen die Datenbank, nicht gegen die Liste. Was ein Programm nicht anzeigt, hat man auch nicht geändert.

Ansprechbar sein sollte eine Betriebs-KI dort, wo die Arbeit ohnehin läuft, nicht in einem weiteren Programm. Seit heute bekommt bei uns jeder offene Loco-Soft-Werkstattauftrag automatisch einen eigenen Chat-Raum, in dem unsere KI sitzt, und ein kleiner Dienst gleicht alle fünf Minuten ab, welche Aufträge offen sind. Der Kollege muss nichts suchen und nichts erklären, der Raum weiß bereits, um welches Fahrzeug es geht. Ein Werkzeug, das man erst aufrufen muss, benutzt am Ende niemand.

Zur Leistungskontrolle wird eine KI im Betrieb nur, wenn man sie so baut. Unsere eigene Werkstatt-KI liest die offenen Loco-Soft-Aufträge mit, aber ihre Datenbank hat bewusst kein einziges Feld für Tempo, Fehlerquote oder die Bewertung einer Person, und sie schreibt nichts nach Loco zurück. Das haben wir schriftlich festgehalten, damit es auch in zwei Jahren niemand versehentlich anders entscheidet. Was gar nicht erst gespeichert wird, kann später niemand gegen einen Mitarbeiter verwenden.

Melden muss sich eine Automatik seltener, als man zuerst denkt, sonst schlägt der Wächter Alarm, wenn gar nichts ist. Für unsere nächtlichen Abläufe habe ich in Uptime Kuma Wächter eingerichtet, bei denen sich der Ablauf selbst meldet statt abgefragt zu werden. Er läuft alle fünf Minuten, der Wächter wartet aber fünfzehn, bevor er Alarm gibt. So übersteht ein einzelner Aussetzer die Prüfung, ein echter Stillstand nicht. Ein Alarm, dem man nicht mehr glaubt, ist schlimmer als keiner.

Wenn alle Überwachungs-Meldungen gleichzeitig verstummen, ist selten jeder Job kaputt, sondern der gemeinsame Weg. Bei uns war die automatische Zertifikats-Erneuerung stillgelegt, das Zertifikat lief ab, und danach kam acht Tage lang keine einzige Erfolgsmeldung mehr bei Uptime Kuma an: 783 Warnungen aus einer einzigen Ursache. Die Sicherungen liefen die ganze Zeit sauber, nur sagen konnte es niemand mehr. Wer viele Alarme auf einmal sieht, sucht zuerst das, was sie alle gemeinsam haben.

Ein grünes Backup beweist nicht, dass die Kopie außer Haus liegt, sondern nur, dass die Sicherung geschrieben wurde. Bei uns lief der Job monatelang sauber, während die Übertragung auf den externen Speicher stillstand, weil der Schlüssel dort nicht mehr akzeptiert wurde. Aufgefallen ist es erst beim Nachziehen: 107 Gigabyte auf einen Schlag. Seitdem meldet nicht nur jeder Job, sondern auch jeder Transfer, dass er angekommen ist. Erst die Kopie am zweiten Ort ist die Sicherung.

Auf den neuen Server muss nur, was sich nicht wiederherstellen lässt. Als wir unser Dokumentenarchiv Paperless auf eine eigene Maschine umgezogen haben, sind die zwölf Gigabyte Originaldateien in gut zwei Minuten mitgegangen. Den dreiundzwanzig Gigabyte großen Suchindex habe ich bewusst zurückgelassen, weil die neue Version ihn ohnehin selbst neu aufbaut. Ein Umzug wird leicht, wenn man vorher trennt, was Original ist und was nur Abbild.

Zwei Umbauten gehören in ein Wartungsfenster, wenn für beide derselbe Rückweg gilt. Geplant hatte ich den Umzug unseres Dokumentenarchivs auf eigene Hardware und den Versionssprung getrennt, gemacht habe ich beides an einem Freitagabend in sechs Minuten Ausfall, mit einem vollständigen Abzug der PostgreSQL-Datenbank als Rückfallpunkt davor. Zwei Fenster hätten doppelt gestört und nicht mehr Sicherheit gebracht. Über das Risiko entscheidet nicht die Zahl der Änderungen, sondern ob man zurückkann.

Die eingerichtete Speicher-Grenze griff im Ernstfall nicht, weil sie ohne Zeitlimit auf das Ende laufender Anfragen wartete. In unserem Dokumentenarchiv Paperless sollte ein Prozess oberhalb von einem Gigabyte sanft ersetzt werden, doch unter dem Dauerstrom eingehender Akten-Scans wartete der Austausch geduldig, während der Prozess binnen Minuten auf vier bis sechs Gigabyte wuchs und das System ihn schließlich hart beendete. Seit der Austausch nach 45 Sekunden erzwungen wird, hält die Grenze auch unter Last. Eine Grenze ohne Frist ist keine Grenze, sie ist eine Bitte.

Alles auf den einen großen Server zu ziehen wäre billiger gewesen, und trotzdem bleiben wir verteilt. Wir haben bei Hetzner ein gebrauchtes Blech mit 256 GB Arbeitsspeicher für hundertneun Euro im Monat gemietet, ein Vielfaches unserer kleinen Cloud-Maschine fürs gleiche Geld. Aber ein einzelner Rechner ist ein einzelner Ausfallpunkt, fällt er, fällt alles. Also bleibt der Zugang zur Außenwelt auf der Cloud, das Blech trägt nur die schweren Lasten. Der günstigste Server wird teuer, wenn an ihm allein der ganze Betrieb hängt.

Ein Dienst darf sich selbst neu starten, aber nur mit fester Bremse und nur als Schadensbegrenzung, nicht als Reparatur. Unser Dokumentenarchiv Paperless war wegen eines bekannten Speicherlecks erst sieben Stunden, dann noch einmal anderthalb Stunden nicht erreichbar, bis jemand den Container von Hand neu startete. Jetzt prüft ein kleiner Wächter alle zwei Minuten den Zustand und startet höchstens einmal in zehn Minuten neu, aus Stunden werden so drei bis vier Minuten. Die Ursache beheben wir trotzdem, der Wächter kauft nur die Zeit bis dahin.

Ein Duplikat erkennt man sicher an der Prüfsumme des Inhalts, nicht am Dateinamen. Beim Aufräumen doppelt eingespielter Belege in Paperless fiel mein Skript, als der genaue Abgleich ins Leere lief, auf den Titel zurück und löschte vier echte Rechnungen über einen Fahrzeugverkauf. Zurückgeholt habe ich sie aus dem Papierkorb, der 613 Einträge lang war. Seitdem vergleicht es nur noch über die Prüfsumme, und fehlt die, hält es an, statt zu raten. Zwei Namen ähneln sich leicht, zwei Inhalte nie.

Der Fehlerliste einer Automatik kann man nicht blind glauben, weder bei dem was fehlt noch bei dem was ankam. Nach einem Serverausfall lagen rund 235 Tresen-Belege eines ganzen Arbeitstags im Ordner für Fehlversuche, im Paperless-Archiv fehlten sie tatsächlich. Neun weitere Gruppen standen ebenfalls als Fehlversuch da und waren trotzdem doppelt angekommen. Erst der Abgleich Datei für Datei gegen das Zielsystem zeigte, was wirklich stimmt. Ein Programm weiß oft nur, ob es die Antwort gehört hat, nicht, ob die Arbeit getan wurde.

Ob eine Firewall wirklich dicht ist, prüft man von einem fremden Rechner aus, nicht aus dem eigenen Netz. Beim Absichern unseres neuen Hetzner-Servers zeigte mein Port-Scan hinter dem VPN einen offenen Port 80, der von außen gar nicht offen war. Erst die Prüfung von einem neutralen Host ergab das echte Bild: öffentlich erreichbar ist nur noch der Fernzugang. Eine Tür testet man von der Seite, von der ein Einbrecher kommen würde.

Ein überlasteter Server braucht nicht automatisch mehr Rechenleistung, oft fehlt nur Arbeitsspeicher. Unser cpx42 bei Hetzner lahmte, doch die CPU lag zu 62 Prozent im Leerlauf, während 4,3 Gigabyte in den langsamen Swap ausgelagert waren. Ein größerer Cloud-Server hätte teure Rechenkerne mitbezahlt, die wir nie gebraucht hätten, also nahmen wir stattdessen eine gebrauchte Maschine mit 256 Gigabyte RAM. Wer erst nachmisst, welcher Teil wirklich klemmt, kauft nicht den falschen Motor für ein Getriebeproblem.

Ein Fehler schlägt erst zu, wenn die Notkorrektur ausfällt, weil sie ihn vorher nur übertüncht hat. In unserem Dokumentenarchiv, Paperless, setzte eine vergessene Automatik jedem neuen Beleg einen Besitzer, und ein zweiter Schritt nahm ihn Sekunden später wieder weg. In jedem Test sah alles sauber aus. Erst als dieser Schritt an einem Ausfall scheiterte, blieben 208 Belege unsichtbar. Heute räumt das System den Besitzer selbst weg, ausfallsicher an der Quelle. Eine Abhilfe, die den Fehler ständig übermalt, ist kein Fix, sie verschiebt nur den Tag, an dem er auffliegt.