Zuletzt habe ich mit einem Nicht-IT-Problem gekämpft, das mir mal wieder eine wichtige Regel für Software-Architekturen vor Augen geführt hat:

Bei meinem täglichen Prozess „Anziehen“ gibt es einen kleinen Teilschritt „Socken bereitstellen“, der überpropotional viel Performance zog. Dieser Prozess muss im Dunkeln ablaufen, damit ich meine Frau nicht wecke. Er ist schon teilweise optimiert, z.B: habe ich nur dunkle Socken einer Dicke in meinem Socken-Pool, so dass ein Random-Zugriff ausreicht, um ein passendes Paar herauszuziehen.

Dieser Prozess wird aber dadurch gestört, dass sich im Socken-Pool über die Zeit immer mehr Einzelsocken sammeln, und ich (gerade wenn sich die Anzahl gematchter Sockenpaare kurz vorm nächsten Waschgang senkt) mehrere Zugriffe brauche bis ich ein Paar erwische.

Es gab zwar regelmäßige Housekeeping-Jobs, in denen ich zusammengehörende Einzelsocken wieder gematcht habe, dieser lief aber sehr unregelmäßig und wurde erschwert, da die Socken unterschiedlich schnell verblasten und so das Matching erschwerten. Er führte nie dazu, dass der Pool frei von Einzelsocken war. Einen Prozess zum endgültigen Entfernen von Einzelsocken gab es nicht, da ich keine Statistiken darüber führen konnte wie lange eine bestimmte Einzelsocke schon im Pool lag.

Diesen unbefriedigenden Zustand versuchte ich an der Wurzel zu packen, indem ich den Matching-Prozess diekte nach dem Waschgang verbessern wollte. Lösungsversuche sahen hierzu wie folgt aus:

  • Kauf von unterschiedlich gemusterten Socken, um das Matching zu erleichtern
  • Socken im Wäschesack waschen
  • Verwenden von Snap-Socks (diese kann man vor der Wäsche mit einem Durckknopf verbinden)

Aus verschiedenen Gründen sind alle diese Versuche gescheitert. Zuletzt habe ich die Strategie gewechselt und einfach akzeptiert, dass Einzelsocken aus der Waschmaschine kommen können. Dann habe ich einen Prozess etabliert, der besser mit dieser Situation umgehen kann: In einem dedizierten Filter-Schritt werden alle Einzelsocken herausgefiltert bevor sie in den Socken-Pool gehen und in einem eigenen Einzelsocken-Pool abgelegt.

Der Einzelsocken-Pool ist eine selbstentwickelte Custom-Lösung. Dabei handelt es sich um eine familien-übergreifende Instanz. Hier eine Abbildung der Komponente:

socken-tool

Mit diesem System gehören die Matching-Probleme nun endlich der Vergangenheit an.

Fazit
Nachdem ich sehr viel Geld und Aufwand investiert habe, um das Auftreten von Match-Fails nach einem Waschgang zu vermeiden, habe ich das Problem letztlich gelöst, indem ich akzeptiert habe, dass diese einfach auftreten und mit diesem Umstand umgehe.

Die Analogie in die IT ist vermutlich augenfällig: Kein System ist 100% verfügbar; Keine Schnittstelle bekommt 100% richtige oder auch nur syntaktisch korrekte Daten; Nicht alle User verhalten sich unseren Erwartungen konform. Der Fehler ist die Regel. Design for the failure!

Eigentlich keine neue Erkenntnis, aber man muss diese immer mal wieder auffrischen. Gerade in Zeiten von Cloud-Diensten und Microservices wird es immer wichtiger, dass eine Applikation nicht komplett ausfällt, nur weil ein kleiner Peripher-Dienst nicht verfügbar ist.

P.S. Nachdem das System nun schon 2 Monate in Produktion ist, glaube ich ein uraltes Rätsel der Menschheit gelöst zu haben: Die Waschmaschine lässt keine Einzelsocken verschwinden: Früher oder später finden sich die Paare im Einzelsocken-Pool wieder.

Advertisements