Journal.

Wenn eine gemeinsam genutzte Ressource ausgeht, trifft es nicht den Verursacher, sondern den, der zufällig zuletzt kommt. An einem Dienstag wurden 66 Anmeldungen über Authentik abgewiesen, weil unsere Datenbank keine freie Verbindung mehr hatte, während die eigentlichen Dauerverbraucher ungestört weiterliefen. Authentik ist bei uns die Anmeldung für fast alles, also stand plötzlich überall die Tür zu. Wer die Ursache am lautesten Symptom sucht, verdächtigt meistens den Falschen.

Ein stärkerer Server hilft nicht, wenn der angebundene Speicher der Flaschenhals ist. Bei unserer Nextcloud habe ich erst gemessen, bevor ich über neue Hardware nachdachte: 8,4 Megabyte pro Sekunde beim Schreiben in den Objektspeicher, 67 beim Lesen, während das Netz selbst in unter einer Millisekunde antwortete. Die Maschine hatte nie Not, die Leitung dahinter schon. Bevor man aufrüstet, misst man, wo die Zeit wirklich verlorengeht.

Große Uploads brechen nach genau einer Minute ab, weil dort ein Zeitlimit sitzt und kein Zufall waltet. Bei uns endete jede Übertragung über zweihundert Megabyte mit einem Fehler, immer nach 60,1 Sekunden. Der Verdacht lag zuerst beim Programm auf dem Rechner, tatsächlich hatte unser Proxy Traefik in der neuen Version ein Werksmaß von sechzig Sekunden mitgebracht. Eine Störung, die auf die Zehntelsekunde wiederkehrt, kommt nicht von der Leitung, sondern aus einer Einstellung.

Ein Versionssprung ändert nicht nur Funktionen, sondern auch Voreinstellungen, die es vorher gar nicht gab. Unser Proxy Traefik kannte in Version zwei keine Zeitgrenze für eingehende Übertragungen, Version drei bringt sechzig Sekunden ab Werk mit, und das galt schlagartig für alle Dienste dahinter: Dokumentenablage, Projektverwaltung, Dateiserver. Aufgefallen ist es nur an einer einzigen Stelle. Nach einem Update lohnt der Blick auf das, was der Hersteller jetzt anders für richtig hält.

Für den Dauerbetrieb reicht die Werkseinstellung einer Datenbank nicht, sie ist für den kleinsten denkbaren Fall gemacht. Unser PostgreSQL lief mit hundert erlaubten Verbindungen und 128 Megabyte Puffer bei knapp vier Gigabyte Arbeitsspeicher im Server, und seit Mai wurden über zwölftausend Verbindungen abgewiesen. Nach dem Anheben auf zweihundert fiel die Auslastung von achtzig auf vierunddreißig Prozent, bei 0,85 Sekunden Ausfall. Eine Werkseinstellung ist eine Startposition, kein Betriebszustand.

Eine Werkseinstellung kann eine Funktion tatsächlich von Anfang an unmöglich machen. Unsere Nextcloud lief über ein Jahr mit einem Zeitlimit von fünfzehn Sekunden für den angebundenen Objektspeicher, während ein einzelner Datenblock bei gemessenem Durchsatz neunundfünfzig Sekunden gebraucht hätte. Jeder größere Upload musste also scheitern, ganz ohne Defekt. Werkseinstellungen sind eine Annahme des Herstellers über einen Betrieb, den er nicht kennt.

Beim Umzug einer Website kommt erst das Zertifikat, dann die DNS-Umstellung. Wir ziehen zwei unserer Domains auf einen neuen Reverse Proxy, und in der umgekehrten Reihenfolge entsteht ein Zeitfenster, in dem Besucher auf einem Server landen, der für diese Adresse noch gar kein gültiges Zertifikat hat: Warnseite im Browser, mitten am Werktag. Also erst den Traefik-Router scharf schalten, dann den Wegweiser umstellen. Man baut die Brücke fertig, bevor man den Verkehr darüberschickt.

Ein Diagnose-Schalter, den man nach der Reparatur anlässt, wird irgendwann selbst zum Fehler. Auf einem unserer WordPress-Server stand die ausführliche Fehlerprotokollierung seit Monaten auf an, im Produktivbetrieb. Die Protokolldatei war auf 1,96 Gigabyte gewachsen und der Datenträger zu sechsundachtzig Prozent voll. Bevor ich sie geleert habe, habe ich ihr Ende gelesen, denn genau dort stand die Ursache des Ausfalls. Was man zum Suchen anschaltet, gehört nach dem Finden wieder ausgeschaltet.

Umbauen muss man ein Programm dafür nicht, wenn die Entscheidung in der Konfiguration steht und nicht im Code. Unsere Achsvermessung schickt jedes Messprotokoll automatisch per Mail und druckte es zusätzlich in der Werkstatt aus. Diese Woche habe ich den Ausdruck abgeschaltet und den Verteiler verkleinert, dafür reichten zwei Werte in einer Einstellungsdatei und eine Sicherung davon. Der nächste Wagen lief sauber durch: keine Seite gedruckt, Mail zugestellt. Was sich im Betrieb ändern kann, gehört dorthin, wo man es ohne Programmierer ändert.

Eine Login-Sperre schützt nur den Weg, für den sie geschrieben wurde, die Hintertüren bleiben offen. Auf der Website eines Betriebs prasselten an einem Vormittag 1.426 Anfragen in achtundzwanzig Minuten auf eine Programmier-Schnittstelle ein, getarnt als Suchmaschinen-Crawler. Unsere Sperre mit fail2ban wachte am Anmeldeformular und ließ das alles ungebremst durch. Ich habe eine zweite Regel für diesen Weg gebaut und gegen das echte Protokoll geprüft, 1.453 Treffer, ausschließlich Angreifer. Ein Wachhund vor der einen Tür sagt nichts darüber, wie viele Türen das Haus hat.

Im Namen der eigenen Firma kann jeder Mails verschicken, und man merkt es nur, wenn man die Berichte dazu liest. Unser Mailserver, Stalwart, sammelt solche Meldungen seit März 2025 in einem Postfach, das ich bis heute nie geöffnet hatte: 517 Berichte über gut vierzehntausend Mails. Darin stand, dass im Mai ein fremder Anbieter drei Mails unter unserem Absender verschickt hat, abgewiesen allein deshalb, weil unsere Regel streng auf Ablehnung steht. Der Beweis lag über ein Jahr ungelesen im eigenen Haus.

Ein Protokoll, das jede Minute dieselbe Zeile schreibt, muss man ausdünnen, sonst versteckt es den einen Satz, der zählt. Die Protokolldatei unserer Achsmess-Automatik war auf 4,4 Megabyte und 34.616 Zeilen gewachsen, fast nur Meldungen, dass das Gerät gerade ausgeschaltet ist. Die Hälfte stand sogar doppelt drin, weil zwei Wege in dieselbe Datei schrieben. Jetzt rotiert die Datei täglich, wird nach vierzehn Tagen weggeworfen, und die Doppelung ist raus. Ein Protokoll nützt erst, wenn die Abweichung darin auffällt.

Wie oft eine Überwachung nachsehen muss, entscheidet sich daran, wann der Kunde die Störung merkt. Bei uns stand ein Monitor in Uptime Kuma auf dreihundert Sekunden, also fünf Minuten zwischen zwei Prüfungen. Jeder Ausfall, der kürzer war, blieb für das System unsichtbar, und ich habe die Störung vor dem Monitoring bemerkt. Seitdem laufen Kundenseiten auf sechzig Sekunden. Eine Überwachung, die langsamer schaut als der Kunde klickt, meldet nur noch, was ohnehin schon alle wissen.

Die Warnmails der eigenen Server landen in der Quarantäne, wenn sie ohne digitale Signatur verschickt werden. Aus den Berichten unseres Mailservers ging hervor, dass 125 von 222 Systemmails eines Verwaltungsrechners beim Empfänger aussortiert wurden, still, ohne dass bei mir eine Fehlermeldung ankam. Betroffen war genau der Kanal, über den sich abgelaufene Zertifikate und fehlgeschlagene Sicherungen melden. Eine Warnung, die niemanden erreicht, ist keine Warnung, sondern nur eine Zeile in einem Protokoll, das keiner liest.

Einen großen Datenbestand direkt von einer Cloud in die andere zu kopieren, geht selten gut. Ich habe knapp dreitausend Dateien in unsere Nextcloud geschoben, und nach 949 Dateien stand die Übertragung still, fünfundzwanzig Stunden lang, ohne eine einzige Fehlermeldung. Am Server lag es nicht: die Quelle musste jede Datei selbst erst aus ihrer eigenen Cloud holen und stieg dabei aus. Seitdem hole ich solche Bestände zuerst vollständig auf die Platte und schiebe sie dann in Häppchen weiter. Zwei Automatiken, die aufeinander warten, arbeiten nicht, sie stehen.

Im Ordner zu stehen heißt nicht, dass eine Datei wirklich auf dem Rechner liegt. Moderne Cloud-Ordner zeigen Platzhalter, die den vollen Namen und die volle Größe melden, obwohl lokal kein einziges Byte liegt. Bei unserem Nextcloud-Umzug habe ich das erst bemerkt, als ich statt der angezeigten Größe die tatsächlich belegten Blöcke abgefragt habe: ein großer Teil des Ordners war Fassade. Wer so einen Ordner sichert, sichert Namen, keine Daten.

Eine Erkennungsregel verschärft man, indem man die neue Fassung vorher gegen den kompletten Echtbestand laufen lässt. Unsere Dokumentenerkennung hielt jede siebzehnstellige Zeichenfolge für eine Fahrgestellnummer und las so eine Barcode-Nummer als Fahrzeug. Bevor ich die Regel um die Bedingung Buchstaben und Ziffern gemischt ergänzte, habe ich sie gegen 7.499 echte Fahrgestellnummern aus Loco-Soft geprüft, und keine einzige fiel heraus. Wer eine Regel nur am Fehlerfall testet, hat sie nur halb getestet.

Den ersten Treffer im Text soll eine Automatik nicht nehmen, sondern den besten. Unsere Dokumentenerkennung im Paperless hielt Modellbezeichnungen auf Rechnungen für ein Kennzeichen, brach danach ab und übersah das echte Kennzeichen weiter unten auf dem Blatt. In 388 von 17.076 Dokumenten ging so die Kundenzuordnung verloren. Jetzt hat der Fahrzeugbestand Vorrang vor dem ersten Fund, 1.449 falsche Treffer sind weg und kein einziges echtes Kennzeichen ist dabei verlorengegangen. Wer beim ersten Treffer aufhört, sucht nicht, er rät.

Ein Prüfbericht ordnet sich nie von selbst zu, wenn die Automatik die Fahrgestellnummer gar nicht als Suchmerkmal kennt. Unser Nacht-Job gleicht Belege gegen den Fahrzeugstamm aus Loco-Soft ab, las im Volltext aber nur Debitorennummer und Kennzeichen. Genau die fehlen auf Diagnoseprotokollen und Prüfberichten. Ein Fahrzeug lag drei Nächte unzugeordnet, obwohl seine Nummer zweimal auf dem Blatt stand. Seit die Fahrgestellnummer als dritter Anker gilt, lösen sich statt acht Dokumenten zweiunddreißig von allein auf. Was die Maschine nicht als Merkmal kennt, ist für sie nicht vorhanden.

Bei Elektroautos erkannte unsere Software das Kennzeichen nicht, weil das E am Ende abgesetzt steht und die Erkennungsregel es direkt an der Ziffer erwartete. Von 2.099 Kennzeichen, die unser Dokumentenarchiv keinem Fahrzeug zuordnen konnte, erklärten sich 1.245 allein dadurch. Im Stamm aus Loco-Soft tragen 521 von 6.860 Kennzeichen ein E für Elektro oder ein H für Oldtimer. Statt die Regel aufzuweichen, gleichen wir jetzt gegen den eigenen Bestand ab. Ein Sonderfall, der im eigenen Betrieb Alltag ist, ist kein Sonderfall mehr.