Uli Siebold, Leiter CurIX Entwicklung, im Interview

Uli Siebold, Leiter CurIX Entwicklung, im Interview
Uli Siebold, Leiter CurIX Entwicklung bei der IC information company

Von Helmuth Fuchs

Moneycab: Herr Siebold, Sie leiten das Team zur Entwicklung von CurIX (Cure Infrastructure in Xaas), einer Software, die helfen soll, Ausfälle von IT-Komponenten und Diensten zu verhindern. Wie genau soll das geschehen?

Uli Siebold: CurIX ist ein Produkt, das bestehende Monitoring-Werkzeuge um zusätzliche Funktionen zur Alarmierung und Ausfallprävention erweitert. CurIX identifiziert sehr früh mögliche Ausfälle aus einer Menge an Anomalien, die existierende Tools zwar finden, jedoch sind diese Meldungen oft mit Falschalarmraten behaftet. Weil CurIX so frühzeitig aktiv ist, bestehen bei einer Alarmierung noch viele Möglichkeiten für die Systemverantwortlichen, einen bevorstehenden Ausfall zu verhindern. Der Schlüssel liegt hier im rechtzeitigen Warnen und im Bereitstellen ausreichender Information, mit Hilfe derer schnell gehandelt werden kann.

«Wir können die gesamte Kette von Datensammlung, Anomalie-Erkennung, Fehlerprediktion und Fehlerlokation abdecken.» Uli Siebold, Leiter CurIX Entwicklung

Die Überwachung von Systemen mit Frühwarnfunktionen ist oft schon Bestandteil bestehender IT-Lösungen. Wie unterscheidet sich CurIX von diesen?

CurIX ist weit mehr als ein klassisches Monitoring Tool. CurIX versteht sich als Zusatz, der bestehende Monitoring Tools veredelt. Der wesentliche Unterschied, den CurIX damit erreicht, liegt im Aktivitätsniveau: Die uns bekannten Werkzeuge stellen automatisierte Auswertungen vorwiegend in den reaktiven Phasen bereit – das heisst, erst nachdem ein Ausfall geschehen ist. Mit CurIX ist es ein Leichtes, gängige Tools mit proaktiven Funktionen auszustatten. CurIX analysiert die vom Monitoring Tool gesammelten Daten und löst Alarme aus, wenn Ausfälle bevorstehen. Dies geschieht in einer für den Benutzer sehr einfach zu handhabenden Weise. Es ist nicht nötig – wie bei bisherigen Frühwarnsystemen – selbst dutzende Diagramme und Zeitreihen ständig zu beobachten und bei Auffälligkeiten den Alarmknopf zu drücken. Genau das übernimmt CurIX für den Systemverantwortlichen. Somit wird dieser entlastet und ein kontinuierlicher 24×7 Betrieb einfacher möglich. CurIX arbeitet also proaktiv.

Sie sehen CurIX als Zusatzmodul zu bestehenden System-Überwachungslösungen. Wie stellen Sie die Kompatibilität zu den bestehenden Systemen sicher, wie gross ist der Implementationsaufwand?

Für das Erreichen der Kompatibilität zu bestehenden Systemen nutzen wir zwei Ansätze: Auf technischer Seite entwickeln wir für bestehende Systeme Schnittstellenkomponenten. Wenn nötig entwickeln wir auch kundenspezifische Schnittstellen, die an bestehende Lösungen beim Kunden anknüpfen.

Auf der konzeptionellen Seite verfolgen wir den Ansatz sogenannter Key Performance Indikatoren (KPI). Diese KPIs lassen sich aus nahezu allen Rohdaten extrahieren und für viele Zwecke individuell erstellen. Meist liefern bestehende Überwachungslösungen bereits KPIs, oder man kann sie über Schnittstellen auslesen. Dieser Ansatz ist per Design so generisch, dass wir uns an jede Überwachungslösung anknüpfen können, die grundsätzlich erlaubt, Daten auszulesen. Wir haben in unseren Trainingsdatensätzen auch Daten anderer Domänen, beispielsweise von EKGs oder Flugzeugverspätungen, um die Flexibilität der Algorithmen schon während der Entwicklung sicherzustellen.

Im Gegensatz zu bekannten Lösungen, bei denen Schwellwerte eingestellt werden, deren Überschreitung dann zu einem Alarm führen, arbeiten Sie mit einer so genannten “Baseline”. Was ist der Unterschied, worin liegen die Vorteile?

Schwellwerte sind ein sehr robustes Mittel, um vor gefährlichen Zuständen gewarnt zu werden. Nicht ohne Grund werden sie vielerorts eingesetzt. Sie haben jedoch einige Grenzen, die wir mit CurIX überwinden. Zum Beispiel müssen Schwellwerte definiert werden, bevor sie zum Einsatz kommen. Hierbei können Fehler gemacht werden, die im schlimmsten Fall erst bemerkt werden, wenn sie gebraucht werden. Darüber hinaus erlaubt der Schwellwertbasierte Ansatz keine Zuordnung zum Fehlertyp.

«CurIX überwindet die Nachteile von Schwellwerten durch dynamische Anpassungen der Baselines mittels Datenanalyse und Deep Learning.»

Ein weiterer Grund für uns, mit Baselines zu arbeiten, ist die Sensitivität von Baselines. Lassen Sie mich anhand eines Beispiels erklären, worin die Stärken der Nutzung von Baselines liegen: Stellen Sie sich beispielsweise einen typischen Emailverkehr in einem Büro vor. Wenn wir nun überwachen möchten, ob der Mailverkehr beziehungsweise. die dazugehörige Infrastruktur zuverlässig ihren Dienst verrichtet, könnten wir prüfen, ob wir ständig eine gewisse Anzahl Emails pro Stunde verzeichnen. Um nicht ständig alarmiert zu werden, müssten wir dann einen Schwellwert auswählen, welcher der minimalen Last entspricht, die wahrscheinlich nur in der Nacht zu beobachten ist. Damit ist der Schwellwert nahezu nutzlos, denn wir möchten ja gerade tagsüber beobachten, ob alles in Ordnung ist. Folglich könnten wir den Schwellwert tagsüber anders wählen als nachts. Im Grunde macht eine Baseline genau das, nur werden die Schwellwerte dynamisch von CurIX automatisch ermittelt. Und damit kann CurIX Anomalien erkennen, die mit einfachen Schwellwerten nicht zu detektieren sind.

CurIX überwindet die Nachteile von Schwellwerten durch dynamische Anpassungen der Baselines mittels Datenanalyse und Deep Learning.

Ein wichtiger Aspekt bei der Auslegung von Systemen sind Saisonalitäten, wie zum Beispiel aktuell die Jahresabschlüsse, welche die Systeme besonders belasten. Wie gehen Sie damit um, welche speziellen Aspekte müssen berücksichtigt werden?

Der Umgang mit Saisonalitäten ist ein wichtiges Thema und bereits vom Markt in grossen Teilen gut adressiert worden. Hier gibt es kommerzielle sowie offene Lösungen, die sehr viele Fälle abdecken, beispielsweise können Zyklen mit einer Periodenlänge von 1 Woche automatisch erkannt und entsprechend für die Anomalienerkennung genutzt werden. Einige Kunden von uns arbeiten jedoch in einem Umfeld mit sehr speziellen saisonalen Schwankungen, die zwar in regelmässigen Abständen wiederkehren, jedoch keine Zyklen im strengen Sinne sind. Quartalsabschlüsse sind hier als Beispiel zu nennen. Der Quartalsabschluss fällt zwar meist auf festgelegte Tage im Quartal, jedoch treten diese nicht äquidistant auf, das heisst, mal sind es 90 Tage mal 92 Tage, die zwischen den Abschlusstätigkeiten liegen. Und genau damit haben verfügbare Lösungen Schwierigkeiten. Wir haben hierzu ein spezielles Konzept entwickelt, um typische nicht-äquidistante Zyklen verarbeiten zu können. Im Wesentlichen setzen wir auf etablierte Methoden, die unter anderen auch von Twitter genutzt werden, und erweitern diese um einige Funktionalitäten.

Die in Systemen exponentiell steigende Datenflut zum Beispiel durch das Internet der Dingen führt zu grösseren und komplexeren Datensystemen. Wie soll CurIX in solchen Umgebungen auch in Zukunft funktionieren?

Wir nutzen auch hier zwei Ansätze, um einer grossen Datenflut Herr zu werden: Der erste Ansatz ist die Nutzung von Key Performance Indikatoren. Diese sind sehr schlank, da sie jeweils nur einen Zahlenwert pro Zeitpunkt wiederspiegeln. Wir kommen also mit einer minimalen Datenmenge aus, was sich auf allen Ebenen positiv auf die Performance auswirkt, zum Beispiel benötigt CurIX vergleichsweise wenig Speicher, nur wenig Daten werden transferiert, die Daten sind per Design anonym und wir können die Zeitintervalle variabel einstellen, was die Datenmengen noch weiter reduzieren kann. Der zweite Ansatz nutzt Clustering, so lassen sich mehrere CurIX – Instanzen miteinander verbinden und sehr grosse Systemumgebungen bzw. sehr grosse Datenmengen mit mehreren Tausend Knoten durch CurIX überwachen. Im Hintergrund stehen hier Aggregationsansätze, die zu Anwendung kommen.

Wo stehen Sie aktuell in der Entwicklung von CurIX, was ist verfügbar, welche Funktionen werden als nächstes eingeplant?

Die Entwicklung des ersten Releases ist abgeschlossen. Wir können die gesamte Kette von Datensammlung, Anomalie-Erkennung, Fehlerprediktion und Fehlerlokation abdecken. Das Release 1.0 haben wir bereits in unserer SaaS – Umgebung im Einsatz.

«CurIX warnt aber nicht nur vor bevorstehenden Ausfällen, sondern informiert auch darüber wo die Ursache für den bevorstehenden Ausfall zu finden ist.»

Im nächsten Entwicklungsschritt werden Module von CurIX abgelöst werden, die noch Drittanbieter Software beinhalten. Damit gewinnen wir bzw. der Kunde deutlich mehr Konfigurationsmöglichkeiten. Ständig in der Entwicklungspipeline sind natürlich Schnittstellen zu bestehenden Monitoring-Werkzeugen. Mit dem danach anstehenden Entwicklungsschritt zielen wir darauf ab, verschiedene Anomalie-Detektoren an CurIX anzubinden. Denn wir beobachten immer mehr, dass Anomaliedetektion zum Standard bei Monitoring – Werkzeugen wird. Und wenn der Kunde eine eigene Anomaliedetektion mitbringen kann, soll er diese an CurIX anbinden können.

Wo liegt heute die Genauigkeit von Ausfall- und Fehler-Vorhersagen und was braucht es, damit diese noch präziser werden?

Genau in diesem Punkt liegt eine der Stärken von CurIX, mit denen wir bestehende Werkzeuge anreichern. Entscheidend für den Kunden sind aus unserer Sicht zwei Grössen: Die Sensitivität, also die richtig-Alarm Rate, bringt dem Kunden den entscheidenden Nutzen – nämlich alarmiert zu werden, wenn es notwendig ist. Und die Fehlalarmrate, die nicht zu hoch sein darf, denn Fehlalarme können teuer werden. Klassischerweise hängen beide Werte miteinander zusammen, das heisst, sobald Parameter geändert werden, welche die Sensitivität erhöhen, erhöht sich meist auch die Fehlalarmrate. Durch geschickte Wahl von Parametern können wir mit CurIX sehr geringe Fehlalarmraten von unter 5% erreichen. CurIX warnt aber nicht nur vor bevorstehenden Ausfällen, sondern informiert auch darüber wo die Ursache für den bevorstehenden Ausfall zu finden ist. Somit kann der Fehler behoben werden, bevor es zu einem Ausfall kommt. Hier ist es natürlich besonders wichtig, den richtigen Ort zu nennen. CurIX kann dem Anwender eine Kandidatenliste zur Verfügung stellen, in der mögliche Orte des Fehlers aufgeführt sind. Unsere Laborexperimente haben gezeigt, dass wir die Fehlerursache auf ca. 5 Komponenten mit einer Wahrscheinlichkeit über 90% einschränken können. Das heisst, ein Administrator kann seine Fehlerbehebung auf ein paar Komponenten konzentrieren und verliert keine Zeit mit aufwändiger Ursachenforschung.

Welche technologischen Entwicklungen werden aus Ihrer Sicht das Feld der proaktiven Warnsystemen wie CurIX in Zukunft prägen?

In dem Wort proaktiv steckt ja auch der Teil „aktiv“. Und bisher sind Warnsysteme auf ihre eigentliche Bezeichnung beschränkt: Das Warnen. Aktiv werden sie bisher selten. Aus meiner Sicht wird das Feld der proaktiven Warnsysteme in Zukunft dadurch geprägt, dass diese aktiver werden. Und zum Beispiel selbstständig Handlungen wie die Ausführung von Reparaturplänen in Auftrag geben können; erste Ansätze hierzu sind beispielsweise durch die Containertechnologie und Micro-Service Reboots schon zu beobachten. Der Begriff der Resilienz wird so zunehmend bedeutsamer, auch in der IT Landschaft. In Teilen der europäischen Forschung bezieht sich der Begriff der Resilienz meist auf sehr grosse Cyber-Physische Systeme, die sehr heterogen aufgestellt sind. Ich persönlich glaube, dass gerade in der Welt der IT, wo es unglaublich viele Ressourcen für künstliche Intelligenz und Machine Learning direkt in Reichweite gibt, das Konzept der Resilienz grosses Potential entwickeln wird. Hierzu gehören beispielsweise auch sich selbst reorganisierende Umgebungen. Und CurIX wird hier einen wesentlichen Teil beitragen.

Der Gesprächspartner:
Uli Siebold studierte Informatik an den Universitäten Karlsruhe und Freiburg. Sein Diplom erhielt er 2008 nach Abschluss seiner Diplomarbeit bei Fraunhofer zur Thematik Statistik und Zeitreihenanalyse sicherheitsrelevanter Daten. Seit Mai 2008 forschte er zur modellbasierten Sicherheitsanalyse in unterschiedlichen Themenfeldern, z.B. Flughafensicherheit, urbane Sicherheit, Krisenmanagement und Schutz kritischer Infrastrukturen. Seit 2017 leitet er in der IC Information Company AG das Softwareentwicklungs-Team. Zur Entwicklung von CurIX trägt er vor allem mit dem Design der Systemarchitektur, Zeitreihenanalysen und seiner grossen Erfahrung in der Bearbeitung mehrjähriger Forschungs- und Softwareentwicklungsprojekte bei. Seine Vision mit CurIX ist mittels exakten Fehlervorhersagen die Verfügbarkeit von IT Umgebungen (Cloud und OnPremise) zu erhöhen und die Betriebskosten zu senken.

Das Unternehmen:
Die IC information company AG (IC) ist ein in der Schweiz ansässiges Technologieunternehmen. Schwerpunkte der internationalen Geschäftstätigkeiten liegen in der Entwicklung und dem Betrieb von Software und Cloud Lösungen. Nebst Eigenentwicklungen stellt die IC ihren Kunden Premiumprodukte namhafter Partner zu Verfügung.

Firmeninformationen zu IC information company AG bei monetas.ch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert