Tipp KW 5 – 2023

CRAZY MONKEY – in Ihrer neuen Systemumgebung wird es jetzt ganz verrückt

Ich möchte Ihnen heute aus einem meiner aktuellen Projekte berichten, bei dem ich innerhalb eines Kundenprojektes die Einführung einer neuen Omni-Channel-Anlage begleitet habe.

Bei der Implementierung von neuen TK/ACD oder Omni-Channel-Systemen macht man sich im Vorfeld viele Gedanken u.a. über die Ausfallsicherheit, und plant gegebenenfalls die Architektur entsprechend den erwarteten Vorgaben. Dies ist besonders wichtig, um die gesetzten Service-Level-Agreements (SLAs) einhalten zu können, die sie als Kunde mit Ihrem Anbieter der neuen Lösung vereinbaren. Dabei treten verschiedene relevante Fragen auf, beispielsweise „Sollen System-Komponenten doppelt ausgelegt sein?“ oder „Wie ist hier die richtige Strategie in der Arbeitsweise dieser Maschinen und welche gibt es?“  

Dazu möchte ich Ihnen einige der wichtigsten Verfahren näherbringen:

• Aktiv-Aktiv-Betrieb:  Hierfür sind für einen duplizierten Betrieb mehrerer Server notwendig, bei dem im Ausfall eines Servers einer der anderen Server direkt übernehmen kann und der Betrieb nahezu unterbrechungsfrei weitergeführt werden kann
• Aktiv-Passiv-Betrieb:  Diese Variante stellt zwar eine Ausfallsicherheit dar, hat aber zur Folge, dass beim Ausfall des aktiven Servers eine Zeit notwendig ist, die den passiven Server befähigt, aktiviert zu werden, um dann alle Dienste zu übernehmen.
• Stand-Alone-Server oder Datenbank: Hier handelt es sich um Server, die entweder die Steuerung oder diverse Spezial-Aufgaben erledigen sollen. Beim Ausfall eines solchen Servers fallen alle Dienste aus, die durch ihn betrieben wurden. Eine Wiederaufnahme des störungsfreien Betriebes kann in der Regel nur durch Recovery-Maßnahmen erfolgen, indem dieser Server eine Neuinstallation durch Einspielung eines Backups erfährt.
• 3rd-Party-Systeme: Auch über Schnittstellen angebundene Dritt-Systeme können bei einem Ausfall Auswirkungen auf den Gesamtbetrieb haben. Dies ist besonders bei Systemen zu beachten, die ein zentrales Frontend für den Mitarbeiter bereithalten. Z.B. bei der Entscheidung, ein CRM-System mit einer ACD-Umgebung zu verschmelzen, um somit auf einem gemeinsamen Frontend die Telefon- und sonstigen Kontaktkanäle steuern zu können. 

Die Hersteller und auch Dienstleister zeigen im Normalfall je nach gewählter Architektur die resultierende Ausfallsicherheit auf und sorgen im Störungsfall für eine Einhaltung der vereinbarten SLAs. Das wird zugesichert.

Genau hier stelle ich Ihnen aber die Frage: Stimmt das wirklich so? Passiert genau das, wie vermutet? Ist alles so rosarot wie versprochen, oder wie sieht der Worst Case aus? Oder auch: 

Warum CRAZY-MONKEY?

Sobald die Komponenten im Rechenzentrum aufgebaut und für die ersten Tests zur Verfügung stehen, empfiehlt es sich, einen intensiven Fail-Over-Test durchzuführen. Das haben wir also auch im erwähnten aktuellen Kundenprojekt durchgeführt. Alle nur denkbaren Ausfall-Szenarien wurden niedergeschrieben und als Testdokument zusammengefasst. Ein Test-Team wurde gebildet, in dem jeweils Dienstleister aller Systeme, Verantwortliche aus der lokalen IT, des Rechenzentrums sowie System-Tester vertreten waren.

Ich nenne das gerne den Crazy-Monkey-Test, da das Vorgehen wie durch einen „Verrückten Affen“ beschrieben werden kann. Im vollen Betrieb werden nach und nach einzeln oder mehrfach die verschiedensten Server abgeschaltet, und die Tester protokollieren jede Art der Betriebs-Veränderung des Gesamtsystems. Hierbei können die Ergebnisse von „merken wir kaum“ bis zu „es geht nichts mehr“ variieren. Sie würden staunen, wie vielfältig die Testergebnisse aussehen können.

Unsere gewonnenen Erkenntnisse waren z. B.:

• Laufende Gespräche blieben erhalten und brachen nicht ab, obwohl der Hersteller dies nicht garantiert, und einen Abbruch prognostiziert hatte.
• Umschaltzeiten waren länger als durch den Hersteller garantiert
• Viele andere wertvolle Erkenntnisse mehr

Aber auch Erkenntnisse wie „Ja, wie melde ich mich denn jetzt an?“ oder „Greifen die administrierten Notfall-Routings und wo kommen die Gespräche jetzt eigentlich an?“ werden gewonnen. Oft fehlt auch hier der ein oder andere beschrieben Prozess für eine Bedienung im Fehlerfall. 

Ist die Durchführung nicht sehr aufwändig?

Gerade in der heutigen Zeit, in der viele Installationen in einer VM-Umgebung gebaut werden, ist es einfach, einen virtuellen Server mit einem Mausklick abzuschalten und danach wiederzubeleben. Für den hier erwähnten Crazy-Monkey-Test benötigt man dann nur ca. zwei Stunden. Gut investierte Zeit, denn: Sind Sie erst einmal im Live-Betrieb und Ihre Mitarbeiter arbeiten auf dem neuen System, werden Sie kaum Gelegenheit haben, so einen Fail-Over-Test durchzuführen. 

Fazit

Die Durchführung eines Crazy-Monkey-Tests vor der Inbetriebnahme einer neuen Systemumgebung kann ich jedem ganz besonders ans Herz legen. Für einen überschaubaren Aufwand erhält man sehr wichtige Kenntnisse über das mögliche Verhalten bei Ausfällen und beugt somit unerwarteten Ausfall-Szenarien und den damit entstehenden Kosten vor.

Udo Ociepka – Senior Consultant 

junokai