
Patchorgie bis zum Morgengrauen: Wie Dogiwood beinahe am eigenen Ehrgeiz erstickt ist
Eigentlich sollte es nur eine technische Endkontrolle werden. Stattdessen wurden 17 Fehler, ein beleidigtes Radio, falsche Statusmeldungen und ein ganzes Rudel Systeme bis tief in die Nacht repariert.
Es gibt Tage, da öffnet man morgens den Rechner und denkt: Heute machen wir nur noch ein bisschen Feintuning.
Und dann ist plötzlich Nacht. Sehr tiefe Nacht. Die Sorte Nacht, in der normale Menschen schlafen, Katzen auf Fensterbänken sitzen und irgendwo auf einem Server ein PHP-Skript leise vor sich hinflüstert: Bitte patch mich nicht noch einmal.
Willkommen bei Dogiwood.
Eigentlich stand nur eine technische Endkontrolle auf dem Plan. Astra sollte einmal durch den aktuellen Stand laufen, sechs Tage Entwicklung prüfen, den Bericht ausspucken und vielleicht noch zwei Kleinigkeiten an Dogiwood Control reparieren. Danach hätte man den imaginären Stempel FERTIG auf das Projekt drücken können.
Astra kam zurück.
Mit 17 bestätigten technischen Fehlern. Vier davon trugen den besonders freundlichen Hinweis: Freeze-Blocker.
Danke auch.
Damit begann die große Dogiwood-Patchorgie 2026. Was folgte, hatte mit gemütlichem Feintuning ungefähr so viel zu tun wie eine digitale Notaufnahme mit Wellness. Einer nach dem anderen wurden die Patienten hereingeschoben: C.O.C.O.-Authentifizierung, Rollback-System, DogiFY, Stundennachrichten, Begleiterlogik, Premium-Sprachnachrichten, Blog-Videoframes, Adventure-Gesundheitssystem und schließlich sogar die Backup-Ampel.
Bei DogiFY stellte sich zunächst heraus, dass die Nachrichten mit 1,5-facher Geschwindigkeit vorgelesen wurden. Vermutlich wollte der Nachrichtensprecher einfach früher Feierabend machen. Also zurück auf 100 Prozent.
Danach fiel auf, dass bereits verwendete Nachrichten problemlos noch einmal abgespielt werden konnten. Radio DogiFY hätte damit jederzeit verkünden können: Und nun die Nachrichten von gestern. Noch einmal. Weil sie so schön waren.
Also bekam jede verwendete Nachricht ihre eigene kleine Sperre.
Anschließend zeigte sich, dass eine einzige kaputte Stundenansage theoretisch den Rest des Tages lahmlegen konnte. Wenn die Ansage um 05 Uhr ausfiel, gab es eben auch keine 06 Uhr, keine 07 Uhr und keine Nachrichten. Feierabend.
Auch das wurde repariert.
Besonders freundlich war der Ausflug ins Adventure-Gesundheitssystem. Dort gibt es einen Vertrauenswert namens medical_trust. Der darf niemals kleiner als null werden. Der Code rechnete trotzdem sinngemäß: 0 minus 1, aber bitte mindestens 0.
MySQL antwortete darauf ungefähr: Du möchtest also eine negative Zahl in einer UNSIGNED-Spalte berechnen? Interessant. Nein.
Der Charakter stirbt bei Dogiwood natürlich nicht. Nur das Skript.
Auch das lebt jetzt wieder.
Dann kam das Radio an die Reihe. Im Browser lief der Stream wunderbar durch. Das Küchenradio dagegen spielte ein paar Minuten, brach ab und begrüßte den Hörer anschließend wieder fröhlich mit dem Start-Jingle. Immer wieder.
Unser eigener Stream hatte beschlossen, sich alle 270 Sekunden selbst zu erschießen. Ursprünglich aus Vorsicht vor einem vermuteten Hosting-Limit. Astra stellte trocken fest: nicht belegt.
Also flog die künstliche Trennung wieder raus. Der Browser hatte die Angelegenheit übrigens längst elegant überspielt und automatisch reconnectet. Er wusste offenbar mehr über DogiFY als wir.
Danach meldete der neue Statusmonitor, dass die Stundennachrichten kaputt seien.
Waren sie nicht.
Unser Statusmonitor las einfach die falschen Feldnamen. Ein wunderschöner Moment: Wir hatten einen Fehlerchecker gebaut, der zuverlässig einen Fehler meldete. Leider seinen eigenen.
Patch drauf. Weiter.
Dann kam die Backup-Ampel. Heute Morgen noch grün, abends plötzlich rot.
Panik?
Nein. Die alte Prüfung hatte einfach jedes halbwegs frische Backup-Verzeichnis als erfolgreiches Nachtbackup betrachtet. Patchbackup? Grün. Rollbackbackup? Grün. Irgendwas mit .sql.gz? Herzlichen Glückwunsch, Dogiwood ist sicher.
Nach der Reparatur stellte sich heraus, dass unser angebliches Nachtbackup vermutlich gar kein Nachtbackup war.
Und dann fiel der Groschen: Die echten Backups macht Lima-City.
Natürlich.
Also API her, API-Key rein, HTTP 403. Neue Rechte vergeben. Jetzt antwortet Lima-City immerhin. Das Backup kommt dort normalerweise zwischen fünf und sechs Uhr. Ich werde das selbstverständlich gegen zehn Uhr überprüfen. Vorher bekommt mich sowieso niemand aus dem Bett.
Währenddessen meldete sich auch STRATO auf dem Konto: Der neue Rootserver ist bestellt. Intel Xeon, 32 GB ECC RAM, SSD RAID 1. Dogiwood bekommt also bald seinen eigenen kleinen Maschinenraum.
Die Aufgabenverteilung steht bereits fest: DogiFY sendet. METAna sitzt im Keller und macht die Drecksarbeit. DWC spielt Plesk. C.O.C.O. kontrolliert alles.
METAna bekommt selbstverständlich keinen öffentlichen Zugang. Das Lama wird komplett abgeschottet. Nur DWC darf mit ihm reden. Quasi ein Hochsicherheitstrakt mit Sprachmodell.
Und weil normale Menschen an dieser Stelle vermutlich gesagt hätten: Das reicht jetzt, kam natürlich noch eine weitere Idee dazu: ein eigenes Terminal direkt im DWC.
Über API. Mit Serververwaltung, Firewall, Diensten, Logs, Radio, Ollama und später vielleicht Dogiwood TV. Also praktisch ein eigenes Plesk. Nur mit mehr Hunden und wahrscheinlich weniger Ruhe.
Am Ende dieser Nacht bleibt eine wichtige Erkenntnis: Dogiwood hat kein Milliardenbudget. Dogiwood hat ein Milliardenbudget an Ideen.
Irgendwo zwischen Patch 327, 434, 454, 466, 581, 605, 624, 632, 636, 640, 642 und 643 saßen wir schließlich da und stellten fest, dass wir eigentlich nur kurz nach Fehlern schauen wollten.
Nun ja.
Dogiwood eben.
Hollywood hat Serverfarmen. Wir haben einen Shared Hoster, einen kommenden Rootserver, ein Llama im Keller und eine C.O.C.O., die nachts um drei noch Statusampeln kontrolliert.
Und irgendwie funktioniert es.
Meistens.
Bis zum nächsten Patch. 😄
Kommentare
Noch keine freigegebenen Kommentare.