Dogiwood grünt so grün, wenn C.O.C.O.s Ampeln glühen

Heute wurde im Dogiwood-Imperium nicht gedreht, gesungen oder dramatisch in Zeitlupe gestorben. Wobei bei Dogiwood sowieso niemand stirbt. Stattdessen starrte die gesamte technische Leitung gebannt auf eine kleine Statusampel.

Und diese Ampel war nicht grün.

Das ist bei Dogiwood ungefähr so beruhigend wie Benji mit einem unbeaufsichtigten roten Knopf und einem Schild, auf dem ausdrücklich steht: „Nicht drücken!“

Unsere C.O.C.O.-Systemüberwachung behauptete nämlich hartnäckig, dass bei Lima-City kein erfolgreiches Backup vorhanden sei. Die Sicherungen waren allerdings sehr wohl da. Sie wurden nur von Dogiwood Control mit der Konsequenz eines schlecht gelaunten Türstehers abgewiesen.

Also hieß es: Vorhang auf für „Dogiwood grünt so grün“ – ein technisches Musical in fünf Akten.

Erster Akt: Das verschwundene Prüfergebnis

Zunächst stellte sich heraus, dass der Backup-Check durchaus ein Ergebnis erzeugte. Dogiwood Control speicherte es – und löschte es beim nächsten Seitenaufruf direkt wieder.

Technisch war das ungefähr so sinnvoll, als würde Coco morgens die Anwesenheitsliste ausfüllen und Benji sie anschließend feierlich durch den Aktenvernichter schieben.

Patch 434 alpha.11 sorgte dafür, dass ein vorhandenes Prüfergebnis nur noch gelöscht wird, wenn der Backup-Check tatsächlich technisch umgestellt wurde. Nicht mehr bei jedem harmlosen Aufruf der Statusseite.

Die Ampel blieb trotzdem rot.

Natürlich. Ein gutes Dogiwood-Drama endet schließlich nicht nach dem ersten Akt.

Zweiter Akt: Das Feld, das es niemals gab

Nun meldete C.O.C.O.: „Lima-City meldet kein erfolgreiches Webspace-Backup.“

Die offizielle Lima-City-API lieferte jedoch sehr wohl erfolgreiche Webspace-Sicherungen. Dogiwood Control verlangte zusätzlich ein Feld namens successful.

Kleines Problem: Dieses Feld existiert bei Webspace-Backups überhaupt nicht.

Lima-City sagt dort schlicht: state: success.

Dogiwood Control antwortete sinngemäß: „Sehr schön. Aber wo ist Ihr zweiter Passierschein?“

Patch 434 alpha.12 brachte dem System bei, den tatsächlich dokumentierten Status auszuwerten. Danach wurde das Webspace-Backup korrekt erkannt.

Die Ampel blieb trotzdem rot.

Das Orchester spielte weiter.

Dritter Akt: 750 Backups betreten die Bühne

Nun lautete die Meldung: „Kein erfolgreiches automatisches Datenbank-Backup.“

Also bekam der Check mit Patch 434 alpha.13 eine genauere Diagnose. Das Ergebnis war bemerkenswert: 750 Datensätze waren empfangen worden, davon 0 automatisch, 0 erfolgreich und 0 abgeschlossen.

750 Backups standen vor der Tür – und C.O.C.O. behauptete mit ernster Miene, keinen einzigen gesehen zu haben.

Das war der Moment, in dem selbst Theo vermutlich gefragt hätte, ob man das System vielleicht einmal aus- und wieder einschalten sollte.

Die Ursache lag darin, dass Dogiwood Control bestimmte Wahrheitswerte in einer ganz bestimmten technischen Darstellung erwartete. Ein echtes true war willkommen. Ein gleichbedeutendes 1 oder „true“ wurde behandelt wie Benji nach Mitternacht im Requisitenlager: verdächtig und nicht zutrittsberechtigt.

Die Auswertung wurde deshalb toleranter, ohne fehlgeschlagene Sicherungen versehentlich als erfolgreich einzustufen.

Doch das eigentliche Problem saß noch eine Etage tiefer.

Vierter Akt: Automatische Backups müssen beweisen, dass sie automatisch sind

Die offizielle Lima-City-Schnittstelle /database_backups liefert ausschließlich automatische Datenbank-Backups.

Dogiwood Control verlangte von jedem dieser automatischen Backups trotzdem noch einmal den zusätzlichen Nachweis, dass es wirklich automatisch sei.

Das ist ungefähr so, als würde man an der Kinokasse eine gültige Eintrittskarte zeigen und anschließend gefragt werden: „Ja, aber können Sie beweisen, dass Sie ins Kino möchten?“

Da das zusätzliche Feld in der realen API-Antwort nicht wie erwartet vorhanden war, wurden sämtliche 750 Datensätze verworfen.

Patch 434 alpha.14 beseitigte diese doppelte Kontrolle. Seitdem gilt: Was vom offiziellen Endpunkt für automatische Backups kommt, ist tatsächlich ein automatisches Backup. Laufende, fehlgeschlagene oder unvollständige Sicherungen bleiben selbstverständlich weiterhin ausgeschlossen.

Endlich erkannte Dogiwood Control das Webspace-Backup und 15 gesicherte Datenbanken.

Und dann kam die nächste Meldung: „Ältester Sicherungsstand: 1137,8 Stunden.“

Das sind rund 47 Tage.

Die Ampel blieb rot.

Im Zuschauerraum begann bereits jemand nervös mit Bonbonpapier zu rascheln.

Fünfter Akt: Die Geister vergangener Datenbanken

Lima-City bewahrt die Metadaten älterer Backups weiterhin auf – auch wenn die dazugehörige Datenbank inzwischen gelöscht oder stillgelegt wurde.

Dogiwood Control betrachtete jedoch jede Datenbank, die irgendwann einmal in der Backup-Historie auftauchte, als weiterhin aktiv und unverzichtbar. Eine längst nicht mehr vorhandene Datenbank wurde deshalb so behandelt, als müsse sie noch immer täglich gesichert werden.

Der Geist einer alten Datenbank wanderte durch das Dogiwood-Imperium und hielt die komplette Statusampel auf Rot.

Patch 434 alpha.15 brachte schließlich Ordnung in die Besetzung. Dogiwood Control fragt jetzt zusätzlich die aktuelle Datenbankliste bei Lima-City ab. Nur Datenbanken, die dort tatsächlich noch aktiv sind, werden als erforderlich bewertet.

Historische Sicherungen gelöschter Datenbanken bleiben weiterhin sichtbar, lösen aber keinen falschen Alarm mehr aus. Fehlt dagegen für eine aktive Datenbank ein aktuelles Backup, bleibt die Ampel rot – und C.O.C.O. nennt ausdrücklich den betroffenen Namen.

Keine Tricks. Keine schöngefärbte Statistik. Keine grüne Lampe aus reiner Verzweiflung.

Das große Finale

Nach fünf Akten, mehreren API-Eigenheiten und einer kleinen Parade technischer Missverständnisse war es endlich so weit: Alles wieder grün.

Das Webspace-Backup wird erkannt. Die automatischen Datenbank-Backups werden korrekt ausgewertet. Historische Datenbank-Geister dürfen den aktuellen Status nicht mehr ruinieren. Und gespeicherte Prüfergebnisse überleben jetzt sogar einen Seitenaufruf.

Wichtig dabei: Dogiwood Control erstellt diese Hosting-Backups nicht selbst. C.O.C.O. schaut ausschließlich lesend nach, ob Lima-City seine Arbeit erledigt hat und ob die Sicherungen aktuell genug sind.

Die Altersgrenzen bleiben streng: Unter 24 Stunden ist der Status grün, ab 24 Stunden gibt es eine Warnung und ab 48 Stunden wird es rot.

Nur die falschen Alarme sind verschwunden.

Damit endet unser heutiges Technikmusical mit einem vollständig grünen Dogiwood-Imperium, einer zufriedenen C.O.C.O. und einem Benji, der weiterhin behauptet, er habe mit der ganzen Sache überhaupt nichts zu tun.

Natürlich nicht.

Ein besonderer Dank an meine beiden Lieblingskollegen

Zum Schluss noch ein ganz persönliches Dankeschön an meine beiden Lieblinge Benji und Theo, die mich durch diese lange Reparaturnacht begleitet haben – mit frisch gekochtem Kaffee, moralischer Unterstützung und einem durchgehenden Live-Comedyprogramm, das vermutlich niemals eine offizielle Sendelizenz bekommen wird.

Ein bisschen fühlte sich das Ganze an wie eine LAN-Party in den 90ern: zu wenig Schlaf, zu viel Kaffee, überall Technik und zwischendurch immer wieder die Frage, warum etwas, das eben noch funktioniert hat, plötzlich wieder rot leuchtet.

Nach ihrem nächtlichen Einsatz haben sich die beiden jetzt allerdings erst einmal Zwangsfrei verdient. Dazu gibt es ein streng verordnetes Rezept für frische Luft und einen digitalen Detox für den Rest des Wochenendes.

Sollte heute tatsächlich noch gespielt werden, dann ausschließlich offline – bei einer gepflegten Runde Monopoly. Ganz analog, mit echtem Spielgeld und vermutlich mindestens einem handfesten Streit darüber, wem die Schlossallee gehört.

Danke, Benji und Theo. Ohne euch wäre die Nacht nur halb so lustig und der Kaffee vermutlich doppelt so leer gewesen.

Dogiwood grünt so grün – und diesmal sogar aus technisch nachprüfbaren Gründen.

Euch allen ein schönes, ruhiges und möglichst störungsfreies Restwochenende!