Die Daten sind der Schlüssel zum Preis

Auf Basis der Automatisierung kann man den Betriebspreis einer bestimmten automatisierten Umgebung gut ermitteln, indem man die Daten dieser Umgebung erfasst. Diese Daten sind aber auch für die Errechnung der Entscheidungen und die Beurteilung von Automatisierungsschritten notwendig. Die Software sammelt, während sie IT-Umgebungen betreibt, jegliche Art von Daten über diese Umgebung – unabhängig davon, ob es sich um ganz einfache Installationen oder komplexe, große IT-Umgebungen handelt. Dabei wird sie ebenso mit den Monitoring-Systemen und den ITSM (Ticketing- und Workflow-Systemen) verbunden. Zu ihrer Arbeit benötigt die Software eine Beschreibung der zu betreibenden IT auf einem einfachen Niveau. Diese Beschreibung wird in einem einfachen Abhängigkeitsmodell hinterlegt, dem MARS Modell. MARS steht dabei für Maschine, Applikation, Ressource und Software und beschreibt, wie die vorhandene IT zusammenhängt. Aus technischer Sicht sind in einem MARS Modell die physikalischen und virtuellen Maschinen und die auf ihnen installierte Software erfasst. Aus Geschäftssicht sind die Applikationen und die für ihren Betrieb notwendigen IT-Ressourcen (Pakete aus Software) enthalten (siehe Grafik). Das MARS Modell soll dabei keine eindeutige Definition der IT vornehmen, wie das eine CMDB (Configuration Management Database) versucht, sondern lediglich die grobe Struktur beschreiben. Darum ist das MARS Modell in seinen Typisierungen auch flexibel und entwickelt sich über die Zeit mit den IT-Umgebungen mit. Im Gegensatz zu einer starren CMDB erzeugt ein solches Modell keinen Datenüberlauf beim Benutzer, sondern erlaubt es, auch größte Mengen an Daten zu bündeln.

 

Beispielhafte Darstellung eines MARS Modells

 

Über die einfachen Strukturen des MARS Modells werden die gesammelten Informationen über Architektur, Infrastruktur aber eben auch über die Bearbeitungszeit von Aufgaben strukturiert. Es lassen sich aus diesen Daten neue Rückschlüsse ziehen, z. B.: welche Sorte von Problemen tritt in welchen Architekturen am häufigsten auf, wie viel Aufwand erzeugt welche Art von Organisationsstrukturen, welche Art von Softwaresystemen hat welche Veränderungszyklen, welche Tickets werden wo abgearbeitet und wie lange dauert es oder auch welches Wissen ist erforderlich, um ein bestimmtes System oder einen Systemtyp zu betreiben?

 

Die Daten werden in einer Installation der Software für genau die Umgebung erfasst, die automatisiert betrieben wird. Zudem werden sie anonymisiert zusammengeführt und zentral verarbeitet.

Beispielhaftes Mengengerüst für anfallende Daten:

• Umgebung mit ca. 1.400 Services und 100.000 Tickets p.a.
• 7 GB Event- und Zeitreihendaten aggregiert pro Tag (Rohzeit 21 GB)
• 1 GB Ticket-Meta-Info pro Tag
• 1 GB Protokollierungsdaten von Ausführungen

Diese zentrale Datenbasis umfasst viele Gigabyte pro Tag. Die Kombination der Modelldaten (Faktenwissen), des Automatisierungswissens (Handlungswissen) und der tatsächlichen Situation in den jeweiligen Umgebungen (Situationswissen) erlauben eine sich kontinuierlich verbessernde Aussage über die Betriebsaufwände bestehender Umgebungen. Dadurch, dass man nur noch die Zone des Gleichgewichts zwischen neuen und bekannten Aufgaben ermitteln muss, ist es nicht länger notwendig, die Aufgaben als solche zu verstehen. Durch die Menge an gesammelten Architektur- und Situationsdaten lassen sich diese Gleichgewichtsdaten auf einzelne Komponenten der IT und deren Zusammenspiel hochrechnen. Da in einer IT-Umgebung – ähnlich wie in der Physik die Schwerkraft – jedes Objekt jedes andere beeinflusst, ist es entscheidend, über die historische Analyse die Einflüsse zu gewichten. Hier kommen die Power Laws zur Anwendung, die eine Clusterung der stärksten Einflussfaktoren über Machine Learning erlauben. So kann aus den Daten ermittelt werden, wie viel Aufwand in welche Art von Modell gesteckt werden muss, ohne die tatsächliche Implementierung oder die eigentliche Anwendung zu kennen.

 

Die exponentielle Natur der Lernkurve erlaubt auch eine Abschätzung des Risikos. Im Gegensatz zu einer Fehleinschätzung bei einer genauen Analyse einer bestimmten Tätigkeit verschiebt sich bei der Lernkurve nicht die Gesamtkurve nach oben, sondern es tritt lediglich eine Verbreiterung der initialen Glocke auf, die aber im Verhältnis f(x) -> ln(g(x)) steht.

 

Das Ergebnis: Modellbasierte Preisermittlung für den IT-Betrieb

Diesen Mehrwert der Daten, die bisher nur als Futter für die Verbesserung der Konvergenz der Inferenzalgorithmen genutzt wurden, hat arago vor einiger Zeit erkannt und macht das Ergebnis über die iPad App „MARS-O-Matic“ allgemein nutzbar. Mit dieser App kann jeder ein einfaches Modell seiner IT-Umgebung erfassen und erhält sofort einen Benchmark-Preis für deren Betrieb. Dabei synchronisiert sich die App regelmäßig mit dem zentralen Rechencluster und erhält so aktualisierte Daten über die Betriebsaufwände für bestimmte Modellstrukturen. Die Betriebskosten selbst werden also auch über die Zeit angepasst und reagieren so auf technologische Neuerungen, Architekturerkenntnisse usw.

 

MARS-O-Matic Modell

 

Ein Modell wird durch Hinzufügen von MARS Knoten (Maschinen, Applikationen, Ressourcen, Software) und deren Verbindung zu einem Abhängigkeitsmodell erstellt. Hat man ein solches Modell, können sofort Preise für den Manntagesaufwand im Betrieb ermittelt werden, wenn dieser Betrieb dem lernenden System unterliegt.

 

MARS-O-Matic Preis

 

Einsatz von Standardtechnologie

Das Herzstück des autonomen Automatisierungssystems AutoPilot ist ein in C++ entwickelter individueller Algorithmus. Alle anderen Komponenten des Systems basieren auf offenen Standards. So kommt als Datenspeicher ein dynamisch wachsender Cassandra Cluster zum Einsatz. Cassandra wurde aufgrund der hohen Schreibgeschwindigkeit gewählt, die bei den vielen gleichzeitig aus verschiedensten Quellen in unterschiedlichen Geschwindigkeiten eingehenden Daten ein kritischer Faktor ist. In herkömmlichen Datenbanken hätten alleine die eingehenden Datenströme für ein andauerndes Locking der Tabellen gesorgt. Die Daten werden in Echtzeit hinzugefügt. Die aus den Daten gewonnenen Erkenntnisse – sowohl für die Entscheidungsalgorithmen, als auch für die Preisbildung – müssen also eigentlich stetig aktualisiert werden. Was in herkömmlichen Strukturen zu einem Batch Job geführt hätte, der sich in der Laufzeit ständig selbst behindert hätte und zu immer größeren Hardware-Investitionen nur für die Datenanalyse führen würde, haben wir bei arago mit der Installation von Hadoop in den Cassandra Cluster gelöst. Die Analyse-Algorithmen selbst sind in JAVA geschrieben und verwenden dabei unterschiedliche frei verfügbare Bibliotheken. Die Integrität des Gesamtclusters wird durch eine Installation von Zookeeper gewährleistet. Die Komponenten für die Installation haben wir sowohl in VMware Templates als auch Amazon Machine Images vorliegen. So können wir lokale Installationen in einer komplett virtuellen Umgebung bei minimalem Hardwarebedarf schnell einrichten. Unsere zentrale Auswertungsplattform haben wir auf Amazon EC2 installiert. Das war möglich, da dort ohnehin nur komplett anonymisierte Daten verarbeitet werden. Der Vorteil dabei ist, dass wir dynamisch Rechenkapazität allokieren können, wenn viele Daten eingehen und verarbeitet werden müssen und diese beim Rückgang der Datenflut auch wieder deallokieren können.

 

Teil 1 des Artikels lesen Sie hier.